【分布式】分布式事务处理

偏执的太偏执、 2023-03-02 10:27 35阅读 0赞

**一、本地事务与分布式事务：**

> **事务：**
> 
> 数据库事务(简称：事务，Transaction)是指数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。
> 
> 事务拥有以下四个特性，习惯上被称为ACID特性：
> 
>  *  **原子性(Atomicity)**：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
>  *  **一致性(Consistency)**：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态是指数据库中的数据应满足完整性约束。除此之外，一致性还有另外一层语义，就是事务的中间状态不能被观察到(这层语义也有说应该属于原子性)。
>  *  **隔离性(Isolation)**：多个事务并发执行时，一个事务的执行不应影响其他事务的执行，如同只有这一个操作在被数据库所执行一样。
>  *  **持久性(Durability)**：已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时，此操作将不可逆转。
> 
>  
> 
> **本地事务:**
> 
> 起初，事务仅限于对单一数据库资源的访问控制,架构服务化以后，事务的概念延伸到了服务中。倘若将一个单一的服务操作作为一个事务，那么整个服务操作只能涉及一个单一的数据库资源,这类基于单个服务单一数据库资源访问的事务，被称为本地事务(Local Transaction)。
> 
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70]
> 
> **分布式事务:**
> 
>  分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上,且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
> 
>  最早的分布式事务应用架构很简单，不涉及服务间的访问调用，仅仅是服务内操作涉及到对多个数据库资源的访问。
> 
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 1]
> 
>  当一个服务操作访问不同的数据库资源，又希望对它们的访问具有事务特性时，就需要采用分布式事务来协调所有的事务参与者。
> 
>  对于上面介绍的分布式事务应用架构，尽管一个服务操作会访问多个数据库资源，但是毕竟整个事务还是控制在单一服务的内部。如果一个服务操作需要调用另外一个服务，这时的事务就需要跨越多个服务了。在这种情况下，起始于某个服务的事务在调用另外一个服务的时候，需要以某种机制流转到另外一个服务，从而使被调用的服务访问的资源也自动加入到该事务当中来。下图反映了这样一个跨越多个服务的分布式事务：
> 
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 2]
> 
>  如果将上面这两种场景(一个服务可以调用多个数据库资源，也可以调用其他服务)结合在一起，对此进行延伸，整个分布式事务的参与者将会组成如下图所示的树形拓扑结构。在一个跨服务的分布式事务中，事务的发起者和提交均系同一个，它可以是整个调用的客户端，也可以是客户端最先调用的那个服务。
> 
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 3]
> 
>  较之基于单一数据库资源访问的本地事务，分布式事务的应用架构更为复杂。在不同的分布式应用架构下，实现一个分布式事务要考虑的问题并不完全一样，比如对多资源的协调、事务的跨服务传播等，实现机制也是复杂多变。

## ##

### 二、分布式事务相关理论： ###

> **CAP定理：**
> 
> CAP定律是指的在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性）、三者不可得兼。
> 
>  *  一致性（C）：
> 
>    在分布式系统中的所有数据备份，在同一时刻是否同样的值（等同于所有阶段访问同一份最新的数据副本）
> 
>  *  可用性（A）：
> 
>   在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求（对数据更新具备高可用性）
> 
>  *  分区容错性（P）：
> 
>   以实际效果而言，分区相当于对通信的时限要求。系统如果不能再时限内达到数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
> 
>  
> 
> **BASE理论**
> 
> BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：
> 
> **既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。**
> 
> **Basically Available(基本可用)**：
> 
> 是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，但注意，这绝不等价系统不可用，比如：
> 
> （1）响应时间上的损失。正常情况下，一个在线搜索引擎需要0.5秒返回给用户相应的查询结果，但由于出现故障，查询结果的相应时间增加了1~2秒
> 
> （2）系统功能上的损失：正常情况下，在一个电子商务网站上购物时，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促销购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
> 
> **Soft state（软状态）：**
> 
> 什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。
> 
> 软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
> 
> **Eventually consistent（最终一致性）**
> 
> 最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

**三、分布式事务解决方案：**

> **基于XA协议的两阶段提交 2PC**
> 
> 首先我们来简要看下分布式事务处理的XA规范 ：
> 
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 4]
> 
> 可知XA规范中分布式事务有AP，RM，TM组成：
> 
> 其中应用程序(Application Program ，简称AP)：AP定义事务边界（定义事务开始和结束）并访问事务边界内的资源。
> 
> 资源管理器(Resource Manager，简称RM)：Rm管理计算机共享的资源，许多软件都可以去访问这些资源，资源包含比如数据库、文件系统、打印机服务器等。
> 
> 事务管理器(Transaction Manager ，简称TM)：负责管理全局事务，分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。
> 
> **二阶段协议:**
> 
>  *  **第一阶段**TM要求所有的RM准备提交对应的事务分支，询问RM是否有能力保证成功的提交事务分支，RM根据自己的情况，如果判断自己进行的工作可以被提交，那就对工作内容进行持久化，并给TM回执OK；否者给TM的回执NO。RM在发送了否定答复并回滚了已经完成的工作后，就可以丢弃这个事务分支信息了。
>  *  **第二阶段**TM根据阶段1各个RM prepare的结果，决定是提交还是回滚事务。如果所有的RM都prepare成功，那么TM通知所有的RM进行提交；如果有RM prepare回执NO的话，则TM通知所有RM回滚自己的事务分支。
>  *  也就是TM与RM之间是通过两阶段提 交协议进行交互的.
>  *  **优点：** 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）
>  *  **缺点：** 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。
>  *   
> 
>  **TCC补偿机制**
> 
> TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：
> 
>  *  Try 阶段主要是对业务系统做检测及资源预留
>  *  Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
>  *  Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
> 
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 5]
> 
> 例如： A要向 B 转账，思路大概是：
> 
>     我们有一个本地方法，里面依次调用 
>     1、首先在 Try 阶段，要先调用远程接口把 B和 A的钱给冻结起来。 
>     2、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。 
>     3、如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。
> 
>  *  **优点：** 相比两阶段提交，可用性比较强
>  *  **缺点：** 数据的一致性要差一些。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。
> 
>  
> 
> **消息最终一致性**
> 
> 消息最终一致性应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路是来源于ebay。我们可以从下面的流程图中看出其中的一些细节：
> 
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 6]
> 
> 基本思路就是：
> 
> 消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。
> 
> 消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
> 
> 生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。
> 
>  *  **优点：** 一种非常经典的实现，避免了分布式事务，实现了最终一致性。
>  *  **缺点：** 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70]: /images/20230208/466a1cf45ba747ad9fcd42ac2a7286e1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 1]: /images/20230208/ada71317dcee42c29ab620b0757e3b5e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 2]: /images/20230208/31bc0b9bf7854c6c860e4b7e4cc67aef.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 3]: /images/20230208/5cf19cc5ebea48d8a4b0df07f7e3b035.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 4]: /images/20230208/eca32493214e4b11b58dcbace1d042e9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 5]: /images/20230208/705d9b482ca14905b1cd10759bba493b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpbWVndXlz_size_16_color_FFFFFF_t_70 6]: /images/20230208/3e895dfd402744f5a2696c3e13f8af0a.png