Python无开箱即用分布式事务支持，需用Saga模式显式实现幂等正向与补偿操作，状态必须持久化到DB或Redis。
Python 里没有开箱即用的分布式事务支持
标准库和主流 Web 框架（如 Flask、Django）本身不提供跨服务、跨数据库的事务一致性保障。transaction 或 sqlite3 的 commit() 只管本地资源；一旦涉及 HTTP 调用、消息队列、多个 DB 实例，ACID 就断了。
这不是 Python 的缺陷，而是分布式系统本质决定的：网络不可靠、节点独立故障、无法全局加锁。所以别指望靠一个装饰器或中间件“自动修复”两台机器上的转账一致性。
实际项目中怎么落地补偿逻辑（Saga 模式）
最常用、最可控的方式是显式编写正向操作 + 对应的补偿操作，由业务代码驱动状态推进与回滚。比如用户下单扣库存 → 创建订单 → 扣余额，任一环节失败，就按反序调用补偿函数。
-
saga不是某个库的名字，而是一种模式；Python 里靠自己组织函数调用链即可，不需要引入复杂框架 - 每个步骤必须幂等：
cancel_order(order_id)多次调用不能重复退款 - 状态要持久化：用数据库字段记录当前执行到哪一步（如
status= "inventory_deducted"），避免重启后重复执行或跳步 - 不要在内存里维护 saga 流程状态——进程挂了就丢，必须落库或写入 Redis 带过期时间的 key
示例片段：
立即学习“Python免费学习笔记（深入）”；
def create_order(user_id, item_id):
# 正向操作
inventory = db.query("SELECT stock FROM items WHERE id = %s", item_id)
if inventory.stock < 1:
raise ValueError("out of stock")
db.execute("UPDATE items SET stock = stock - 1 WHERE id = %s", item_id)
order_id = db.insert("INSERT INTO orders (...) VALUES (...)")
return order_id
<p>def cancel_order(order_id):</p><h1>补偿操作：只还原库存，不删订单（留痕）</h1><pre class='brush:python;toolbar:false;'>db.execute("UPDATE items SET stock = stock + 1 WHERE id = (SELECT item_id FROM orders WHERE id = %s)", order_id)</pre>Django/Flask 中调用外部服务时的事务边界陷阱
很多人误以为在 @transaction.atomic 里发 HTTP 请求，就能让远程服务也一起回滚。这是错的：HTTP 请求不受本地数据库事务控制，网络延迟、超时、5xx 错误都会导致状态不一致。
-
@transaction.atomic只对当前 DB 连接生效，对requests.post()或kafka_producer.send()完全无效 - 如果先 commit 本地事务再发请求，失败后无法回滚已提交的数据 —— 必须把本地变更暂存在未提交状态，等远程确认成功后再 commit
- 更稳妥的做法是：本地写入“待处理”状态（如
order.status = 'pending_payment'），异步轮询或监听 webhook 更新最终状态
什么时候该放弃强一致性，改用最终一致性
不是所有场景都值得为分布式事务付出复杂度代价。比如日志上报、通知推送、积分变动，允许几秒甚至几分钟延迟，那就别硬套 Saga。
- 用消息队列（如 RabbitMQ、Kafka）解耦，生产者只管发事件，消费者各自重试处理
- 关键字段加版本号或更新时间戳，消费端做去重和幂等判断（例如检查
event_id是否已处理） - 监控缺失事件比写补偿逻辑更省事：定期扫描“卡在 pending 状态超过 5 分钟”的订单，人工介入或触发告警
真正难的从来不是写几个 try/except，而是判断哪条数据必须立刻一致、哪条可以晚点对齐——这个决策藏在业务规则里，不在代码里。
