分布式事务专题总结

1. 分布式事务概念

分布式事务:顾名思义就是要在分布式系统中实现事务，它其实是由多个本地事务组合而成。

产生的原因：

1. 跨服务的事务
2. 跨数据库的事务

2. 分布式事务定律

分布式事务的解决是个难题，目前分布式事务存在两大理论依据。

1. CAP定律
2. BASE理论

2.1 CAP定律

指：在一个分布式系统中，C一致性、A可用性、P分区容错性，三者不可兼得。

• C一致性
  多服务节点下，各个服务节点数据要求一致。

• A可用性
  多服务节点下，各个服务节点只要一收到请求，就能立即给出响应返回正确结果。

• P分区容错性
  多服务节点下，不能因为网络波动问题从而导致无法通信。

为什么无法避免分区容错性P？
分区：大多数分布式系统都分布在多个子网络，每个子网络这里就叫它为一个区。比如一台服务在北京，另一台服务在上海。

结论：对于这种网络波动，我们无法完美避免，所以，可以认为CAP定律里面的P总是成立。

为什么一致性C和可用性A只能保证其中一种？

• C一致性（多服务节点(数据库)情况下，要保证多个服务的数据是一样的。）

举例：1. 有多台服务节点，他们数据现在是一致的。比如定义了 a = 1;2. 用户现在要修改a的值，由于负载均衡，他被带来到服务节点1，修改了a = 2;3. 用户现在要看a的最新值，由于负载均衡，此时他被带来到服务节点2，得出a的值为1;这就是数据不一致的问题。解决思路：当用户在服务节点1修改a = 2时，它发一条消息给其他节点，让其他节点也跟它一样将a改为2。如此一来，就能保证数据的一致性。

• A可用性（多服务节点(数据库)情况下，只要接收到用户请求，就立马告诉用户结果。）

如果你要保证一致性，看看上面是怎么保证一致性的。当我们在修改a=2时，他需要发送一条信息给其他节点，从而达到各个服务节点数据一致，那么在发送信息给其他节点这段时间或其他节点收到消息还没改a的值时，其他节点恰好接收到了请求，怎么办？CA的矛盾点：如果要满足一致性【某个节点更新a的值后要其他节点也同样更新(每个事务都成功，没成功前查数据就获取不到)】，那么就不能满足可用性。如果满足可用性【不管其他节点更没更新a的值，只要用户一发请求，就把当前值告诉用户】，那么就不能满足一致性。

怎么取舍AP 还是 CP
分布式事务最看重的是数据一致性与高可用性，要保证数据一致才是重中之重，只要能保证这一点，可以容忍数据短暂不一致，只要最终是一致的就行。基于这种思想衍生出了BASE理论

2. BASE理论

它是基于CAP定律演化而来的。是对CAP中一致性和可用性权衡后的一种结果。

• BA 基本可用，不要求高可用，允许出现一些不可预知的故障，可以晚一点点给出响应。

• S 软状态，允许数据存在中间状态（即：允许不同服务节点之间数据同步存在延时）。

• E 最终一致性，允许经过一段时间的数据同步，让数据最终达到一致。

核心思想：允许出现短暂不一致性，只要达到最终一致性即可。也不需要高可用，只要保证基本可用即可。

3. 分布式事务的解决方案

基于分布式事务理论思想，衍生出了很多的分布式事务解决方案：

• 基于XA协议的两段提交
• TCC
• 可靠消息最终一致性（借助消息中间件MQ来实现）
• Seata框架

3.1 基于XA协议的两段提交

什么是XA协议？
DTP：1994年由X/OPEN组织定义的用于处理分布式事务的DTP模型，该模型由如下几个角色

