搜索结果： "分布式事务" (19)
幂等设计：分布式事务的压舱石
MQ 会重投、框架会重试、用户会手抖、网络会重发——重复是常态，幂等是活路。五大武器：唯一键防重插、去重表防重消、状态机防乱序、Token 防手抖、乐观锁防并发。先查后写有竞态，唯一索引才是最后的墙。
最大努力通知：通知到为止的艺术
给外部商户推支付结果，对方系统宕机三小时——总不能拿 MQ 无限重试陪它耗。最大努力通知：按阶梯间隔尽力喊 N 遍，喊不到就停，再给对方留一个主动查询的口子。内部靠可靠消息，对外靠尽力而为，边界要分清。
事务消息：RocketMQ 半消息与回查
本地消息表的活，RocketMQ 把它下沉到了服务器内部：先发半消息锁住事实，再执行本地事务，提交或删除；进程挂了还有回查兜底。省掉消息表和扫描任务，代价是被绑死在会做事务消息的 MQ 上。
本地消息表：最朴素的最终一致
先发消息后提交事务，回滚收不回消息；先提交再发消息，进程挂了消息蒸发。本地消息表用最笨的办法破局：业务数据和消息记录同库同事务，后台任务扫描投递——不依赖任何框架，两张表加一个定时任务就是全部。
Saga：长事务的状态机与补偿
五环节的退货流程横跨五天，TCC 要写十五个接口，Saga 只要每步配一个补偿：把长事务拆成一串本地事务，失败就逆序回滚。没有预留阶段，换来的是轻；没有隔离性，换来的是必须设计语义锁。
TCC 三大坑：空回滚、幂等、悬挂
网络一抖，Cancel 比 Try 先到（空回滚）、Confirm 被重试调了三遍（幂等）、回滚完迟到的 Try 又把资源冻上了（悬挂）。三大坑一个根源：远程调用的时序不可控。一张事务控制表管住三个接口的状态，全防住。
TCC：把事务搬进业务代码
XA 的性能债还不起，就用业务改造来换：Try 预留、Confirm 确认、Cancel 释放。把数据库的锁换成业务字段里的冻结标记，吞吐回来了，代价是每个参与者多写两个接口、多背一套幂等纪律。
2PC 与 XA：强一致的经典与枷锁
先表决再提交，全员点头才生效——2PC 用一把全局的钥匙换来了跨库强一致，代价是同步阻塞、协调者单点、不一致窗口三道枷锁。XA 把它做成了数据库标准，接入便宜，性能昂贵：低并发改造成本最低的方案，高并发链路的禁区。
理论基石：从 ACID 到 CAP 再到 BASE
ACID 的护城河出了单机就塌了；CAP 不是三选二，P 没得选，真正的取舍在 C 和 A 之间；BASE 把中间态合法化，最终一致成为互联网架构的宿命。理论不解决问题，但决定你选方案时问什么问题。