分布式基础（十一）——分布式理论之分布式事务：2PC

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

 

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

 

​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

 

一、何谓分布式事务

1.1 单体应用

首先，来看下传统的单体应用（Monolithic App）。下图是一个单体应用的 3 个 模块，在同一个数据源上更新数据来完成一项业务，整个过程的数据一致性可以由数据库的本地事务来保证，如下图：

关于传统的数据库事务，其背后的核心就是ACID理论，本文不再赘述，读者可以参阅专门的书籍，后续我的MySQL系列也会专门讲解。

1.2 分布式应用

随着业务需求和架构的变化，单体应用进行了服务化拆分：原来的 3 个 模块被拆分为 3 个独立的服务，每个服务使用独立的数据源（Pattern: Database per service）。整个业务过程将由 3 个服务的调用来完成，如下图：

此时，每个服务自身的数据一致性仍有本地事务来保证，但是整个业务层面的全局数据一致性要如何保障呢？比如订单服务和账户服务，都有各自的数据库，必须保证操作的一致性，不能出现下单成功但是没记账的情况。这就是分布式系统所面临的典型分布式事务需求：

分布式系统需要一个解决方案来保障对所有节点操作的数据一致性，这些操作组成一个分布式事务，要么全部执行，要么全部不执行。

二、二阶段协议详解

二阶段提交（2PC， two-phase commit protocol），顾名思义，就是通过二阶段的协商来完成一个提交操作。

2PC 最早是用来实现数据库的分布式事务的，不过现在最常用的协议是 XA 协议。这个协议是 X/Open 国际联盟基于二阶段提交协议提出的，也叫作 X/Open Distributed Transaction Processing（DTP）模型，比如 MySQL 就是通过 MySQL XA 实现了分布式事务。

2PC分为两个阶段：投票阶段和提交阶段，我们来详细看下。

2.1 事务过程

二阶段提交协议，包含两类节点：

• 一个中心化协调者节点（coordinator），一般也叫做 事务协调者
• 多个参与者节点（participant、cohort），一般也叫做 事务参与者

二阶段提交协议的每一次事务提交过程如下：

投票阶段（commit-request phase / voting phase）

1. 事务协调者请所有事务参与者进行投票：是否可以提交事务，然后等待所有参与者的投票结果；
2. 参与者如果投票表示可以提交事务，那么就必须预留本地资源（执行本地事务），然后响应YES，后续也不再允许放弃事务；如果不能，就返回NO响应；
3. 如果协调者接受某个参与者的响应超时，它会认为该参与者投票为NO，即预留资源失败。

提交阶段（commit phase）

在该阶段，事务协调者将基于投票阶段的投票结果进行决策：提交或取消各参与者的本地事务

1. 仅当所有参与者都返回 YES 响应时，协调者才向所有参与者发出提交请求，此时所有参与者必须保证提交事务成功；
2. 如果投票阶段中任意一个参与者返回 No 响应，则协调者向所有参与者发出回滚请求，所有参与者进行回滚操作。

两阶段提交协议成功场景示意图：

2PC假设所有节点都采用 预写式日志（Write-Ahead Logging） 来写数据，且日志写入后不会丢失。WAL 的核心思想就是先写日志，再写数据。

2.2 优缺点

优点：

1. 强一致性，因为一阶段预留了资源，所有只要节点或者网络最终恢复正常，协议就能保证二阶段执行成功；
2. 业界标准支持，二阶段协议在业界有标准规范——XA 规范，许多数据库和框架都有针对XA规范的分布式事务实现。

缺点：

1. 在提交请求阶段，需要预留资源，在资源预留期间，其他人不能操作（比如，XA 在第一阶段会将相关资源锁定） ，会造成分布式系统吞吐量大幅下降；
2. 容错能力较差，比如在节点宕机或者超时的情况下，无法确定流程的状态，只能不断重试，同时这也会 导致事务在访问共享资源时发生冲突和死锁的概率增高 ，随着数据库节点的增多，这种趋势会越来越严重，从而成为系统在数据库层面上水平伸缩的"枷锁"；

2PC分布式事务方案，比较适合单体应用跨多库的场景，一般用spring + JTA就可以实现。但是因为严重依赖于数据库层面来搞定复杂的事务，效率很低，所以绝对不适合高并发的场景。

注意：一般来说，如果某个服务内部出现跨多库的直接操作，其实是不合规的。 按照分布式服务治理的规范，一个分布式系统，拆成几十个服务，每个服务只能操作自己对应的一个数据库，如果需要操作别的服务对应的库，不允许直连库，必须通过调用别的服务的接口来实现。

三、总结

二阶段提交协议，虽然是目前分布式事务的事实规范，但实际应用并不多。不过2PC是一种非常经典的思想，Paxos、Raft 等强一致性算法，都采用了二阶段提交操作。所以，读者应当理解该协议背后的二阶段提交的思想，当后续需要时，能灵活地根据二阶段提交思想，设计新的事务或一致性协议。