NServiceBus Outbox精确一次处理：RabbitMQ+SQL Server去重机制问询

核心去重依据：消息唯一ID #

接收端启用Outbox后，会以传入消息的全局唯一ID作为去重标识。当RabbitMQ投递消息时，接收端的第一步操作就是检查SQL Server的Outbox存储：

• 若该消息ID的记录已存在，直接跳过所有业务逻辑处理
• 若不存在，才会进入后续的消息处理流程

跨事务场景的容错逻辑 #

你提到的「处理完RabbitMQ消息后，标记Outbox为已投递的SQL调用失败」是对流程的误解，实际执行顺序和容错逻辑如下：

1. 接收端从RabbitMQ获取消息后，首先在SQL Server的Outbox表中插入一条状态为「待处理」的记录，这一步和后续业务逻辑处于同一个SQL事务中
2. 执行消息对应的业务逻辑（如更新业务数据）
3. 业务逻辑执行成功后，提交SQL事务：此时Outbox记录的状态会被更新为「已处理」，同时业务数据的变更也会持久化
4. 最后向RabbitMQ发送确认（ACK），告知消息已处理完成

如果在步骤3之后、步骤4之前出现故障（比如网络波动导致ACK未送达RabbitMQ），RabbitMQ会认为消息未被处理并重新投递。但此时接收端再次收到消息时，会发现Outbox中已经存在该消息ID的「已处理」记录，直接跳过处理，不会重复执行业务逻辑。

如果是在步骤3之前失败（如业务逻辑抛出异常、SQL事务提交失败），Outbox的「待处理」记录会随事务回滚被删除，此时RabbitMQ重发消息，接收端会重新执行完整流程，这属于正常的故障重试机制。

为什么不会出现重复处理？ #

关键在于Outbox记录的写入/更新与业务逻辑执行绑定在同一个SQL事务中：要么业务逻辑和Outbox状态一起成功提交，要么一起回滚。只要业务逻辑执行完成并提交了事务，Outbox中就一定会存在该消息的「已处理」记录，后续的重复消息都会被去重机制过滤。

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