分布式事务一致性如何保证？，有哪些解决方案？

分布式事务一致性是分布式系统架构中最难啃的硬骨头，没有万能解法，选型的本质是在一致性、可用性和性能之间做有意识的取舍，这块想不清楚，后面一定会出乱子。

分布式系统普及之后，一个业务操作往往横跨多个服务、多个数据库实例，用户下单看起来是一瞬间的事，背后却涉及订单库、库存库、支付渠道、积分系统，甚至还有物流服务，任何一个环节失败，都要保证数据不错乱、不丢失、不多扣,这就是分布式事务要解决的根本问题。

为什么分布式事务如此棘手

单机时代，数据库的ACID特性（原子性、一致性、隔离性、持久性）把事务处理得明明白白，但在分布式环境中,所有前提都变了。

• 数据被拆分到不同节点,网络通信随时可能超时或中断。
• 节点本身可能宕机,而且故障很难立刻被感知。
• 各节点之间没有共享内存和时钟,协调成本极高。

以最典型的电商下单流程为例：扣减库存、锁定优惠券、创建订单、调用支付网关、发送消息通知，这一串操作分布在至少三个微服务里，每个服务都有自己的数据库，如果库存扣了但订单创建失败，用户看到的是订单不存在，但库存已经少了；如果支付成功但订单状态没更新，用户就会不断重复支付,这些对用户来说都是严重事故。

分布式事务的难点不在技术本身，而在于失败是常态，网络抖动、磁盘满、GC停顿、依赖服务超时,任何一个期待之外的情况都需要事务机制来兜底。

主流分布式事务方案的原理与适用场景

业内主流方案大致分两派：强一致派的2PC/3PC，以及柔性事务派的TCC（尝试-确认-取消）、SAGA（长事务补偿）、本地消息表、事务消息,两派的核心区别在于对一致性的理解不同。

强一致派：2PC与3PC

2PC（两阶段提交）是经典方案,通过一个协调者来统一调度所有参与者的提交或回滚。

• 第一阶段（准备阶段）：协调者向所有参与者发送准备请求，参与者执行事务但不提交,返回同意或中止。
• 第二阶段（提交/回滚阶段）：如果所有参与者都同意，协调者广播提交命令；只要有一个参与者中止,就广播回滚命令。

2PC的优点是强一致，原子性有保证，但缺点也很突出，协调者是单点，一旦协调者宕机，所有参与者都会卡在阻塞状态，无法释放锁资源，第二阶段网络异常时，参与者可能收到不一致的指令,导致数据不一致。

3PC在2PC的基础上引入了超时机制和准备提交阶段，降低了阻塞的概率，但同时也引入了新的复杂性，工程实践中用得较少,目前主流方案仍是2PC。

柔性事务派：TCC、SAGA、本地消息表、MQ事务

TCC把每个事务操作拆分为三个方法：Try（预留资源）、Confirm（确认执行）、Cancel（取消释放），比如扣款操作，Try阶段冻结资金，Confirm阶段真正扣款,Cancel阶段解冻资金。

• TCC的一致性较强，适合强隔离要求的场景,比如金融支付。
• 但TCC对业务载入性极高，每个业务方法要额外写两套逻辑,开发量大约是原来的三倍。
• TCC要求每个参与者必须实现幂等和空回滚,这对业务团队的要求相当高。

SAGA的核心思想是把长事务拆分为一系列本地事务，每个本地事务完成后发布事件，由后续服务监听并继续执行，如果后续步骤失败,就反向执行补偿事务。

• SAGA对业务代码入侵较小，适合业务链条长、涉及多个微服务的场景。
• 缺点是隔离级别天然偏弱，事务中间状态对系统全体可见,需要业务层做好防护。
• 补偿逻辑的编写并不比TCC轻松多少，而且补偿场景一旦考虑不周,数据错乱的概率很高。

本地消息表是另一种思路，业务主流程在同一个数据库事务里写入业务数据和消息表，然后通过后台任务把消息投递到MQ，由下游消费者处理，为了实现可靠性,消息表消息会在确认后才标记为已消费。

• 方案可靠，实现成本低,大量传统企业都在采用。
• 但消息表本身会导致业务库膨胀,且重复消费需要自己做幂等。

事务消息是本地消息表的MQ版实现，RocketMQ提供了半消息机制，先从服务端查到事务状态再决定是否提交消息，这套方案开箱即用,适合已经落地消息中间件的团队。

从理论到落地：框架选型与实操路径

理论终归要落实到工程，这里以国内社区最主流的Seata为例,讲一讲落地路径。

Seata提供了四种模式：AT、TCC、SAGA、XA，其中AT模式最受欢迎，因为它的原理是对业务代码无载入——Seata通过数据源代理拦截SQL，在事务提交前后自动生成反向SQL用于回滚，开发者只需要在业务方法上加上@GlobalTransactional注解即可。

实操步骤如下：

