为什么搭配Azure Function使用Event Hub时会产生大量重复消息？

1. 单条消息平均重复5次是否属于预期情况 #

不属于正常预期，Event Hub默认至少一次投递的天然重复率通常低于1%，该量级的重复基本由业务侧处理逻辑问题导致，核心排查方向如下：

• 检查Azure Function批量处理的错误/超时情况：如果Function处理批次时出现未捕获异常、运行超时，会导致批次offset未提交checkpoint，触发Event Hub重新投递整个批次的消息，形成批量重复。你提供的代码中所有处理逻辑都封装在genericFunctionStopper.Loaddata方法内，优先核查该方法是否有完善的异常捕获逻辑，是否存在批量处理失败的报错记录。
• 排查下游自有Event Hub限流情况：你配置的下游Event Hub初始吞吐量仅1TU，单TU最多支持1MB/s或1000条/秒的写入流量，当写入量超过阈值时会触发服务端节流，导致IAsyncCollector推送消息失败，Function重试时会产生大量重复消息。

2. 同一发票主键消息EnqueuedTimeUtc重复的原因 #

该现象由批量写入导致，和分区数无关：
EnqueuedTimeUtc是Event Hub服务端在消息写入时统一赋值的时间戳，当你使用IAsyncCollector批量推送多条消息时，同一批次写入的多条消息会被服务端赋值相同的EnqueuedTimeUtc，属于正常表现。旧架构中你直接消费第三方Event Hub，第三方侧的消息是单条或小批量分散写入，因此不会出现同主键消息时间戳重复的情况。

优化建议 #

• 去重逻辑改造：放弃依赖EnqueuedTimeUtc做去重，改用业务主键（发票ID）+ 上游消息offset的组合作为去重标识，也可以在写入自有Event Hub时给每条消息添加自定义唯一ID存入消息属性，消费端基于该ID完成去重。
• Function可靠性优化：调整Event Hub触发器的批量拉取阈值，调小单次拉取的消息数量，避免处理超时；在处理逻辑中加入细粒度异常捕获，单条消息处理失败不要阻断整个批次的offset提交。
• 下游Event Hub配置优化：如果业务写入量较大，建议将初始TU调整到2以上，规避冷启动阶段的节流问题。

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