分布式事务

分布式事务解决方案

一、本地事务

本地事务是通过关系型数据库来控制的

数据库事务四大特性：ACID

• A原子性：要么全部成功，要么全部失败
• C一致性：经典银行转账
• I 隔离性：并发事务中，不同事务应该互不干扰
• D持久性：事务完成之后，事务对数据的修改应该持久化到数据库，不会回滚

小结：传统的关系型数据库完美满足ACID,但对于分布式服务，我们需要新的理论支撑

二、分布式事务

分布式系统下，不同服务之间通过网络远程协作完成事务称之为分布式事务

1、CAP理论

1）CAP概念

• Consistency（一致性）：例商品在主数据库中被修改，那么从数据库中也应该是读到最新的修改后的信息（不会读到旧数据）
• Availability（可用性）：每一次只要请求查询数据库一定可以读到数据（可能会读到旧数据）
• Partition tolerance（分区容忍性）：一个节点挂掉不影响其他节点提供服务，主数据库向从数据库同步失败，不影响写读。

2）问题

• 强一致性产生问题：每次读取必须等待数据同步完成以读取最新数据，服务存在短暂不可用。

• 强可用性产生问题：每次必须读到数据，导致经常读到旧数据。

• 分区容错性问题：必须存在分区容错性，不然的话就用不着分布式事务了

3）扩展问题

1、如何实现分区容忍性？

• 使用异步代替同步
• 增加从节点，一个节点挂掉，另一个节点工作

2、为什么无法同时保证C和A?

• 要保证C，那么从节点要读数据的时候，就要等待主节点将最新的数据同步完成，就会产生短暂不可用。
  - 要保证A，那么只要来了请求读取数据，就一定会读取到，哪怕读到旧数据，不会因为要等待主节点同步完成而产生短暂不可用

3、现存分布式事务解决方案

• AP： 放弃一致性，追求可用性和分区容错性，例 Eureka
• CP： 放弃可用性，追求一致性和分区容错性，例 Zookeeper
• CA： 当前关系型数据库就满足了CA

词解：

• 网络分区：分布式系统的各节点部署在不同的子网

小结：严格的CA,CP并不适用于一些复杂场景，如支付，我们需要一致性，看到支付结果，但是我们也需要可用性，一定要返回结果，因要新的理论支撑

2、BASE理论

1）BASE概念

• 基本可用：分布式系统故障，允许部分不可用，保证核心功能可用
• 软状态：不最求强一致性，返回中间态，如处理中，支付中
• 最终一致性：一段时间后，所有节点数据都都会达到一致，如 “支付中“ 最终变为 “支付完成” 或 “支付失败”

2）词解

• 强一致性：每次查询必须是最新数据，不允许旧数据或其他状态

小结： BASE理论通过牺牲强一致性解决了既要C又要A的问题，由此事务发展 关系型数据库ACID——》分布式事务CAP——》AP的增强BASE

3、2PC两阶段提交

图示：

1）概念：

• 准备阶段：数据库参与者在本地执行事务，写本地的Undo/Redo日志，事务未提交
• 提交阶段： 接收参与者的消息，失败，超时就发送回滚命令，成功就发送提交命令，最后释放锁资源

2）角色：

• 事务管理器： 协调全部事务参与者进行提交或回滚
• 事务参与者： 具体执行本地事务的提交回滚，记录Undo/Redo日志

3）问题：

为什么要记录Undo/Redo日志？ 此时事务未提交，记录Undo日志是为了回滚时恢复数据，记录Redo是为了提交时更新数据。

4）理解：

• Prepare阶段就像 预先排练 一样，先看一下各参与者能否提交成功，最后决定如何处理
• 两阶段提交只是一种设计理念，并非具体方案

小结：2PC的传统方案是在数据库层面实现的，Oracle、Mysql都支持，或许可以定义一套标准，减轻数据库厂商集成2PC协议的成本

4、XA方案

1）概念：

• DTP模型定义TM和RM的之间通讯的接口规范就叫XA，可简单理解为数据库基于2PC协议提供的规范对接，所以基于XA实现的2PC又称为XA方案

2）角色：

• AP： 应用程序（有多个数据源）
• RM： 资源管理器
• TM： 事务管理器

3）问题：

1. 需要数据库支持XA协议
2. 资源锁需要等到提交或回滚后才释放，并发场景性能很低

4）词解：

• DTP: 国际开放组织定义的分布式事务处理模型

