目前大部分的互联网公司在设计整体架构的时候，都会按照业务模块，将系统拆分成很多小系统，例如订单系统、卡券系统、支付系统等等，简单来说，就是分而治之，这样每个人可以专注维护自己的代码。然后不同的小系统自己开发、测试和上线，都不会跟别人耦合在一起，可以自己独立进行，非常的方便，大大简化了大规模系统的开发成本。
然而有了多个子系统之后，分布式事务应该怎么来实现？下面就介绍一下分布式事务的几种实现方式。
一、分布式事务的概念
分布式事务指的是一个请求在多个系统的调用链当中如何确保数据一致。例如，一个支付请求，支付成功后，会回调请求订单系统修改订单状态，会回调请求卡券系统修改卡券状态。那么如果回调请求因为网络原因丢失了，可能出现用户支付了，订单仍然显示为未支付状态，卡券仍然在冻结中，无法置为已使用状态。
二、2PC/3PC/TCC等分布式事务协议
2PC两阶段提交协议
2PC是非常经典的强一致、中心化的原子提交协议，协议中定义了两类节点：一个中心化协调者节点和多个参与者节点。2PC分为两个阶段：
准备阶段：
1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
2、各参与者执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。
3、如参与者执行成功，给协调者反馈YES，即可以提交；如执行失败，给协调者反馈NO，即不可提交。
提交阶段：
（所有参与者均反馈YES）
1、协调者向所有参与者发出正式提交事务的请求（即Commit请求）。
2、参与者执行Commit请求，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。
（任何一个参与者反馈NO）
1、协调者向所有参与者发出回滚请求（即Rollback请求）。
2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。
2PC两阶段提交过程中会遇到一些问题：
1、性能问题。从流程上我们可以看得出，其最大缺点就在于它的执行过程中间，节点都处于阻塞状态。各个操作数据库的节点此时都占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知进行全局提交，参与者进行本地事务提交后才会释放资源。这样的过程会比较漫长，对性能影响比较大。
2、协调者单点故障问题。事务协调者是整个XA模型的核心，一旦事务协调者节点挂掉，会导致参与者收不到提交或回滚的通知，从而导致参与者节点始终处于事务无法完成的中间状态。
3、丢失消息导致的数据不一致问题。在第二个阶段，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就会导致节点间数据的不一致问题。
3PC三阶段提交协议
2PC的改进版本，其在两阶段提交的基础上增加了CanCommit阶段，并引入了超时机制。一旦事务参与者迟迟没有收到协调者的Commit请求，就会自动进行本地commit，这样相对有效地解决了协调者单点故障的问题。。
阶段1：CanCommit
1、协调者向所有参与者发出包含事务内容的CanCommit请求，询问是否可以提交事务，并等待所有参与者答复。
2、参与者收到CanCommit请求后，如果认为可以执行事务操作，则反馈YES并进入预备状态，否则反馈NO。
阶段2：PreCommit
事务预提交：（所有参与者均反馈YES时）
1、协调者向所有参与者发出PreCommit请求，进入准备阶段。
2、参与者收到PreCommit请求后，执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。
3、各参与者向协调者反馈Ack响应或No响应，并等待最终指令。
中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）
1、协调者向所有参与者发出abort请求。
2、无论收到协调者发出的abort请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。
阶段3：do Commit
提交事务：（所有参与者均反馈Ack响应时）
1、如果协调者处于工作状态，则向所有参与者发出do Commit请求。
2、参与者收到do Commit请求后，会正式执行事务提交，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。
中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）
1、如果协调者处于工作状态，向所有参与者发出abort请求。
2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。
TCC补偿事务协议
TCC 将事务提交分为 Try - Confirm - Cancel 3个操作。
1、Try：预留业务资源/数据效验
2、Confirm：确认执行业务操作
3、Cancel：取消执行业务操作
TCC事务处理流程和 2PC 二阶段提交类似，不过 2PC通常都是在跨库的DB层面，而TCC本质就是一个应用层面的2PC。
三、分布式事务使用场景
1、基于消息实现的事务
基于消息实现的事务适用于分布式事务的提交或回滚只取决于事务发起方的业务需求，其他数据源的数据变更跟随发起方进行的业务场景。
2、补偿实现的事务
基于消息实现的事务并不能解决所有的业务场景，例如以下场景：某笔订单完成时，同时扣掉用户的现金。
这里事务发起方是管理订单库的服务，但对整个事务是否提交并不能只由订单服务决定，因为还要确保用户有足够的钱，才能完成这笔交易，而这个信息在管理现金的服务里。这里我们可以引入基于补偿实现的事务，其流程如下：
- 创建订单数据，但暂不提交本地事务
- 订单服务发送远程调用到现金服务，以扣除对应的金额
- 上述步骤成功后提交订单库的事务
以上这个是正常成功的流程，异常流程需要回滚的话，将额外发送远程调用到现金服务以加上之前扣掉的金额。
以上流程比基于消息队列实现的事务的流程要复杂，同时开发的工作量也更多：
- 编写订单服务里创建订单的逻辑
- 编写现金服务里扣钱的逻辑
- 编写现金服务里补偿返还的逻辑
可以看到，该事务流程相对于基于消息实现的分布式事务更为复杂，需要额外开发相关的业务回滚方法，也失去了服务间流量削峰填谷的功能。但其仅仅只比基于消息的事务复杂多一点，若不能使用基于消息队列的最终一致性事务，那么可以优先考虑使用基于补偿的事务形态。
3、2PC事务
其适用于参与者较少，单个本地事务执行时间较少，并且参与者自身可用性很高的场景，否则，其很可能导致性能下降严重。
扫一扫
1008
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
