不过，

痛点：线上使用者下单后余额已扣、库存已减。但订单显示未支付，排查发现，订单库、账户库、库存库各自独立修改。缺乏统一事务保障，导致数据不一致。其实，跨库操作没有本地事务兜底，出问题只是早晚的事。

一、一个扣款场景，把问题逼出来

分布式事务要解决的。不是“一次操作改多个地方”，而是“多个地方要么同时成功、要么同时失败”。

本地事务在同一个数据库内完成的事务。要么全部提交，要么全部回滚。话说回来，可以理解为“同一本账本上的记录，错了一整页都能涂掉重写”。

生活类比的观点是。三个人合租，住在 ①楼、②楼、③楼，晚上要同时关灯，需要挨个通知。只要中间有一层没听到，就会有人摸黑进门。跨库操作就是这种“挨个通知”的活，而本地事务只管自己那盏灯。

分布式事务跨越多个数据库或服务的操作集合，要求所有参与方要么一起成功、要么一起回滚。可以理解为“几本分处各地的账本，想在同一时刻改对”。

这篇文章将从原理到落地完整梳理分布式事务：先看 CAP 定理为何让这条路如此艰难。再看 BASE 理论给出的妥协方案，最终对比 AT 模式和 TCC 模式两大实现及其坑点。收藏一下我们开始，

二、CAP定理：分布式程序的天花板

在 CAP 定理里分区容错是必选项，一致性和可用性只能二选一。

CAP 定理分布式程序不可能同时满足一致性、可用性、分区容错性，最多同时保证其中两个。可以理解为“酒店的地点、价格、房间大小，最多让你挑两个满意”。话说回来，

一致性使用者访问任意节点。读到的数据必须一样，node01 改了余额，node02 必须跟着变。否则使用者换个节点就查到旧账。

可用性读或写总能成功。按理说，只能读不能写、只能写不能读或两者都不可，都算弱可用或不可用。

分区容错节点之间的网络断了程序仍需继续对外服务。Partition 就是网络故障把程序劈成几个互不相通的“孤岛”。

关键矛盾在这这方面。网络不会百分之百畅通，分区大概率会出现；而程序又必须持续运行，分区容错是硬指标，所有分布式程序都得满足。 剩下的，只能在一致性和可用性里挑一个：

• A— 可用性优先：节点继续读写。但同步不了的节点数据不一致；事后靠补偿慢慢收敛，
• C— 一致性优先：把数据锁住等网络恢复再放行；期间程序不可用或只能读，其实，

现实就是这么不讲道理——只要网络会断。你就得在 A 和 C 之间二选一。怎么说呢，

三、BASE理论：不强一致。但最终一致

BASE 理论`放弃的是强一致性，而是把“必须立刻一致”换成“最终一致就行”。可以理解为“先把事办了睡前保证把账平掉”。

• 基本可用：故障时损失部分可用性，但保住主要功能。例如抢购高峰排队等一会儿，而不是直接报错。
• 软状态：允许出现中间状态，比如数据暂时对不上。
• 最终一致性：不要求立刻一致，但所有中间状态结束后数据会收敛到一致。

S​E​A​T​A 等实现遵循两条思路：

• AP 思想：`各分支各自执行并提交，不锁数据；结果可能短暂不一致，通过补偿实现最终一致——AT 模式走这条路。
• CP 思想：`各分支执行完先不提交，等全局决定后统一提交或回滚；怎么说呢，期间锁资源保证强一致——XA 模式走这条路。

四、AT模式：框架帮你补偿。但别忽视脏写

痛点：`AT 模式虽然免写补偿代码，却在高并发下容易出现脏写导致数据回滚错误，这是最常被低估的风险。说起来，

`Seata 提供的一种实现。通过数据快照自动回滚，让开发者几乎无感。可以理解为“程序定期给你的数据拍照，出事就按照片恢复”。它包含两个阶段：

1. 阶段一：`每个分支事务执行前记录快照，接下来正常执行并提交。
2. 阶段二：`全局协调者汇果——全部成功则删掉快照；有失败则依据快照回滚，再删快照。

A​T 在多数业务场景下省心省力。但在多线程并发访问同一条记录时会出现脏写——某个分支回滚时把另一个刚提交的新值覆盖回旧值，从而导致账目错乱。

解决办法：`引入全局锁。在分支释放 DB 锁前获取全局锁，以确保同一时间只有一个事务能操作该行数据。取舍提示：`全局锁会显著降低冲突热点的并发吞吐。如果写冲突少且读多写少，用 AT 很划算；如果业务是高并发热点，请考虑 TCC 或消息队列方案。

五 、TCC模式 ：补偿逻辑自己写，更可控