Azure Service Bus Topic消息推送方案选型：规避消息丢失与重复

直接给结论：你应该选择方案b，我们从你核心需求「绝对避免消息丢失+重复」出发，拆解两种方案的优劣：

为什么方案a（仅重试）满足不了需求？ #

• 消息丢失风险无法根除：重试只能解决临时网络波动、服务短暂不可用这类小问题，如果主Service Bus遇到持续性故障（比如区域级 outage、资源被误删），无论重试多少次，消息都无法成功推送，最终必然丢失，完全达不到「绝对避免丢失」的要求。
• 重复推送是必然隐患：重试机制的本质是「不确定推送是否成功就再次发送」——比如推送请求已经成功到达Service Bus，但ACK响应因网络延迟没返回，客户端会误以为失败而重试，直接导致同一条消息被推送多次，违反你「避免重复」的要求。

方案b（配对Service Bus）如何解决核心问题？ #

• 彻底堵死消息丢失的可能：主节点不可用时，消息会被路由到配对节点，确保消息有可靠的接收端，不会因为主节点故障而石沉大海；等主节点恢复后，自动切换回主节点推送（或同步配对节点的消息到主节点），整个流程没有消息丢失的缺口。
• 天然避免重复推送：这种方案的推送逻辑是「互斥路由」——同一消息只会被推送到主节点或配对节点中的一个，不存在重试那种「误判失败重复发送」的场景，从推送层面就最大程度降低了重复的可能。

额外提个兜底建议：可以给每条消息生成唯一的MessageId，让工作流管理器（消费端）基于这个ID做幂等校验，进一步强化「无重复」的保障，但这属于消费端的补充，方案b本身已经从推送逻辑上满足了你的核心要求。

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