分布式事务

背景

• 业务不断发展变得复杂
• 复杂的业务需要拆分成分布式系统

• 分布式系统下产生了分布式事务

  概念

• 分布式条件下，多个节点操作的整体事务一致性

• 微服务下，跨系统的AB两个事务如何保持一致

  对比

  

  XA强一致分布式事务

  前提

• 基于强一致的思路和数据库本身支持的协议

• 在现有事务模型上微调扩展，实现分布式事务

• 适用于要求严格一致如金融系统业务

  概念

• AP应用程序ApplicationProgram，用于定义事务边界（事务的开始和结束）并在边界内对资源进行操作

• RM资源管理器ResourceManager，如数据库服务、文件系统等，并提供访问资源的方式，即本地事务服务
• TM事务管理器TransactionManager，负责分配事务唯一标识、监控事务的执行进度，并负责事务的提交、回滚等
• 也称两阶段提交2PC
  • prepare阶段
  • 真正处理阶段

XA接口

• xa_start:开启或恢复一个事务分支
• xa_end:取消当前线程和事务分支的关联
• xa_prepare:询问RM是否准备好提交事务
• xa_commit:通知RM提交事务
• xa_rollback:通知RM回滚事务
• xa_recover:列出需要恢复的XA事务 ```sql

  查看XA是否支持

  show engines;

开启一个xa，并命名全局事务名称[,分支事务名称]

xa start ‘gName’,’bName’;

insert into tname values(); update tname set name=1 where id=1;

通知sql已经执行完毕

xa end ‘name’;

询问RM是否准备好

xa prepare ‘name’；

提交

xa commit ‘name’; ```

MySQL XA事务状态

XA处理过程

异常情况

• 业务SQL执行过程中，某个RM崩溃？
  • TM会收到报错异常，自己业务处理
• 全部prepare后，某个RM崩溃？
  • MySQL5.7后修复了重连后xa recover消失的问题
  • TM有xa recover则可以随时再commit/rollback

• commit时，某个RM崩溃？

  • 重试
  • 重试失败后通知人工处理（手动xa recover）

    主流框架

    

    问题

• 同步阻塞问题

  • 一般情况下，不需要调高隔离级别
  • 如果需要强一致，TM这边的所有事务都要串行化的执行
• 单点故障
  • 成熟的XA框架需要考虑TM的高可用性

• 数据不一致

  • 极端情况下，一定有事务失败问题，需要监控和人工处理

    BASE柔性分布式事务

    前提

• 使用一套事务框架保证最终一致的事务

• 通过最终超时终止，调度补偿，容忍短时间不一致，实现最终一致
• 适用于非实时业务

• 通过放宽对强一致的要求换取吞吐量的提升，通过业务逻辑将互斥锁操作从资源层面移至业务层面

  BASE

• 基本可用BasicallyAvailable，分布式事务参与方不一定同时在线，但基本可用

• 柔性状态SoftState，允许状态更新有一定的延迟

• 最终一致EventuallyConsistent，通过消息传递的方式保证状态最终一致

  柔性事务下的隔离级别

  事务特性

• 原子性：正常情况下可以保证

• 一致性：要求最终一致，中间状态可能不一致
• 隔离型：中间状态可能读取到脏数据

• 持久性：和本地事务一样，只要commit就能持久

  隔离级别

• 如果没有全局锁的概念，对于一个分布式事务，每一个小的事务都有可能先后执行，全局来看就会是读未提交隔离，出现脏读

• 如果有全局锁，则能隔离到读已提交

  常见模式

• TCC 通过手动补偿处理

• AT 通过自动补偿处理

  TCC/AT以及相关框架

  TCC

  概念

• 将某个业务操作分成两个阶段

  • 第一个阶段检查并预留相关资源
  • 第二个阶段根据业务的Try状态来操作，如果都成功则Confirm，任意一个Try发生错误，全部Cancel
• 此模式依赖业务模式设计，并不依赖RM对分布式事务的支持，所以对业务是有侵入要求
• Try/Confirm/Cancel
  • Try接口事务执行完会提交，执行失败会回滚
  • Confirm接口事务执行完会提交，业务执行完毕，如果多次重试仍然失败则走Cancel接口
  • Cancel接口会回滚Try的提交

• 图3:25

  实现三段逻辑

• 准备操作Try：完成所有业务检查，预留必要的业务资源（比如预先冻结部分数据）

• 确认操作Confirm：
  • 真正执行业务逻辑，不做检查，只是用Try预留的资源。Try能成功Confirm必须能成功。
  • Confirm操作要满足幂等性，保证一笔分布式事务能且只能成功一次

• 取消操作Cancel：释放Try预留的资源，Cancel也要幂等性

  注意点

• 允许空回滚

  • Try直接报错走到的Cancel接口允许空回滚
• 防悬挂控制
  • 有可能因网络抖动Cancel接口先接收到，Try才接收到，这样Try就没有Cancel
  • 为了避免，可以内存中记录Cancel时的ID，Try来时进行检查，如果有ID则Try就放弃执行

• 幂等设计

  AT

  概念

• 就是两阶段提交，自动生成反向SQL

• SQL解析模块自动把操作前的数据现场保存起来，并且自动生成反向SQL，失败后执行反向SQL进行回滚

• 

  框架SEATA

• TM事务管理器

• TC事务协调器
• RM资源管理器

• 

  Hmily

  
  

  ShardingSphere分布式事务

  基础

• 支持强一致的XA事务和柔性的BASE事务，但api不一致

• XA事务开发简单，但需要业务设计，对高并发和长事务支持的不好
• BASE事务需要对业务进行改造，接入成本高，需要开发者自行实现资源锁定和反向补偿
• ShardingSphere分布式事务模块主要设计目标就是整合现有的事务方案（本地事务、TCC和BASE）

  实现