根据EF Core事务状态决定是否向Azure Service Bus发送变更

你遇到的是典型的分布式事务一致性问题，社区里成熟的解决方案主要围绕最终一致性设计，以下是几种常用方案：

1. Outbox模式（事务日志表+后台轮询） #

这是目前最常用的可靠方案，核心思路是将消息发送与本地事务绑定，通过后续重试确保消息最终送达：

• 在业务数据库中新增一张OutboxMessages表，字段包含：消息内容、目标队列名、状态（待发送/已发送/发送失败）、重试次数、创建时间、最后尝试时间。
• 在EF Core的业务事务中，同时将需要发送的变更记录插入OutboxMessages表，确保业务操作和消息记录的原子性——事务提交则消息记录落地，事务回滚则消息记录也被回滚。
• 实现一个后台服务（比如ASP.NET Core Hosted Service），定期轮询OutboxMessages表中状态为“待发送”或“发送失败且重试次数未达阈值”的记录。
• 针对每条记录尝试发送到Azure Service Bus：
  • 发送成功：将记录状态更新为“已发送”。
  • 发送失败：增加重试次数，若未超过阈值则保留“发送失败”状态等待下次轮询；若超过阈值则标记为“永久失败”并触发告警。

2. 分布式事务（DTC绑定） #

如果你的数据库（如SQL Server）和Azure Service Bus都支持分布式事务协调器（DTC），可以将EF Core事务与Service Bus的发送操作绑定到同一个分布式事务中：

• 启用Service Bus的事务功能，在发送消息时指定事务上下文。
• 将EF Core的数据库事务与Service Bus事务关联，确保两者要么同时提交，要么同时回滚。
• 注意：该方案配置复杂，性能开销较高，且对基础设施有严格要求，高并发场景不推荐使用。

3. 补偿机制（仅适用于可逆业务操作） #

先提交EF Core事务，再尝试发送消息：

• 若消息发送成功，流程结束。
• 若消息发送失败，执行补偿操作回滚已提交的业务变更（比如订单创建失败则删除订单记录）。
• 局限性：要求业务操作必须是可逆的，大部分业务场景无法满足，仅适合特定场景。

实践建议 #

• 优先采用Outbox模式，这是微服务架构中处理最终一致性的标准方案，实现简单且可靠性高。
• 后台轮询的间隔时间和重试策略需根据业务场景调整，避免给数据库和Service Bus造成不必要的压力。
• 定期清理OutboxMessages表中的过期记录（比如已发送超过30天的记录），防止表数据膨胀。

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