来源头条作者:極分享
分布式事务
对于网上购物的每一笔订单来说，电商平台一般都会有两个核心步骤：一是订单业务下订单操作，二是库存扣减操作。
通常，这两个业务会运行在不同的机器上，甚至是运行在不同区域的机器上。针对同一笔订单，当且仅当订单操作和减库存操作一致时，才能保证交易的正确性。也就是说一笔订单，只有这两个操作都完成，才能算做处理成功，否则处理失败，充分体现了“All or nothing”的思想。
在分布式领域中，这个问题就是分布式事务的问题。
1、分布式事务简介
起初，事务仅限于对单一数据库资源的访问控制。架构服务化以后，事务的概念延伸到了服务中。
倘若将一个单一的服务操作作为一个事务，那么整个服务操作只能涉及一个单一的数据库资源。这类
基于单个服务单一数据库资源访问的事务，被称为本地事务（Local Transaction）
。
本地事务主要限制在单个会话内，不涉及多个数据库资源。但是在
基于SOA（Service-Oriented Architecture，面向服务架构）的分布式应用环境下，越来越多的应用要求对多个数据库资源、多个服务的访问都能纳入到同一个事务当中
，分布式事务应运而生
。
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
例如在大型电商系统中，下单接口通常会扣减库存、减去优惠、生成订单 id, 而订单服务与库存、优惠、订单 id 都是不同的服务，下单接口的成功与否，不仅取决于本地的 db 操作，而且依赖第三方系统的结果，这时候分布式事务就保证这些操作要么全部成功，要么全部失败。
本质上来说，分布式事务就是为了保证不同数据库的数据一致性
。
最早的分布式事务应用架构很简单，不涉及服务间的访问调用，仅仅是服务内操作涉及到对多个数据库资源的访问。当一个服务操作访问不同的数据库资源，又希望对它们的访问具有事务特性时，就需要采用分布式事务来协调所有的事务参与者。如果一个服务操作需要调用另外一个服务，这时的事务就需要跨越多个服务了。在这种情况下，起始于某个服务的事务在调用另外一个服务的时候，需要以某种机制流转到另外一个服务，从而使被调用的服务访问的资源也自动加入到该事务当中来。
整个分布式事务的参与者组成的拓扑结构
较之基于单一数据库资源访问的本地事务，分布式事务的应用架构更为复杂。在不同的分布式应用架构下，实现一个分布式事务要考虑的问题并不完全一样，比如对多资源的协调、事务的跨服务传播等，实现机制也是复杂多变。尽管有这么多工程细节需要考虑，但分布式事务最核心的还是其 ACID 特性。
2、XA协议与2PC
1）XA协议
最早的分布式事务模型是 X/Open 国际联盟提出的 X/Open Distributed Transaction Processing（DTP）模型，也就是大家常说的 X/Open XA 协议，简称XA 协议。
XA 协议描述了 TM 与 RM 之间的接口，允许多个资源在同一分布式事务中访问。
DTP 模型中包含一个全局事务管理器（TM，Transaction Manager）和多个资源管理器（RM，Resource Manager）。
全局事务管理器负责管理全局事务状态与参与的资源，协同资源一起提交或回滚；资源管理器则负责具体的资源操作。
XA协议协作机制
应用程序（Application Program，简称AP）：AP定义事务边界（定义事务开始和结束）并访问事务边界内的资源。
资源管理器（Resource Manager，简称RM）：RM管理计算机共享的资源，资源即数据库等。
事务管理器（Transaction Manager，简称TM）：负责管理全局事务，分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。
基于 DTP 模型的分布式事务流程大致如下：
应用程序（AP，Application）向 TM 申请开始一个全局事务。
针对要操作的 RM，AP 会先向 TM 注册（TM 负责记录 AP 操作过哪些 RM，即分支事务），TM 通过 XA 接口函数通知相应 RM 开启分布式事务的子事务，接着 AP 就可以对该 RM 管理的资源进行操作。
当 AP 对所有 RM 操作完毕后，AP 根据执行情况通知 TM 提交或回滚该全局事务，TM 通过 XA 接口函数通知各个 RM 完成操作。TM 会先要求各个 RM 做预提交，所有 RM 返回成功后，再要求各个 RM 正式提交，XA 协议要求，一旦 RM 预提交成功，则后续的正式提交也必须能成功；如果任意一个 RM 预提交失败，则 TM 通知各 RM 回滚。
所有 RM 提交或回滚完成后，全局事务结束。
2）2PC
XA 协议使用 2PC（Two Phase Commit，两阶段提交）原子提交协议来保证分布式事务原子性。
两阶段提交是指将提交过程分为两个阶段，即准备阶段（投票阶段）和提交阶段（执行阶段）：
准备阶段：TM 向每个 RM 发送准备消息。如果 RM 的本地事务操作执行成功，则返回成功；如果 RM 的本地事务操作执行失败，则返回失败。
提交阶段：如果 TM 收到了所有 RM 回复的成功消息，则向每个 RM 发送提交消息；否则发送回滚消息；RM 根据 TM 的指令执行提交或者回滚本地事务操作，释放所有事务处理过程中使用的锁资源。
3）2PC的不足
场景一：准备阶段失败(业务一阶段)
如上图描述，在业务的第一阶段，在向资源管理器2发布准备命令时，出现了准备资源失败的情况，那么就需要在第二阶段时候，想资源管理器1与资源管理器2发起回滚操作。
业务阻塞：
如果在资源管理器1发起准备操作并获取返回结果后，再向资源管理器2发起准备操作，此时资源管理器起2一直不返回，阻塞在此处，那么整个业务流程就无法向后推进，必须等待返回后才能进而业务的二阶段，也是说在处理时存在着阻塞问题
单点：
如果在事务管理器获取了资源管理器1与资源管理器2的准备就绪的逻辑后，在发起二阶段开始前，如果资源管理器宕机了，整个业务就无法继续推进，那么这里事务管理器TM就存在着单点问题。
场景二：提交阶段失败(业务二阶段)
如上图描述，在业务的第二阶段，在向资源管理器2发起提交时，会出现如下两种情况：
提交命令发出后，事务管理器宕机，整个事务状态无法知道是否完成，该问题再次说明事务管理器是单点的，无法保证业务。
提交命令发给资源管理器1，并成功提交，再发给资源管理器2后，由于网络问题对事务管理器2一直提交不成功，那么此时在整个分布式系统中，就存在了数据不一致（资源管理器1已经提交，资源管理器2无法提交）。
综上所述，2PC主要存在如下问题：
协调者单点问题：
如上描述，一旦事务管理器宕机，整个事务的状态无法保证，分布式事务无法推进；
同步阻塞问题：
在准备就绪后，如果参与事务的其他业务一直无法获取结果，那么就会导致资源无法释放，一直阻塞；
数据一致性问题：
如上在场景二中描述，如果资源管理器1提交了，再提交资源管理器2时出现网络超时，那么就会导致数据不一致；
说明一下，三阶段提交就是在两阶段提交的第二阶段中加入了超时机制与自动提交，但是本质上还是没有解决一致性的问题，故而在此不在赘述。
4）XA 协议的隔离性保证
XA 协议中没有描述如何实现分布式事务的隔离性，但是 XA 协议要求DTP 模型中的每个 RM 都要实现本地事务，也就是说，
基于 XA 协议实现的分布式事务的隔离性是由每个 RM 本地事务的隔离性来保证的
，当一个分布式事务的所有子事务都是隔离的，那么这个分布式事务天然的就实现了隔离性。
以 MySQL 来举例，MySQL 使用 2PL（Two-Phase Locking，两阶段锁）机制来控制本地事务的并发，保证隔离性。2PL 与 2PC 类似，也是将锁操作分为加锁和解锁两个阶段，并且保证两个阶段完全不相交。加锁阶段，只加锁，不放锁。解锁阶段，只放锁，不加锁。
如上图所示，在一个本地事务中，每执行一条更新操作之前，都会先获取对应的锁资源，只有获取锁资源成功才会执行该操作，并且一旦获取了锁资源就会持有该锁资源直到本事务执行结束。MySQL 通过这种 2PL 机制，可以保证在本地事务执行过程中，其他并发事务不能操作相同资源，从而实现了事务隔离。
XA 协议通常实现在数据库资源层
，直接作用于资源管理器上。因此，基于 XA 协议实现的分布式事务产品，无论是分布式数据库，还是分布式事务框架，对业务几乎都没有侵入，就像使用普通数据库一样。
XA 协议严格保障事务 ACID 特性，能够满足所有业务领域的功能需求，但是，这同样是一把双刃剑。由于隔离性的互斥要求，在事务执行过程中，所有的资源都被锁定，
只适用于执行时间确定的短事务
。同时，整个事务期间都是独占数据，对于热点数据的并发性能可能会很低，实现了分布式 MVCC 或乐观锁（optimistic locking）以后，性能可能会有所提升。
3、TCC
1）TCC模型
TCC（Try-Confirm-Cancel）分布式事务模型相对于 XA 等传统模型，其特征在于它不依赖资源管理器（RM）对分布式事务的支持，而是通过对业务逻辑的分解来实现分布式事务。
TCC 模型认为对于业务系统中一个特定的业务逻辑，其对外提供服务时，必须接受一些不确定性，即对业务逻辑初步操作的调用仅是一个临时性操作，调用它的主业务服务保留了后续的取消权。如果主业务服务认为全局事务应该回滚，它会要求取消之前的临时性操作，这就对应从业务服务的取消操作。而当主业务服务认为全局事务应该提交时，它会放弃之前临时性操作的取消权，这对应从业务服务的确认操作。每一个初步操作，最终都会被确认或取消。
因此，针对一个具体的业务服务，TCC 分布式事务模型需要业务系统提供三段业务逻辑：
初步操作 Try：完成所有业务检查，预留必须的业务资源。
确认操作 Confirm：真正执行的业务逻辑，不作任何业务检查，只使用 Try 阶段预留的业务资源。因此，只要 Try 操作成功，Confirm 必须能成功。另外，Confirm 操作需满足幂等性，保证一笔分布式事务有且只能成功一次。
取消操作 Cancel：释放 Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。
TCC 分布式事务模型包括三部分：
主业务服务：主业务服务为整个业务活动的发起方，服务的编排者，负责发起并完成整个业务活动。
从业务服务：从业务服务是整个业务活动的参与方，负责提供 TCC 业务操作，实现初步操作（Try）、确认操作（Confirm）、取消操作（Cancel）三个接口，供主业务服务调用。
业务活动管理器：业务活动管理器管理控制整个业务活动，包括记录维护 TCC 全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时调用所有从业务服务的 Confirm 操作，在业务活动取消时调用所有从业务服务的 Cancel 操作。
2）TCC流程
一个完整的 TCC 分布式事务流程如下：
1.主业务服务首先开启本地事务；
2.主业务服务向业务活动管理器申请启动分布式事务主业务活动；
3.然后针对要调用的从业务服务，主业务活动先向业务活动管理器注册从业务活动，然后调用从业务服务的 Try 接口；
4.当所有从业务服务的 Try 接口调用成功，主业务服务提交本地事务；若调用失败，主业务服务回滚本地事务；
5.若主业务服务提交本地事务，则 TCC 模型分别调用所有从业务服务的 Confirm 接口；若主业务服务回滚本地事务，则分别调用 Cancel 接口；
6.所有从业务服务的 Confirm 或 Cancel 操作完成后，全局事务结束。
3）TCC的原子性与隔离性
A：TCC 模型也使用 2PC 原子提交协议来保证事务原子性。Try 操作对应2PC 第一阶段准备（Prepare）；Confirm 对应 2PC 的二阶段提交（Commit），Cancel 对应 2PC 的二阶段回滚（Rollback），可以说 TCC 就是应用层的 2PC。
I：TCC 分布式事务模型仅提供两阶段原子提交协议，保证分布式事务的原子性。事务的隔离交给业务逻辑来实现。TCC 模型的隔离性思想就是通过业务的改造，在第一阶段结束之后，从底层数据库资源层面的加锁过渡为上层业务层面的加锁，从而释放底层数据库锁资源。
4）举个例子
假设商品库存为 100，购买数量为 2，这里检查和更新库存的同时，冻结用户购买数量的库存，同时创建订单，订单状态为待确认。
Try阶段全部服务执行成功，进入Confirm阶段。
Try阶段没有全部服务执行成功，进入Cancel阶段。
5）TCC的优缺点小结
TCC 事务机制相对于传统事务机制（X/Open XA），有以下优点：
性能提升：让应用自己定义数据操作的粒度，使得降低锁冲突、不会锁定整个资源，提高吞吐量。
适用范围广：基于业务实现，TCC 可以跨数据库，跨不同业务系统实现事务。
最终一致性：基于 Confirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的最终一致性。
可靠性：解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。
缺点：
TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。
这三个操作方法的实现有一定难度，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。