小结：个人理解，XA与2PC就相当于JPA与Hibernate,数据库都实现了自己的2PC，应用端对接困难，由此约定一个统一的对接模型，可以减少对接成本

5、Seata

图示：

1）概念：

• 开源的分布式事务框架，设计理念无侵入，解决2PC问题

2）角色：

• TC(事务协调器) ：
  （1）接收TM指令发起全局事务的提交与回滚
  （2）负责与RM通信，协调各分支事务的提交或回滚
  （3）是独立的中间件，需要独立部署与运行
• TM(事务管理器)：
  （1）向TC申请开启全局事务生成全局唯一XID
  （2）向TC发起全局提交或全局回滚的指令
  （3）TM需要嵌入应用程序中工作（jar包）
• RM(资源管理器)：
  （1）向TC注册分支,分支执行业务逻辑，将分支纳入XID
  （2）状态汇报
  （3）接收TC指令进行提交或回滚

3）Seata实现2PC与传统2PC差别

• 架构层次。 传统PC方案的RM是在数据库层，RM本质就是数据库自己，通过XA协议实现，Seata的RM是通过jar包的形式作为中间件部署在应用程序这一侧的。
• 资源释放。 传统2PC在第二阶段才释放锁，Seata则在第一阶段已经提交了本地事务，释放了锁资源，提高了并发性能。

小结：Seata解决了原二阶段提交资源长时间锁定的问题，且不要求数据库必须实现XA协议

6、Seata之TCC模式

1）概念：

• TCC为Try预处理, Confirm确认, Cancel撤销三个词的缩写
• Try: 业务检查,资源预留
• Confirm: 业务确认操作,默认此阶段不会出错，出错即重试或人工处理
• Cancel: 与try相反的回滚操作，释放预留资源，失败即重试或人工处理

2）角色：

• TM： 发起所有分支事务的try操作；try全部成功则发起Confrim操作；存在try失败则发起Cancel操作；可让全局事务发起者充当TM,也可独立成公用组件

3）执行逻辑：

• 第一阶段TM发起所有分支事务的Try操作，进行业务检查，资源预留
• 第二阶段，如果存在一个分支事务的try执行失败，就会发起所有分支事务的Cancel操作；try全部成功则发起Confrim操作，Cancel/Confirm执行失败TM会进行重试。

4）三种异常：

• 空回滚：

  • 原因： 在没有调用Try的情况下，调用了Cancel*
  • 场景： 网络问题，服务宕机等都可以造成

• 幂等：

  • 原因： TCC二阶段存在提交重试机制，因此二阶段的Confrim,Cancel需要保证幂等，以保证不会重复使用或释放资源，同时try也是单独线程执行也需要保持幂等性，幂等没有做好就可能造成数据不一致。
  • 场景： try，cancel，confirm都是有单独线程执行，且会出现重复调用，所以都需要实现幂等

• 悬挂：

  • 原因： 对于一个分布式事务，TCC二阶段可能Cancel可能比Try先执行。
  • 场景： 如执行Try时，存在RPC调用超时，随后TM通知RM进行回滚，回滚完成后，PRC请求才到达参与者真正执行，而Try方法预留的业务资源，只有该分布式事务才能使用，即业务资源预留后没法继续处理

5）三种异常解决：

增加一张分支事务记录表，其中有全局事务ID及分支事务ID

• 空回滚解决：
  try 方法里插入一条记录，记录第一阶段的执行，执行Cancel时检查try的执行情况
• 幂等解决：
  各阶段执行都插入一条记录，以知道是否重复执行
• 悬挂解决：
  执行第一阶段事务时，判断分支事务表是否有二阶段事务记录，有则不执行

空回滚与悬挂的区别： 空回滚是没有执行try，悬挂是执行了try

6）优缺点

优点

• 解决了跨事务原子性问题（如转账）
• 性能高，不需要全局锁

缺点

• 实现难度大，代码侵入性高，需要自定义方法，维护成本高
• 为保证一致性，try，confirm、cancel接口必须实现幂等性（定时器+重试）
• 需要增加事务记录日志，可考虑使用Redis

小结：TCC模式实现难度大，自定义程度高，性能强，是否使用需要综合衡量

7、AT模式与TCC模式区别

1）AT 模式基于 支持本地 ACID 事务 的 关系型数据库：

• 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。
• 二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。
• 二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。

2）TCC 模式，不依赖于底层数据资源的事务支持：

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