Azure Functions Service Bus触发器启用Batch与Session时的消息投递机制

一、启用Batch时，消息投递数量的决定逻辑 #

• 由两个核心配置参数共同控制：
  • maxBatchSize：单次投递到函数的最大消息数，默认值为16，可按需调整（例如设置为32）。
  • maxWaitTime：触发器等待攒够批量消息的最长时间，默认是1分钟。若在该时间内攒满maxBatchSize条消息，会立即投递；若超时仍未攒满，则将已有的消息投递出去。
• 同时还会受以下因素限制：
  • Service Bus队列/主题中当前可用的消息数量；
  • 若启用会话，仅会攒集同一会话内的消息；
  • 函数实例的并发处理能力限制。

二、Service Bus Topic消息持续投递时的触发器工作机制 #

• 触发器采用长轮询机制：函数运行时与Service Bus建立持久连接，当Topic订阅中出现新消息时，会被立即检测到并触发函数（除非被批量配置的等待时间延迟）。
• 当消息持续涌入时，触发器会根据函数实例的实时处理能力动态调整拉取速率：实例处理速度快时，会拉取更多批次；实例负载较高时，会降低拉取频率，避免消息堆积。
• 消息被拉取后会进入锁定状态，直到函数处理完成：处理成功则标记消息为完成；处理失败则解锁消息，使其重新回到队列等待重试。

三、同时启用Batch与Session时的投递行为 #

• 这种情况下，触发器确实会等待一段时间攒集消息后再投递，但有个核心限制：批量内的所有消息必须属于同一个会话。
• 具体逻辑：针对每个会话单独应用maxBatchSize和maxWaitTime配置。当某会话有消息进入时开始计时，要么攒满maxBatchSize条同会话消息，要么等待到maxWaitTime超时，才会将这批消息投递到函数。
• 该设计是为了保障同会话消息的处理顺序——会话的核心作用就是维持消息的有序性，因此批量攒集只会在同会话内进行，绝不会跨会话合并消息。

内容的提问来源于stack exchange，提问作者Manikandan