WCF文件服务接入Azure EventHubs：事件发布失败时回滚还是重试？

核心诉求锚定 #

用户上传文件的核心需求是一次操作完成文件持久化与事件通知，既要避免让用户重复上传（尤其是大文件），也要尽可能保证数据的一致性。

两种方案的利弊拆解 #

回滚方案（失败则撤销DB写入+删除Blob） #

• 优势：能严格保证数据一致性，不会出现「DB有记录、Blob存了文件但事件没发出去」的脏数据
• 劣势：
  • 实现复杂度高：跨本地DB和Azure Blob的分布式事务很难维护，WCF环境下搞分布式事务还容易引发性能问题
  • 用户体验极差：上传成功后因事件发布失败被回滚，用户得重新上传，大文件场景下投诉率会飙升
  • Blob删除有延迟：Azure Blob的删除操作不是即时生效，可能出现短暂的脏数据残留

重试方案（失败则自动重试事件发布） #

• 优势：
  • 用户体验友好：无需用户重新操作，后台自动兜底处理
  • 实现成本低：可以直接利用Event Hubs客户端内置的指数退避重试策略，或者用本地数据库表做重试队列，逻辑简单
• 劣势：
  • 可能产生重复事件：重试成功后下游会收到重复消息，要求下游必须实现幂等性
  • 存在短暂数据不一致：DB和Blob已写入，但事件未发布的窗口内，下游系统看不到这条数据，属于最终一致的范畴，对强一致性要求极高的场景不适用

推荐的折中方案：重试优先+兜底补偿 #

完全回滚或单纯重试都有明显短板，建议结合两者优势，采用「重试优先+兜底补偿」的策略：

1. 多级重试机制：
   • 第一级：配置Event Hubs客户端的内置重试，设置3-5次指数退避重试，覆盖网络抖动、临时限流等瞬时故障
   • 第二级：如果内置重试失败，将事件关键信息（文件ID、DB记录ID、Blob路径等）写入本地重试队列（比如用SQL Server表实现），后台起定时任务轮询重试，直到发布成功
2. 异常告警与手动兜底：
   • 当重试超过阈值（比如24小时）仍失败，触发运维告警，同时记录详细异常日志
   • 运维人员可手动触发事件发布，若确认Event Hubs长期不可用，再执行回滚操作（删除Blob、DB记录）——这是极端场景的兜底，而非常规流程
3. 强制下游幂等：
   • 要求所有事件消费端必须基于事件ID或文件ID实现幂等逻辑，避免重复处理引发业务异常（比如重复生成单据）

额外优化建议 #

• 调整操作顺序：将DB写入与Blob上传用本地事务包裹（比如先上传Blob，成功后再写入DB并提交事务），保证这两步要么都成功要么都失败，后续事件重试有明确的数据源依据
• 事件内容设计：事件中包含Blob路径、DB记录ID、文件元数据等完整信息，下游无需额外查询本地DB即可处理

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