如何处理EventHub触发Azure Function批重试导致的重复事件问题

首先明确根因：EventHub触发器的检查点是按批次粒度提交的，只要批次处理中抛出未捕获异常，运行时就不会推进该批次的消费位点，你配置的FixedDelayRetry触发时会重新投递整个未提交位点的批次，运行时本身不会自动跟踪批次内单条事件的处理状态，这是触发器的默认设计逻辑，不是配置错误。

如何识别批次内已处理成功的事件 #

运行时不会主动返回单条事件的处理结果，你需要基于EventData自带的分区级唯一标识自行判断，标识选择优先级如下：

• 优先使用SequenceNumber：EventHub分区内单调递增的全局唯一序号，同分区下绝对不会重复，是做幂等判断的最优选择
• 其次使用Offset：标识事件在分区日志中的存储位置，同分区下唯一，但问题排查时不如序列号直观
• 不要依赖MessageId：该字段由发送端自行设置，未显式赋值时为空，可靠性不足
  每次处理单条事件前，先拿上述唯一标识查询你维护的状态存储，标记为处理成功的事件直接跳过即可，不需要重复执行业务逻辑。

成熟实践与无状态Function的状态存取方案 #

这个场景的通用落地模式是幂等消费者模式，核心是独立维护事件处理状态存储，和业务逻辑绑定更新，不需要修改Function本身的无状态特性，是经过大量生产场景验证的方案。

适配无服务场景的状态存储选型 #

不需要自己搭服务，直接用Azure生态的原生托管服务即可：

• 核心链路首选：Azure Table Storage / Cosmos DB
  存储结构非常简单：分区键设为{EventHub实例名}/{消费组名}/{分区ID}，行键直接存事件的SequenceNumber，额外存处理状态、处理时间、关联业务ID三个字段就够用。这两个服务按主键查询延迟在毫秒级，成本极低，能完美适配Function的弹性扩缩容特性。
  注意写入顺序：必须在单条事件的业务逻辑完全执行成功后，再写入「处理成功」的状态，绝对不能先写状态再执行业务，避免业务执行失败但状态被标记为成功导致丢数。如果业务逻辑本身是操作数据库，尽量把状态写入和业务操作放在同一个事务里（比如用Cosmos DB存储过程、Azure SQL本地事务），做不到强一致的话，至少要保证状态写入失败时抛出异常，触发重试。
• 非核心轻量场景可选：Azure Redis Cache
  如果业务对极少量重复处理的容忍度较高、追求低延迟，可以用Redis存储已处理的事件序列号，记得给key设置的过期时间必须长于你配置的最长重试窗口+EventHub消息保留周期，避免key过期导致的重复判断失效。缺点是缓存故障丢数据时可能出现少量重复处理，不建议用在资金、订单等核心链路。

改造后的标准处理流程 #

不需要修改现有触发器的重试配置，只要把原来的整批处理逻辑调整为如下顺序即可：

1. 收到事件批次后，先批量查询本批次所有事件对应的处理状态
2. 逐个遍历批次内的事件：
   • 若状态为已处理成功：直接跳过
   • 若状态为未处理/之前处理失败：执行对应业务逻辑
   • 业务逻辑执行成功：立即将该事件的序列号和成功状态写入状态存储
3. 所有事件处理完成后正常返回，运行时会自动提交批次检查点
4. 若某条事件处理抛出异常：直接终止遍历，将异常抛给运行时触发重试。下次批次重投时，之前已经标记为成功的事件会被直接跳过，不会出现重复处理问题

避坑提醒 #

• 不要尝试手动调用EventHub SDK的检查点接口跳过单条事件，这类操作很容易打乱消费位点，导致大面积丢数或者重复消费范围扩大
• 原有FixedDelayRetry策略不需要关闭，改造后重试逻辑只会作用在未处理成功的事件上，不会产生额外副作用
• 状态写入操作要自带幂等性，比如用upsert操作，避免重复写入报错导致不必要的重试

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