分布式事务篇
为什么需要分布式事务
什么是事务
事务就是用户定义的一系列数据库操作，这些操作可以视为一个完成的逻辑处理工作单元，要么全部执行，要么全部不执行，是不可分割的工作单元。
通俗的说，事务是指程序中一系列严密的逻辑操作，而且所有操作必须全部成功完成，否则在每个操作中所做的所有更改都会被撤销。
数据库事务正确执行的四个基本要素：
- 原子性（Atomicity）
- 一致性（Consistency）
- 隔离性（Isolation）
- 持久性（Durability）
为什么需要分布式事务
由于近十年互联网的发展非常迅速，很多网站的访问越来越大，集中式环境已经不能满足业务的需要了，只能按照业务为单位进行数据拆分(包含：垂直拆分与水平拆分)，以及按照业务为单位提供服务，从早期的集中式转变为面向服务架构的分布式应用环境。
举一个典型的例子，阿里的淘宝网站随着访问量越来越大，只能按照商品、订单、用户、店铺等业务为单位进行数据库拆分，以及按照业务为单位提供服务接口。
这个时候 为了完成一个简单的业务功能，比如：购买商品后扣款，有可能需要横跨多个服务，涉及用户订单、商品库存、支付等多个数据库，而这些操作又需要在同一个事务中完成，这就涉及到到了分布式事务。
本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。
分布式事务产生的情景
- 跨JVM进程产生分布式事务：典型的场景就是微服务架构：微服务之间通过远程调用完成事务操作。比如：订单微服务和库存微服务，下单的同时订单微服务请求库存微服务减少库存。
- 跨数据库实例产生分布式事务：单体系统访问多个数据库实例当单体系统需要访问多个数据库（实例）时就会产生分布式事务。比如：用户信息和订单信息分别在两个MySQL实例存储，用户管理系统删除用户信息，需要分别删除用户信息及用户的订单信息，由于数据分布在不同的数据实例，需要通过不同的数据库链接去操作数据，此时产生分布式事务。
- 多服务访问同一个数据库实例：单微服务和库存微服务即使访问同一个数据库也会产生分布式事务，原因就是跨JVM进程，两个微服务持有了不同的数据库链接进行数据库操作，此时产生分布式事务。
分布式架构常见理论
分布式的一致性理论（CAP）
CAP分别是：
- 一致性（Consistency）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。
- 可用性（Availability）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
- 分区容忍性（Partition tolerance）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP理论指的是在一个分布式系统中，CAP这三点最多只能同时实现两点，不可能三者兼顾。
CAP理论的不可能三角：
在绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证最终一致性。
这也是是后来发展出的BASE理论的基础。
BASE理论
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
- Basically Available（基本可用）
- Soft state（软状态）
- Eventually consistent（最终一致性）
分布式事务解决方案
两阶段提交（2PC）
两阶段提交2PC是分布式事务中最强大的事务类型之一，两段提交就是分两个阶段提交，第一阶段询问各个事务数据源是否准备好，第二阶段才真正将数据提交给事务数据源。
为了保证该事务可以满足ACID，就要引入一个协调者（Cooradinator），其他的节点被称为参与者（Participant）。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务进行提交。处理流程如下：
阶段一
a) 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复。
b) 各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。
c) 如参与者执行成功，给协调者反馈 yes，否则反馈 no。
阶段二
如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则，发送提交(commit)消息。两种情况处理如下：
情况1：当所有参与者均反馈 yes，提交事务
a) 协调者向所有参与者发出正式提交事务的请求（即 commit 请求）。
b) 参与者执行 commit 请求，并释放整个事务期间占用的资源。
c) 各参与者向协调者反馈 ack(应答)完成的消息。
d) 协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。
情况2：当有一个参与者反馈 no，回滚事务
a) 协调者向所有参与者发出回滚请求（即 rollback 请求）。
b) 参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。
c) 各参与者向协调者反馈 ack 完成的消息。
d) 协调者收到所有参与者反馈的 ack 消息后，即完成事务。
问题
1) 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
2) 可靠性问题：如果协调者存在单点故障问题，或出现故障，提供者将一直处于锁定状态。
3) 数据一致性问题：在阶段 2 中，如果出现协调者和参与者都挂了的情况，有可能导致数据不一致。
优缺点
优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）。
缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。
三阶段提交（3PC）
三阶段提交是在二阶段提交上的改进版本，3PC最关键要解决的就是协调者和参与者同时挂掉的问题，所以3PC把2PC的准备阶段（第一阶段）再次一分为二，这样三阶段提交。处理流程如下：
阶段一
a) 协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。
b) 参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。
阶段二
协调者根据参与者响应情况，有以下两种可能：
情况1：所有参与者均反馈 yes，协调者预执行事务
a) 协调者向所有参与者发出 preCommit 请求，进入准备阶段。
b) 参与者收到 preCommit 请求后，执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。
c) 各参与者向协调者反馈 ack 响应或 no 响应，并等待最终指令。
情况2：只要有一个参与者反馈 no，或者等待超时后协调者尚无法收到所有提供者的反馈，即中断事务
a) 协调者向所有参与者发出 abort 请求。
b) 无论收到协调者发出的 abort 请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。
阶段三
该阶段进行真正的事务提交，也可以分为以下两种情况：
情况 1：所有参与者均反馈 ack 响应，执行真正的事务提交
a) 如果协调者处于工作状态，则向所有参与者发出 do Commit 请求。
b) 参与者收到 do Commit 请求后，会正式执行事务提交，并释放整个事务期间占用的资源。
c) 各参与者向协调者反馈 ack 完成的消息。
d) 协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。
情况2：只要有一个参与者反馈 no，或者等待超时后协调组尚无法收到所有提供者的反馈，即回滚事务。
a) 如果协调者处于工作状态，向所有参与者发出 rollback 请求。
b) 参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。
c) 各参与者向协调组反馈 ack 完成的消息。
d) 协调组收到所有参与者反馈的 ack 消息后，即完成事务回滚。
优缺点
优点：相比二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题。阶段 3 中协调者出现问题时，参与者会继续提交事务。
缺点：数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 do commite 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
补偿事务（TCC）
TCC 是服务化的二阶段编程模型，采用的补偿机制：
条件：
- 需要实现确认和补偿逻辑
- 需要支持幂等
处理流程：
a) Try 阶段主要是对业务系统做检测及资源预留。
这个阶段主要完成：
- 完成所有业务检查( 一致性 ) 。
- 预留必须业务资源( 准隔离性 ) 。
- Try 尝试执行业务。
b) Confirm 阶段主要是对业务系统做确认提交。
Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
c) Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
优缺点：
优点：
- 性能提升：具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。
- 数据最终一致性：基于 Confirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。
- 可靠性：解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。
缺点：TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。
本地消息表（消息队列）
核心思想是将分布式事务拆分成本地事务进行处理。
通过在消费者额外新建事务消息表，消费者处理业务和记录事务消息在本地事务中完成，轮询事务消息表的数据发送事务消息，提供者基于消息中间件消费事务消息表中的事务。
条件：
服务消费者需要创建一张消息表，用来记录消息状态。
服务消费者和提供者需要支持幂等。
需要补偿逻辑。
每个节点上起定时线程，检查未处理完成或发出失败的消息，重新发出消息，即重试机制和幂等性机制。
处理流程：
1. 服务消费者把业务数据和消息一同提交，发起事务。
2. 消息经过MQ发送到服务提供方，服务消费者等待处理结果。
3. 服务提供方接收消息，完成业务逻辑并通知消费者已处理的消息。
容错处理情况如下：
- 当步骤1处理出错，事务回滚，相当于什么都没有发生。
- 当步骤2、3处理出错，由于消息保存在消费者表中，可以重新发送到MQ进行重试。
- 如果步骤3处理出错，且是业务上的失败，服务提供者发送消息通知消费者事务失败，且此时变为消费者发起回滚事务进行回滚逻辑。
MQ事务消息（最终一致性）
消息发送一致性：是指产生消息的业务动作与消息发送的一致。也就是说，如果业务操作成功，那么由这个业务操作所产生的消息一定要成功投递出去(一般是发送到
kafka、rocketmq、rabbitmq等消息中间件中)，否则就丢消息。
支持事务消息的MQ，其支持事务消息的方式采用类似于二阶段提交。
基于 MQ 的分布式事务方案其实是对本地消息表的封装，将本地消息表基于 MQ 内部，其他方面的协议基本与本地消息表一致。
条件：
- 需要补偿逻辑
- 业务处理逻辑需要幂等
处理流程：
c) 消费者向MQ发送half消息。
d) MQ Server将消息持久化后，向发送方ack确认消息发送成功。
e) 消费者开始执行事务逻辑。
f) 消费者根据本地事务执行结果向MQ Server提交二次确认或者回滚。
g) MQ Server收到commit状态则将half消息标记可投递状态。
h) 服务提供者收到该消息，执行本地业务逻辑。返回处理结果。
优缺点：
优点：
- 消息数据独立存储，降低业务系统与消息系统之间的耦合。
- 吞吐量优于本地消息表方案。
缺点：
- 一次消息发送需要两次网络请求(half消息 + commit/rollback)。
- 需要实现消息回查接口。
最大努力通知与可靠消息一致性有什么不同
解决方案思想不同
可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知 方来保证。
最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接 收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。
两者的业务场景不同
可靠消息一致性关注的是交易过程的事务一致，以异步的方式完成交易。
最大努力通知关注的是交易后的通知事务，即将交易结果可靠的通知出去。
技术解决方案不同
可靠消息一致性要解决消息从发出到接收的一致性，即消息发出并且被接收到。
最大努力通知无法保证消息从发出到接收的一致性，只提供消息接收的可靠性机制。可靠机制是，最大努力的将消 息通知给接收方，当消息无法被接收方接收时，由接收方主动查询消息（业务处理结果）。
Saga事务模型（最终一致性）
Saga模式是一种分布式异步事务，一种最终一致性事务，是一种柔性事务，有两种不同的方式来实现saga事务，最流行的两种方式是：
事件/编排Choreography：没有中央协调器（没有单点风险）时，每个服务产生并聆听其他服务的事件，并决定是否应采取行动
该实现第一个服务执行一个事务，然后发布一个事件。该事件被一个或多个服务进行监听，这些服务再执行本地事务并发布（或不发布）新的事件，当最后一个服务执行本地事务并且不发布任何事件时，意味着分布式事务结束，或者它发布的事件没有被任何Saga参与者听到都意味着事务结束。
处理流程：
- 订单服务保存新订单，将状态设置为pengding挂起状态，并发布名为ORDER_CREATED_EVENT的事件。
- 支付服务监听ORDER_CREATED_EVENT，并公布事件BILLED_ORDER_EVENT。
- 库存服务监听BILLED_ORDER_EVENT，更新库存，并发布ORDER_PREPARED_EVENT。
- 货运服务监听ORDER_PREPARED_EVENT，然后交付产品。最后，它发布ORDER_DELIVERED_EVENT。
- 最后，订单服务侦听ORDER_DELIVERED_EVENT并设置订单的状态为concluded完成。
假设库存服务在事务过程中失败了。进行回滚：
- 库存服务产生PRODUCT_OUT_OF_STOCK_EVENT
- 订购服务和支付服务会监听到上面库存服务的这一事件：
- ① 支付服务会退款给客户。
- ② 订单服务将订单状态设置为失败。
优点：事件/编排是实现Saga模式的自然方式; 它很简单，容易理解，不需要太多的努力来构建，所有参与者都是松散耦合的，因为他们彼此之间没有直接的耦合。如果您的事务涉及2至4个步骤，则可能是非常合适的。
命令/协调orchestrator：中央协调器负责集中处理事件的决策和业务逻辑排序
saga协调器orchestrator以命令/回复的方式与每项服务进行通信，告诉他们应该执行哪些操作。
订单服务保存pending状态，并要求订单Saga协调器（简称OSO）开始启动订单事务。
OSO向收款服务发送执行收款命令，收款服务回复Payment Executed消息。
OSO向库存服务发送准备订单命令，库存服务将回复OrderPrepared消息。
OSO向货运服务发送订单发货命令，货运服务将回复Order Delivered消息。
OSO订单Saga协调器必须事先知道执行“创建订单”事务所需的流程(通过读取BPM业务流程XML配置获得)。如果有任何失败，它还负责通过向每个参与者发送命令来撤销之前的操作来协调分布式的回滚。当你有一个中央协调器协调一切时，回滚要容易得多，因为协调器默认是执行正向流程，回滚时只要执行反向流程即可。
优点：
- 避免服务之间的循环依赖关系，因为saga协调器会调用saga参与者，但参与者不会调用协调器。
- 集中分布式事务的编排。
- 只需要执行命令/回复(其实回复消息也是一种事件消息)，降低参与者的复杂性。
- 在添加新步骤时，事务复杂性保持线性，回滚更容易管理。
- 如果在第一笔交易还没有执行完，想改变有第二笔事务的目标对象，则可以轻松地将其暂停在协调器上，直到第一笔交易结束。
分布式事务对比分析
2PC 最大的诟病是一个阻塞协议。RM在执行分支事务后需要等待TM的决定，此时服务会阻塞并锁定资源。由于其阻塞机制和最差时间复杂度高， 因此，这种设计不能适应随着事务涉及的服务数量增加而扩展的需要，很难用于并 发较高以及子事务生命周期较长 (long-running transactions) 的分布式服务中。
如果拿TCC事务的处理流程与2PC两阶段提交做比较，2PC通常都是在跨库的DB层面，而TCC则在应用层面的处理，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据操作的粒度，使得降低锁冲突、提高吞吐量成为可能。而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现 try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。典型的使用场景：登录送优惠券等。
可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后，同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响，并实现了两个服务的解耦。典型的使用场景：注册送积分，登录送优惠券等。
最大努力通知是分布式事务中要求最低的一种，适用于一些最终一致性时间敏感度低的业务；允许发起通知方处理业 务失败，在接收通知方收到通知后积极进行失败处理，无论发起通知方如何处理结果都会不影响到接收通知方的后续处理；发起通知方需提供查询执行情况接口，用于接收通知方校对结果。典型的使用场景：银行通知、支付结果 通知等。
在条件允许的情况下，我们尽可能选择本地事务单数据源，因为它减少了网络交互带来的性能损耗，且避免了数据弱一致性带来的种种问题。若某系统频繁且不合理的使用分布式事务，应首先从整体设计角度观察服务的拆分是否 合理，是否高内聚低耦合？是否粒度太小？分布式事务一直是业界难题，因为网络的不确定性，而且我们习惯于拿 分布式事务与单机事务ACID做对比。
无论是数据库层的XA、还是应用层TCC、可靠消息、最大努力通知等方案，都没有完美解决分布式事务问题，它们 不过是各自在性能、一致性、可用性等方面做取舍，寻求某些场景偏好下的权衡。
分布式事务具体的实现框架
2PC的解决方案
XA方案
2PC的传统方案是在数据库层面实现的，如Oracle、MySQL都支持2PC协议，为了统一标准减少行业内不必要的对接成本，需要制定标准化的处理模型及接口标准，
国际开放标准组织Open Group定义了分布式事务处理模型DTP（Distributed Transaction Processing Reference Model）。
DTP模型定义如下角色：
- AP(Application Program)：即应用程序，可以理解为使用DTP分布式事务的程序。
- RM(Resource Manager)：即资源管理器，可以理解为事务的参与者，一般情况下是指一个数据库实例，通过资源管理器对该数据库进行控制，资源管理器控制着分支事务。
- TM(Transaction Manager)：事务管理器，负责协调和管理事务，事务管理器控制着全局事务，管理事务生命周期，并协调各个RM。
为了让大家更明确XA方案的内容程，下面新用户注册送积分为例来说明：
全局事务是指分布式事务处理环境中，需要操作多个数据库共同完成一个工作，这个工作即是一个全局事务。
DTP模型定义TM和RM之间通讯的接口规范叫XA，简单理解为数据库提供的2PC接口协议，基于数据库的XA协议来实现2PC又称为XA方案。
以上三个角色之间的交互方式如下：
- TM向AP提供 应用程序编程接口，AP通过TM提交及回滚事务。
- TM交易中间件通过XA接口来通知RM数据库事务的开始、结束以及提交、回滚等。
整个2PC的事务流程涉及到三个角色AP、RM、TM。
AP指的是使用2PC分布式事务的应用程序；
RM指的是资源管理器，它控制着分支事务；
TM指的是事务管理器，它控制着整个全局事务。
- 在准备阶段RM执行实际的业务操作，但不提交事务，资源锁定；
- 在提交阶段TM会接受RM在准备阶段的执行回复，只要有任一个RM执行失败，TM会通知所有RM执行回滚操作，否则，TM将会通知所有RM提交该事务。
- 提交阶段结束资源锁释放。
XA方案的问题：
- 需要本地数据库支持XA协议。
- 资源锁需要等到两个阶段结束才释放，性能较差。
Atomikos
Atomikos在XA中作为一个事务管理器（TM）存在。
实现了JTA/XA规范中的事务管理器(Transaction Manager)应该实现的相关接口，如：
- UserTransaction实现是com.atomikos.icatch.jta.UserTransactionImp，用户只需要直接操作这个类
- TransactionManager实现是com.atomikos.icatch.jta.UserTransactionManager
- Transaction实现是com.atomikos.icatch.jta.TransactionImp
针对实现了JDBC规范中规定的实现了XADataSource接口的数据库连接池，以及实现了JMS规范的MQ客户端提供一层封装。
JTA规范中，XADataSource、XAConnection等接口应该由资源管理器RM来实现，而Atomikos的作用是一个事务管理器(TM)，并不需要提供对应的实现。而Atomikos对XADataSource进行封装，只是为了方便与事务管理器整合。封装XADataSource的实现类为AtomikosDataSourceBean。典型的XADataSource实现包括：
- mysql官方提供的com.mysql.jdbc.jdbc2.optional.MysqlXADataSource
- 阿里巴巴开源的druid连接池，对应的实现类为com.alibaba.druid.pool.xa.DruidXADataSource
- tomcat-jdbc连接池提供的org.apache.tomcat.jdbc.pool.XADataSource
详细请参考：atomikos JTA/XA全局事务
Seata方案
传统2PC的问题在Seata中得到了解决，它通过对本地关系数据库的分支事务的协调来驱动完成全局事务，是工作在应用层的中间件。
主要优点是性能较好，且不长时间占用连接资源，它以高效并且对业务0侵入的方式解决微服务场景下面临的分布式事务问题，它目前提供AT模式(即2PC)及TCC模式的分布式事务解决方案。
Seata把一个分布式事务理解成一个包含了若干分支事务的全局事务。
全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。
此外，通常分支事务本身就是一个关系数据库的本地事务，
下图是全局事务与分支事务的关系图：
与 传统2PC 的模型类似，Seata定义了3个组件来协调分布式事务的处理过程：
- Transaction Coordinator (TC)： 事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收TM指令发起全局事务的提交与回滚，负责与RM通信协调各各分支事务的提交或回滚。
- Transaction Manager (TM)： 事务管理器，TM需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向TC发起全局提交或全局回滚的指令。
- Resource Manager (RM)： 资源管理器，控制分支事务，负责分支注册、状态汇报，并接收事务协调器TC的指令，驱动分支（本地）事务的提交和回滚。
以新注册送积分为例：
具体的执行流程如下：
1. 用户服务的 TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID。
2. 用户服务的 RM 向 TC 注册 分支事务，该分支事务在用户服务执行新增用户逻辑，并将其纳入 XID 对应全局事务的管辖。
3. 用户服务执行分支事务，向用户表插入一条记录。
4. 逻辑执行到远程调用积分服务时(XID 在微服务调用链路的上下文中传播)。
积分服务的RM 向 TC 注册分支事务，该分支事务执行增加积分的逻辑，并将其纳入 XID 对应全局事务的管辖。
5. 积分服务执行分支事务，向积分记录表插入一条记录，执行完毕后，返回用户服务。
6. 用户服务分支事务执行完毕。
7. TM 向 TC 发起针对 XID 的全局提交或回滚决议。
8. TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。
Seata实现2PC与传统2PC的差别：
- 架构层次方面
- 传统2PC方案的 RM 实际上是在数据库层，RM 本质上就是数据库自身，通过 XA 协议实现。
- 而Seata的 RM 是以jar包的形式作为中间件层部署在应用程序这一侧的。
- 两阶段提交方面
- 传统2PC无论第二阶段的决议是commit还是rollback，事务性资源的锁都要保持到Phase2完成才释放。
- 而Seata的做法是在Phase1 就将本地事务提交，这样就可以省去Phase2持锁的时间，整体提高效率。
seata需要安装事务协调器，详细请参考：seata实现2PC事务
|
参考： |
