补偿事务需应用层实现，RabbitMQ仅支持单次消息发送确认，不提供分布式事务或回滚能力；应采用本地消息表或发件箱模式确保DB与消息最终一致，并通过幂等、死信队列、手动ACK及上下文快照消息结构保障可靠性。
补偿事务必须自己实现，RabbitMQ 不提供事务回滚能力
RabbitMQ 本身没有跨服务的分布式事务支持，confirm 模式和 transaction（已废弃）只管单次发消息是否成功，不涉及业务一致性。所谓“补偿”，是应用层用消息驱动状态机：正向操作发消息 → 对方消费成功 → 本地更新状态；失败时靠定时任务或死信队列触发 cancelOrder()、refundMoney() 这类反向操作。
常见错误现象：消息发送成功但下游消费失败，上游就认为事务完成；或者把 channel.txSelect() 当成数据库事务来用（它早被标记为 deprecated，且仅保证 broker 接收，不保下游处理）。
- 必须开启
durable队列 +persistent消息，否则 broker 重启后补偿指令丢失 - 消费端要手动
ack，禁用autoAck=true，否则消息被取走就丢，失败也无法重试 - 每个补偿动作需幂等：比如用
order_id+action_type做唯一索引，防止重复退款
怎么设计可追踪的补偿消息结构
光发个 {"type":"cancel","orderId":"123"} 不够。补偿链一旦断掉，你根本不知道该不该补、补到哪一步。关键是在消息体里带上下文快照和版本号。
使用场景：订单服务调库存服务扣减，库存失败后，订单要回滚创建动作；但如果订单已通知用户“下单成功”，还得额外发短信撤回——这些都得靠消息字段区分。
- 必含字段：
traceId（全链路跟踪）、compensateTo（目标服务名）、originalEvent（原始事件类型，如createOrder）、version（业务状态版本，用于乐观锁判断能否执行补偿） - 避免在消息里放敏感数据（如用户银行卡号），补偿逻辑应通过
orderId查库获取必要信息 - 示例消息体：
{"traceId":"abc123","compensateTo":"inventory-service","originalEvent":"deductStock","orderId":"ORD-789","version":2,"timestamp":1715824000}
死信队列不是自动补偿开关，得配好 TTL 和 retry 逻辑
很多人以为只要把消息扔进死信队列（DLX），就等于“自动延时重试+最终补偿”。其实 DLX 只是转发机制，真正决定是否补偿、补几次、间隔多久，全靠你写的消费者逻辑。
性能影响：TTL 设太短（如 1s），网络抖动就会触发大量无效补偿；设太长（如 1h），故障恢复延迟高。典型做法是用指数退避：1s → 5s → 30s → 3min，超过 3 次失败再进告警队列。
- 声明队列时必须同时设置：
x-dead-letter-exchange、x-dead-letter-routing-key、x-message-ttl - 不要依赖 RabbitMQ 的
max-length触发死信，它只按队列长度截断，跟消息生命周期无关 - 消费端收到死信后，先校验
redelivered属性和deliveryTag，避免把重试当新消息重复处理
本地事务与消息发送如何真正解耦
最常踩的坑是：先 commit 数据库，再发消息。万一发消息失败（网络中断、broker 不可用），状态已提交，补偿消息又没出去，系统就卡死在“半成功”状态。
正确做法是用本地消息表或事务性发件箱（outbox pattern）。核心是让 DB 和消息落盘在同一个事务里，靠轮询保障最终一致。
- 建一张
outbox_message表，字段含：id、payload、status（pending/sent/failed）、created_at - 业务代码中：开启事务 → 写业务表 + 插入
outbox_message（status=pending）→ commit → 单独线程异步扫描 status=pending 的记录，调用channel.basicPublish()，成功则 update status=sent - 不要用 RabbitMQ 的
publisher confirms同步等待结果，它会拖慢主流程；confirm 是事后校验手段，不是同步屏障
复杂点在于轮询频率和并发控制：查太多压 DB，查太少延迟高；多个 worker 同时扫同一条记录会导致重复发。得用 SELECT ... FOR UPDATE SKIP LOCKED 或加分布式锁，这点容易被忽略。
