吊打面试关之分布式事务

今天药忘吃喽~ 2022-11-12 02:51 273阅读 0赞

### 吊打面试官之分布式事务 ###

*   *  1、什么是分布式事务
     *  2、有哪些分布式事务解决方案？
     *  3、各种分布式事务解决方案优缺点？
     *   *  3.1、两阶段提交/XA（DTP）
         *  3.2、TCC
         *  3.3、本地消息表
         *  3.4、可靠消息最终一致性
         *  3.5、尽最大努力通知
     *  4、往期佳文
     *   *  4.1、面试系列
         *  4.2、技术系列

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

### 3.2、TCC ###

**解释：** 就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作；  
![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模式的实现][TCC 1]

### 3.3、本地消息表 ###

**解释：** 将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。  
![本地消息表][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70]  
大致的流程：  
       当系统 A 被其他系统调用发生数据库表更操作，首先会更新数据库的业务表，其次会往相同数据库的消息表中插入一条数据，两个操作发生在同一个事务中  
       系统 A 的脚本定期轮询本地消息往 mq 中写入一条消息，如果消息发送失败会进行重试  
       系统 B 消费 mq 中的消息，并处理业务逻辑。如果本地事务处理失败，会在继续消费 mq 中的消息进行重试，如果业务上的失败，可以通知系统 A 进行回滚操作

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

外部链接: [本地消息表的实现][Link 1]

--------------------

### 3.4、可靠消息最终一致性 ###

*解释：*\* 将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。  
![可靠消息最终一致性][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 1]  
大致的流程：  
       A 系统先向 mq 发送一条 prepare 消息，如果 prepare 消息发送失败，则直接取消操作，如果消息发送成功，则执行本地事务  
       如果本地事务执行成功，则想 mq 发送一条 confirm 消息，如果发送失败，则发送回滚消息  
       B 系统定期消费 mq 中的 confirm 消息，执行本地事务，并发送 ack 消息。如果 B 系统中的本地事务失败，会一直不断重试，如果是业务失败，会向 A 系统发起回滚请求  
       mq 会定期轮询所有 prepared 消息调用系统 A 提供的接口查询消息的处理情况，如果该 prepare 消息本地事务处理成功，则重新发送 confirm 消息，否则直接回滚该消息

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

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

--------------------

### 3.5、尽最大努力通知 ###

*解释：*\* 最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果 不影响主动方的处理结果。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 2]  
大致的流程：  
       系统 A 本地事务执行完之后，发送个消息到 MQ；  
       这里会有个专门消费 MQ 的服务，这个服务会消费 MQ 并调用系统 B 的接口；  
       要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B, 反复 N 次，最后还是不行就放弃。

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

外部链接: [最大努力通知实现][Link 2]

--------------------

## 4、往期佳文 ##

### 4.1、面试系列 ###

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

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

--------------------

### 4.2、技术系列 ###

1、[吊打面试官之分布式会话][Link 7]  
2、[吊打面试官之分布式锁][Link 8]  
3、[吊打面试官之乐观锁][Link 9]  
4、[吊打面试官之幂等性问题][Link 10]

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

--------------------

[XA]: /images/20221022/d827a8bbd2024e9fad831838e13994c8.png
[DTP]: https://blog.csdn.net/liaomin416100569/article/details/78651525
[TCC]: /images/20221022/36da945847f54637b8129d7931fdfc31.png
[TCC 1]: https://blog.csdn.net/github_35735591/article/details/111063998
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70]: /images/20221022/e897288a019e4276a888df1f81a6cc75.png
[Link 1]: https://segmentfault.com/a/1190000023286365
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 1]: /images/20221022/f1599b90793d43f8a112fd5ebe59727c.png
[MQ]: https://zhuanlan.zhihu.com/p/115924952
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 2]: /images/20221022/641dd72a818d4f4b9ccb1c9769793f57.png
[Link 2]: https://blog.csdn.net/anbang713/article/details/108309909
[Link 3]: https://blog.csdn.net/wtyicy/article/details/114933478
[Link 4]: https://blog.csdn.net/wtyicy/article/details/114983053
[Link 5]: https://blog.csdn.net/wtyicy/article/details/115005012
[Link 6]: https://blog.csdn.net/wtyicy/article/details/115064661
[Link 7]: https://blog.csdn.net/wtyicy/article/details/114685293
[Link 8]: https://blog.csdn.net/wtyicy/article/details/114915987
[Link 9]: https://blog.csdn.net/wtyicy/article/details/114915177
[Link 10]: https://blog.csdn.net/wtyicy/article/details/114888754