吊打面试关之分布式事务

1、什么是分布式事务

       我认为就是在同一个系统同一业务操作访问不同服务器能做到全部成功或全部失败的一种机制（解决方案），说白了就是保证数据一致性。

       场景： 在大型电商系统中，下单接口通常会扣减库存、减去优惠、生成订单 id, 而订单服务与库存、优惠、订单 id 都是不同的服务，下单接口的成功与否，不仅取决于本地的 db 操作，而且依赖第三方系统的结果，要么全部成功，要么全部失败。

       解决方案： 要么一致监控整个业务是否成功，要么反复重试（补偿）操作。

       基本原理：
              1、CAP 原则（指的是在一个分布式系统中， Consistency（一致性： 在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本））、 Availability（可用性： 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性））、Partition tolerance（分区容错性： 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择），三者不可得兼）
              2、BASE 理论（基本可用 Basically Available： 分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用，软状态 Soft State： 允许系统存在中间状态，而该中间状态不会影响系统整体可用性，最终一致性 Eventual Consistency： 系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，核心思想是即便无法做到强一致性，但应该采用适合的方式保证最终一致性）

---

2、有哪些分布式事务解决方案？

       1. 两阶段提交/XA；
       2. TCC；
       3. 本地消息表；
       4. 可靠消息最终一致性；
       5. 尽最大努力通知；

---

3、各种分布式事务解决方案优缺点？

3.1、两阶段提交/XA（DTP）

解释： 顾名思义就是要分两步提交。存在一个负责协调各个本地资源管理器的事务管理器，本地资源管理器一般是由数据库实现，事务管理器在第一阶段的时候询问各个资源管理器是否都就绪？如果收到每个资源的回复都是 yes，则在第二阶段提交事务，如果其中任意一个资源的回复是 no, 则回滚事务。

大致的流程：
       第一阶段（prepare）：事务管理器向所有本地资源管理器发起请求，询问是否是 ready 状态，所有参与者都将本事务能否成功的信息反馈发给协调者；
       第二阶段 (commit/rollback)：事务管理器根据所有本地资源管理器的反馈，通知所有本地资源管理器，步调一致地在所有分支上提交或者回滚。
缺点：
       1、同步阻塞：当参与事务者存在占用公共资源的情况，其中一个占用了资源，其他事务参与者就只能阻塞等待资源释放，处于阻塞状态。
       2、单点故障：一旦事务管理器出现故障，整个系统不可用
       3、数据不一致：在阶段二，如果事务管理器只发送了部分 commit 消息，此时网络发生异常，那么只有部分参与者接收到 commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。
       4、不确定性：当协事务管理器发送 commit 之后，并且此时只有一个参与者收到了 commit，那么当该参与者与事务管理器同时宕机之后，重新选举的事务管理器无法确定该条消息是否提交成功。
外部链接: DTP模式的实现

3.2、TCC

解释： 就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作；

大致的流程：
       Try 阶段：主要是对业务系统做检测及资源预留
       Confirm 阶段：主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
       Cancel 阶段：主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

优点：
       1、解决了跨服务的业务操作原子性问题，例如组合支付，订单减库存等场景非常实用。
       2、TCC的本质原理是把数据库的二阶段提交上升到微服务来实现，从而避免了数据库2阶段中锁冲突的长事务低性能风险。
       3、TCC异步高性能，它采用了try先检查，然后异步实现confirm，真正提交的是在confirm方法中。
缺点：
       1、对微服务的侵入性强，微服务的每个事务都必须实现try，confirm，cancel等3个方法，开发成本高，今后维护改造的成本也高。
       2、为了达到事务的一致性要求，try，confirm、cancel接口必须实现等幂性操作。（定时器+重试）
       3、由于事务管理器要记录事务日志，必定会损耗一定的性能，并使得整个TCC事务时间拉长，建议采用redis的方式来记录事务日志。

外部链接: TCC模式的实现

3.3、本地消息表

解释： 将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。

大致的流程：
       当系统 A 被其他系统调用发生数据库表更操作，首先会更新数据库的业务表，其次会往相同数据库的消息表中插入一条数据，两个操作发生在同一个事务中
       系统 A 的脚本定期轮询本地消息往 mq 中写入一条消息，如果消息发送失败会进行重试
       系统 B 消费 mq 中的消息，并处理业务逻辑。如果本地事务处理失败，会在继续消费 mq 中的消息进行重试，如果业务上的失败，可以通知系统 A 进行回滚操作

优点：
       1、容错机制比较完善；
缺点：
       1、消费者与生成者的接口都要支持幂等
       2、生产者需要额外的创建消息表
       3、需要提供补偿逻辑，如果消费者业务失败，需要生产者支持回滚操作

外部链接: 本地消息表的实现

---

3.4、可靠消息最终一致性

解释：* 将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。

大致的流程：
       A 系统先向 mq 发送一条 prepare 消息，如果 prepare 消息发送失败，则直接取消操作，如果消息发送成功，则执行本地事务
       如果本地事务执行成功，则想 mq 发送一条 confirm 消息，如果发送失败，则发送回滚消息
       B 系统定期消费 mq 中的 confirm 消息，执行本地事务，并发送 ack 消息。如果 B 系统中的本地事务失败，会一直不断重试，如果是业务失败，会向 A 系统发起回滚请求
       mq 会定期轮询所有 prepared 消息调用系统 A 提供的接口查询消息的处理情况，如果该 prepare 消息本地事务处理成功，则重新发送 confirm 消息，否则直接回滚该消息

优点：
       1、RocketMQ直接支持；
缺点：
       1、目前只有RocketMQ支持
       2、提供的接口需要支持幂等性

外部链接: MQ实现分布式事务

---

3.5、尽最大努力通知

解释：* 最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果 不影响主动方的处理结果。

大致的流程：
       系统 A 本地事务执行完之后，发送个消息到 MQ；
       这里会有个专门消费 MQ 的服务，这个服务会消费 MQ 并调用系统 B 的接口；
       要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B, 反复 N 次，最后还是不行就放弃。

优点：
       1、实现最终一致性
       2、系统结偶
缺点：
       1、适用于一致性要求不高的系统

外部链接: 最大努力通知实现

---

4、往期佳文

4.1、面试系列

1、吊打面试官之一面自我介绍
2、吊打面试官之一面项目介绍
3、吊打面试官之一面系统架构设计
4、吊打面试官之一面你负责哪一块

······持续更新中······

---

4.2、技术系列

1、吊打面试官之分布式会话
2、吊打面试官之分布式锁
3、吊打面试官之乐观锁
4、吊打面试官之幂等性问题

······持续更新中······

---