应用程序(AP)          我们的微服务
事务管理器(TM)        全局事务管理者
资源管理器(RM)        数据库
通信资源管理器(CRM)    TM与RM之间的通信中间件，用于通知各个本地事务实现思路：在该模型中，一个分布式事务将被拆分成多个本地事务，运行在不同的AP和RM上。一个分布式事务的成功实现，要求拆分成的所有本地事务全实现成功。因为在本地上，所以本地事务的ACID就能很好解决与实现。但是分布式事务是要求所有本地事务同时执行成功，若有一个失败，则全部回滚。但是各个本地事务间如何知道其他事务是否执行完毕呢？因此，需要一个CRM来通知各个本地事务，事务的状态。想让CRM来做这个事，那么你就得按照CRM的要求来，按照人家的规范来开启你的本地事务。不然你A服务你搞个mysql，B服务你搞个Oracle，大家没有统一的规范，CRM就帮我们实现不了这个事。XA：就是CRM与TM之间联系的接口规范。定义了用于 通知事务开始，提交，终止，回滚等接口。各个数据库厂商都必须实现这些接口。

基于XA协议思想的两阶段提交方案
基于XA协议的两段提交：就是基于DTP这种思想衍生出来的，将全局事务拆分成两个阶段执行。整个过程中，需要一个协调者，用于协调本地事物。

实现步骤：

• 阶段一：准备阶段，各个本地事务完成本地事务的准备工作。【去执行一次，但不真正提交，将能否成功执行本地事务的结果反馈给协调者(TC)】
• 阶段二：执行阶段，根据上一阶段执行结果，通知各个本地事务进行提交还是回滚。

缺点：

• 单点故障问题：第一阶段成功，此时协调者挂了，还没告诉二阶段该怎么做。
• 数据阻塞问题：各个本地事务开启的时候，都要对数据加锁。此时不能对数据进行操作，包括查询操作。若某个本地事务先执行完，还得等其他事务执行完毕，得到最终结果看是否全部本地事务执行完毕，待协调者第二阶段的处理。

3.2 TCC

TCC：这种解决方案解决了两阶段提交方案的部分痛点，他的理论基础是基于BASE理论实现的，解决了两阶段的数据阻塞问题，达到的效果的最终一致性。

TCC：三个单词的缩写。

• Try：资源的检测和预留
• Confirm：执行的业务的提交
• Cancel：补偿

实现步骤：

• 准备阶段(try)：资源的检测和预留
• 执行阶段(confirm/cancel)：根据上一步的结果，判断下面执行的方法，若上一步都成功，则confirm。反之，则concel。

缺点：

• 代码侵入太严重，需要人为去实现各个阶段，如：一阶段的try功能，二阶段的confirm与cancel功能。
• 开发成本高，本来一个业务现在要去编写这么多复杂业务。
• 还要考虑安全问题，万一补偿的时候发生异常失败了呢。

具体实现原理：

• 需求：我们以下单业务中的扣减余额为例。假设账户A原本余额为100，需要余额扣减30元。

• 阶段一：余额检查，并冻结部分用户金额，此阶段执行完毕，事务已经提交。
  检查用户余额是否充足，若充足，再冻结部分金额(要扣减的金额)
  在账户表中新增冻结金额字段，值为30，余额不变100。此时查询来了余额应该告诉他是70。

• 阶段二：根据第一阶段的执行情况，执行二阶段的提交或回滚。
  提交(confirm)：真正的扣款，把冻结金额从余额里面扣除，冻结金额清空【将冻结金额值改为0，将余额改为70】
  补偿(cancel)：释放之前冻结的余额【真正的余额不变，将冻结金额的值改为0】
  

4. Seata框架

介绍：Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT（非侵入式）、TCC（侵入式）、SAGA（侵入式） 和 XA 事务模式（非侵入式），为用户打造一站式的分布式解决方案。

4.1 四种模式的特点

4.2 Seata术语

• TC - 事务协调者
  维护全局和分支事务的状态，驱动全局事务提交或回滚。

• TM - 事务管理器
  定义全局事务的范围：开始全局事务、提交或回滚全局事务。

• RM - 资源管理器
  管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

4.3 AT模式

概述：AT 模式是 Seata 创新的一种非侵入式的分布式事务解决方案，它是基于两阶段提交的演变。