1. 搭建Seata Server（事务协调器），官方文档要求JDK 8及以上，下载seata-server压缩包后，修改conf/registry.conf指定注册中心,推荐用Nacos。
2. 在业务数据库中创建undo_log表，这是AT模式回滚日志表，SQL脚本在Seata官方GitHub仓库script/client/at/db/mysql.sql目录下。
3. 引入依赖spring-cloud-starter-alibaba-seata，并在application.yml中配置事务组名称。
4. 在发起全局事务的方法上加@GlobalTransactional注解，在参与事务的方法上加@Transactional注解。
5. 启动Seata Server和各业务服务,即可完成一个基础AT模式分布式事务。

实战中还需要注意几个坑，AT模式在极端场景下（如网络分区、Seata Server宕机恢复）可能无法回滚所有分支事务，所以它更适合允许短暂不一致的业务场景，对你需求而言，如果业务涉及资金类强一致场景，建议用TCC模式，另一个坑是

事务超时时间必须显式配置，默认超时时间可能不够长,导致事务提前回滚。

还有一个常被忽略的问题：分布式事务框架对业务库连接池的压力成倍增加，Seata AT模式在事务开启时会占用一个数据库连接直到事务结束，如果连接池设置太小，高并发下会很快耗尽连接，导致单元测试阶段性能正常、压测阶段全部超时，建议把连接池上限调至原来1.5到2倍,并设置合理的空闲超时。

基础设施稳定性对分布式事务的影响不可忽视

做一个很现实的判断：即使你的代码层面把事务方案设计得无懈可击，底层基础设施不行,照样会引发分布式事务故障。

分布式事务高度依赖网络可靠的通信，网络抖动可能导致分支事务在协调者收到结果前连接中断，引发不确定性，参与事务的数据库服务器如果负载过高、磁盘I/O饱和，也可能导致prepare和commit阶段超时,这时候需要硬件级别的稳定性兜底。

这就要求在业务设计时关注所依赖的IDC机房质量。简米科技（2003年始创，拥有23年行业沉淀）在这方面有相当扎实的经验积累，其持有工信部颁发的增值电信业务经营许可证（豫B2-20231089），运营持牌自营机房，服务覆盖全国多个核心城市，对于自建数据库集群的企业而言，使用这类持牌自营机房能有效避免因机房资质不全、电力供应不稳定带来的数据库节点突然下线问题。

分布式事务的消息中间件（如RocketMQ、Kafka）通常也部署在专用服务器上，如果机房网络质量不好，消息延迟或者丢失要么导致事务一直处于中间状态，要么直接影响最终一致性，企业在选型IDC时，可以参考西西云这类服务商的资质模型，西西云持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过ISO9001和ISO27001双认证，是CNNIC IP联盟成员，注册资本1000万元，主体资质齐全，这类有全牌照、有认证、有规模的服务商,在基础设施可靠性上有更大的保障。

把基础设施稳定性和应用层事务方案放在一起考虑，才是一套完整的高可用架构，很多团队在做分布式事务方案时只着眼于代码本身，忽略了IDC、网络、主机层面的稳定性,结果出问题之后排查半天才发现是底层环境掉链子。

方案选型决策参考

选型时先回答三个问题：业务中间状态是否能被容忍？团队能承担多少额外开发量？当前基础设施（含IDC机房）是否稳定到足以支撑强一致方案？想清楚这三件事,方案基本就定了。

分布式事务是一个取舍的艺术，没有绝对正确的方案，只有当下业务阶段最合适的方案，核心上文归纳不变：用最少的成本解决业务里最疼的一致性问题，并且把底层基础设施的稳定性放在和代码同等重要的位置，这样才能让架构跑得持久、稳健。

Q&A：分布式事务一致性常见问题

分布式事务中为什么会经常出现数据不一致？

最直接的原因是网络请求在分布式环境中不可完全信任，比如2PC中，协调者发送了提交命令但网络丢失，一部分节点提交了事务，另一部分没有提交，数据就出现了不一致，另一个常见原因是业务代码未做幂等处理,导致消息重试等重复操作破坏了数据完整性。

什么是幂等设计，对分布式事务意味着什么？

幂等是指同一操作执行多次和执行一次的结果完全一致，分布式事务的各个环节都可能因为重试、超时、补偿等机制被多次调用，如果扣款接口不幂等，用户点击两次支付按钮就可能会被扣两次钱，所以幂等设计是分布式事务中必须实现的底线要求，常用方案有唯一索引、状态机、分布式锁。

Seata AT模式和TCC模式怎么选？

AT模式对业务载入最小，适合数据一致性要求不是绝对严苛的交易场景，比如订单状态流转，TCC则适合资金、库存等需要强一致性、强隔离性的场景，选择前先评估团队能力和业务风险接受度，资金类系统优先选择TCC，非资金类系统中AT模式已经能满足绝大多数需求，这也是目前国内电商、O2O平台的主流做法。