分布式系统（二）分布式事务的理解

1.简介

1.1 什么是事务

数据库事务，就不过多说了，算是数据库里面的一个核心点，可以理解 ，我们操作数据库的一系列动作如果在一个事务中，这些操作要么全部执行，要么全部不执行； 一个事务是由事务开始和结束中间的全部数据库操作组成；

注：像是在MySQL里面 redo log 是保证事务提交的成功，undo 是保证事务回滚；

1.2 分布式事务

单机系统里面所有的操作可以理解成一个事务；但是随着服务的演变，在微服务分布式的架构中，服务之间调用可能会涉及到多个数据源，如何保证多个数据源之间的事务的一致性； 多个数据源的事务就可以理解为分布式事务；

2.分布式事务解决方案

分布式事务没有完美的解决方案；目前大致的思想有两种；

• 两阶段提交2pc
• 三阶段提交3pc （3pc 无法处理二阶段锁定资源的问题，只是减少锁定资源的时间）
• 消息队列+ 事件表
• LCN ：lock 锁定事务单元 Confirm 确认事务 ，Notify 通知事务

3 两阶段提交2pc

two-phase commit protocol 2PC ：强一致，中心化的原子提交协议，内部又两个角色

• 参与者节点（partcipant） ：支付系统 或者 订单系统, 也叫 资源拥有者 RM resource Manager ；
• 协调者节点（coordinator） ：判断参与者是否全部成功/失败 ，也叫 事务管理者 TM transaction Manager ；

用上面举例子成功流程

• 1.下单业务开始 分布式事务开始
• 2.支付系统支付，开始事务，锁定支付数据并修改，不提交
• 3.订单系统，开始事务， 锁定订单数据并修改，不提交
• 4.前两步骤都执行成功，两个步骤都提交对应事务
• 5.支付系统提交事务
• 6.订单系统提交事务
• 7.分布式事务完成

3.1 第一阶段 Prapare

协调者节点向所有节点询问是否可以执行提交操作；开始等待响应；开启各自服务和数据库的事务

3.2 第二阶段 Commit

阶段二：执行事务，所有节点返回同意，协调者会想参与者发出commit 请求

然后各自参与者的事务提交，释放锁定的资源，参与者和协调者发送完成消息，执行成功

两阶段提交2pc 所有节点正常返回成功执行流程

两阶段提交2pc 所有节点正常返回其中一个失败执行流程

阶段二：执行事务，所有节点返回同意，协调者会想参与者发出 rollback请求

然后各自参与者的事务回滚，释放锁定的资源，事务回滚完成后，参与者和协调者发送完成回滚完成消息， 结束整体事务

3.3 二阶段问题

其中最后每个节点提交或者回滚事务的操作由于服务或者网络的原因无法响应，资源就无法得到释放

缺陷：单点服务故障，程序进入阻塞(资源锁定，无法释放)

怎么处理？人工发现补偿，定时任务，脚本补偿

4 三阶段提交3pc

降低2pc 资源锁定的时间；在2pc 的时候系统执行的开始到结束都是锁定对应的数据资源的；

优化点：

• 第一阶段 Can Commit 资源不锁定
• TM RM 超时时间设定 超时可以RM 可以自己提交事务，不需要2pc 的Tm 同一决定带来的阻塞；

4.1 第一阶段 Can Commit

协调者向所有参与者发送提交请求，参与者如果可以提交就返回提交消息，否则返回投票中止消息

4.2 第二阶段 Pre Commit

协调者根据参与者的回答和超时机制，确定是否可以继续事务的preCommit。包括两种情况：

• 可以提交，协调者从所有的参与者收到投票提交消息，然后发出全部提交消息，进入下一阶段

• 中止事务，协调者从任何一个参与者处收到投票中止消息，或者等待超时之后，则发出全部中止消息，参与者执行事务的回滚。

4.3 第三阶段 Do Commit

此时会进行真正的事务提交阶段。这个阶段也可以分为两种情况，过程类似2PC的提交阶段，但是消息传递过程存在超时机制。超时RM 自己提交，这一点避免资源锁定过长；

重要总结：二阶段和三阶段提交总结！！！！！！！！！！！！！！！！！

可以看到二阶段和三阶段提交流程答题一致，三阶段相当于是在二阶段的第一步和第二部之间加了一个预先提交询问的机制；

