Saga模式与RabbitMQ组合比Celery更可靠，因其通过本地事务拆分+补偿机制保障跨服务一致性，并依托RabbitMQ持久化、手动ACK、死信队列等特性实现消息不丢、补偿不漏、重试可控。
Python微服务间无法靠单个数据库事务保证跨服务一致性，必须引入最终一致性方案。Saga模式和RabbitMQ可靠消息是生产中最常用、最可控的组合，关键不在“用不用”，而在“怎么让补偿不漏、消息不丢、重试不崩”。
为什么Saga + RabbitMQ比单纯用Celery更可靠
Saga把一个长事务拆成多个本地事务，每个步骤失败都触发前序步骤的补偿操作；RabbitMQ提供持久化、确认机制和死信队列，能兜住网络抖动、服务重启、消费者宕机等现实问题。Celery默认使用Redis做broker时，消息可能丢失（比如Broker崩溃且未配置持久化），而RabbitMQ配合delivery_mode=2、mandatory=True和消费者手动ack，可做到至少一次投递（at-least-once）。
常见错误现象包括：订单创建成功但库存没扣减、支付回调后订单状态卡在“待支付”、补偿动作执行了两次导致库存多扣。这些问题基本都源于消息可靠性或Saga步骤幂等性没做实。
- RabbitMQ必须开启
durable=True声明Exchange和Queue，消息发送时设delivery_mode=2 - 消费者必须在业务逻辑执行成功后再调用
channel.basic_ack()，不能自动确认 - 每个Saga步骤的Try和Compensate操作都得基于唯一
transaction_id做幂等判断，比如写入saga_log表并加唯一索引 - 避免在Compensate里调用下游HTTP服务——它可能不可用，应改用本地SQL回滚或状态机驱动
saga-python库的Try/Compensate定义要避开状态耦合
saga-python要求每个步骤返回dict携带compensation函数，但很多人直接在里面写requests.post()，结果Compensate失败就彻底断链。正确做法是把补偿逻辑收口到本地方法，通过RabbitMQ异步触发，而不是同步阻塞调用。
立即学习“Python免费学习笔记（深入）”；
例如订单服务的Try步骤该做：update order set status='created' where id=%s and status='draft'，同时发一条inventory_reserve消息到RabbitMQ；它的Compensate就只是发inventory_release消息，由库存服务自己消费处理。
- 不要在
compensation函数里写httpx.post("inventory-service/release") - Compensate函数只负责发消息，且消息体带
transaction_id和step_id - 所有Saga步骤的数据库操作必须带
WHERE status = 'expected'条件，防止重复执行 - 步骤超时时间（如RabbitMQ consumer_timeout）需大于业务最大处理耗时，否则会误判失败
RabbitMQ死信队列必须配全三要素才能捕获异常流转
光设x-dead-letter-exchange不够，消息进死信队列需要同时满足三个条件：消息被拒绝（basic_nack或basic_reject）、TTL过期、队列满。生产环境最常漏的是x-dead-letter-routing-key没配，导致死信消息被路由到默认exchange，直接消失。
典型配置示例：
channel.exchange_declare(exchange='dlx', exchange_type='direct', durable=True)
channel.queue_declare(queue='order_saga_dlq', durable=True, arguments={
'x-dead-letter-exchange': 'dlx',
'x-dead-letter-routing-key': 'saga.failed'
})
channel.queue_bind(exchange='dlx', queue='order_saga_dlq', routing_key='saga.failed')
- 消费者遇到数据库连接失败、HTTP超时等临时错误，应
basic_nack(requeue=False)推入DLQ，而非requeue=True无限重试 - DLQ里的消息不能永久堆积，得有定时任务扫描，超过3次失败的
transaction_id转入人工干预流程 - 所有RabbitMQ连接必须启用
heartbeat=60，防止TCP空闲断连导致消息确认丢失
真正难的不是写通Saga流程，而是让每条消息可追溯、每次补偿可验证、每个失败有出口。很多团队卡在“本地跑通，一上生产就丢消息”，问题往往出在RabbitMQ连接复用没做健康检查，或者Saga日志表没建联合唯一索引导致同个transaction_id重复插入成功多次。