在二阶段中，TM 通知RM 去回滚和提交 ，这个时候可能会一致阻塞，因为有节点由于网络问题的原因；

那这个时候三阶段就相当于先问一下各个RM 是否可以提交，第二部到第三部是比较快的；如果这个时候有人挂了，就直接发起分布式事务中存活节点的本地事务回滚就可以了(总而言之就是先问一下所有人，是不是都是正常的，正常的我才开始最后一步)；如果都正常的，节点都开始提交，正常情况下都可以完成各自事务，但是，也会出现节点不响应的情况；只是，前面也说了2->3 很快 ，减低资源锁定的时间；

5 .消息队列+ 事件表

流程拆分成异步执行策略方式

支付系统本地事务保证数据写入事件表和队列

订单系统保证消费到队列和修改订单表

达到修改数据一致性的问题；

6.LCN -LockConfirmNotify

感觉类似于2PC

• Lock： 锁定事务单元
• Confirm：确认事务
• Notify：通知事务 通知事务提交

总体类似与二阶段，不同是最后补偿的机制；

架构图

时序图

对应的框架实现

注：com.codingapi.txlcn 支持 LCN TCC TXC

7.TCC-TryConfirmCancel

• Try
• Confirm :
• Cancel

重要总结TCC 和LCN 事务总结 ！！！！！！！！！！！！

LCN 的大致原理是代理数据库连接 需要的分布式事务中连接有回滚模式，比如MySQL 这类数据的连接是带回滚的

TCC 使用与分布式事务中，多种数据源，有的数据源不具备回滚的功能，这个时候，是需要自己来实现confirmXXXX,cancelXXX的方法来操作的；

LCN 和 TCC 是可以混用的，不冲突，本质上都是可以回滚，一个是依赖于中间件的回滚，一个是代码对数据的回滚

8.分布式事务框架 Seate

Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务；

支持的事务模式 AT,TCC,SAGA,XA

注意： tx-lcn 中的TC 是Transaction Client ,Seata 中的TC 是Transaction coordinator；

9.AT 模式

两阶段 2PC提交协议的演变：需要分布式节点中数据库本地事务的支持

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

• 二阶段：
  • 提交异步化，非常快速地完成(各自RM 在一阶段已经完成)。
  • 回滚通过一阶段的回滚日志进行反向补偿。

本地锁和全局锁概念

• 一阶段本地事务提交前，需要确保先拿到 全局锁 。（一个服务的角度 本地事务sql ,执行sql ,获取全局锁（失败回滚），提交sql,提交全局）
• 拿不到 全局锁 ，不能提交本地事务。
• 拿 全局锁 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。
• 本地锁 ，数据库的锁 保证ACID ，全局锁 可以理解是分布式锁,保证全局事务的回滚

示例：

TM通知所有RM 回滚，如果支付系统RM 获取全局锁，并且回滚失败（DB 死了），订单系统RM会等不到全局锁，这个时候会有超时(获取不到全局锁)回滚；

9.Seate 的TCC

原有的TCC 是 Try 提交资源，Confirm确认,Cancel 资源逆操作

Seate 的TCC :TCC 模式，不依赖于底层数据资源的事务支持 ,是指支持把 自定义 的分支事务纳入到全局事务的管理中。

• 一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
• 二阶段 commit 行为：调用 自定义 的 commit 逻辑。
• 二阶段 rollback (cancel )行为：调用 自定义 的 rollback 逻辑。

TCC 问题：

• 空回滚：空try .try 没有执行，cancel执行 ，其他节点失败，其他节点还没有try 就cancel 了； 事务控制表
• 幂等问题：TC（事务协调者），没收到RM 的执行响应，多次执行cancel ,事务控制表
• 悬挂：悬挂是指因为网络问题，RM 开始没有收到 try 指令，但是执行了cancel 后try 有发送执行成功 ；事务控制表

附录

基于tx-lcn 架的搭建的分布式事务

TCC 问题：

• 空回滚：空try .try 没有执行，cancel执行 ，其他节点失败，其他节点还没有try 就cancel 了； 事务控制表
• 幂等问题：TC（事务协调者），没收到RM 的执行响应，多次执行cancel ,事务控制表
• 悬挂：悬挂是指因为网络问题，RM 开始没有收到 try 指令，但是执行了cancel 后try 有发送执行成功 ；事务控制表

附录

基于tx-lcn 架的搭建的分布式事务

基于Seate 搭建的分布式事务