4Seata分布式事务模式选型

• Saga模式组成结构和实现方式
• XA模式组成结构和实现方式
• Seata分布式事务模式选型

Saga模式组成结构和实现方式

概念

长事务
长时间执行的事务，传统事务锁定资源不适合执行长事务
Saga模式
Saga模式由一串本地事务组成，每个本地事务都有自己回滚.数据的补偿事务（没有全局事务）。
事务之间串型执行，当正向执行的某一个事务出现报错，那么将执行这个事务的补偿事务，并且逆行执行之前的事务补偿。

优势

• 事务提交
  一阶段直接提交事务
• 加锁机制
  没有锁等待，性能较高
• 事务异步
  结合事件驱动架构实现短事务异步执行
• 补偿机制
  补偿过程实现简单，实现正向事务的逆向补偿即可
• 应用场景
  更适用于遗留服务、第三方服务或无法改造的服务

问题
不提供加锁机制，也就不具备原子性，因此数据隔离性的影响比较大

实现类型

• 事件/编排式
  前一个服务执行完成后发送消息，后一个服务通过订阅消息的式来实现服务的协调。引入消息中间件来解决耦合性问题。
  • 优势
    引入了消息订阅降低了耦合性;简单场景实现相对来说逻辑清晰
  • 劣势
    服务之间通过订阅消息来触发调用，处理不当容易造成循环消息;复杂场景不好处理
• 命令/协同式
  需要定义一个集中式的Saga协调器，负责告诉每一个服务应该做什么。Saga协调器以命令/回复的方式与各个服务进行通信。
  • 优势
    理解简单，业务逻辑实现流程更加清晰;调用是单向的，不会产生依赖循环问题
  • 劣势
    存在一定的设计以及相关API的学习成本

XA模式组成结构和实现方式

XA规范

XA规范是X/Open组织定义的分布式事务处理(DTP，DistributedTransaction Processing)标准XA规范描述了全局的事务管理器与局部的资源管理器之间的接口，目的是允许的多个资源(如数据库，应用服务器，消息队列等)在同一事务中访问，这样可以使 ACID 属性跨越应用程序而保持有效。XA规范使用两阶段提交来保证所有资源同时提交或回滚任何特定的事务。
本质特性
补偿型事务处理机制中的事务资源本身对分布式事务是无感知的，而XA协议要求事务资源本身提供对规范和协议的支持（偏底层），所以事务资源(如数据库)可以保障从任意视角对数据的访问有效隔离，满足全局数据一致性。（强一致性）

事务感知性案例
例如，假设一条库存记录处在补偿型事务处理过程中，由100扣减为50。此时，系统管理人员访问数据库查询统计库存，就看到当前的 50。之后事务因为异常触发回滚，库存会被补偿回滚为 100。

• 补偿模式
  系统管理人员查询统计到的50就是脏数据，所以补偿型事务存在中间状态
• XA规范
  数据中间状态50由数据库本身保证，系统管理人员无法查看

XA模式
一阶段
- TM 启动全局事务

• RM 注册分支事务到TC，汇报状态到TC
  二阶段
  • TC 提交/回滚RM事务
    两阶段说明
• 执行阶段
  1. 可回滚:业务SQL操作放在XA分支中进行，基于资源对XA协议的支持来保证可回滚
  2. 持久化:执行XA分支的prepare方法，同样基于资源对XA协议的支持来保证持久化
• 完成阶段
  1. 分支提交:执行XA分支的commit方法
  2. 分支回滚:执行XA分支的rollback方法

Seata分布式事务模式选型

AT

• 特性
  业务无侵入
  性能满足普通业务
• 应用场景
  不希望对代码进行改造
  数据库支持事务操作
  对性能没有特别高的要求

TCC

• 特性
  业务强侵入
  没有用到锁，通过业务预留实现数据更新

• 应用场景
  对性能有较高要求
  无需依赖于数据库事务性
  各种定制化场景

Saga

• 特性
  开发过程比较复杂
  事务隔离性较差
• 应用场景
  适用于长事务业务场景
  适用于遗留系统(可控性差)改造
  操作多个分散服务的数据

XA

• 特性
  业务无侵入
  并发性能低

• 应用场景
  强一致，对性能要求低
  使用较少

选型维度	业务侵入性	开发友好性	数据一致性	性能
AT	无	好	较强 全局锁和本地锁组合	稍差，全局锁和本地所组合
TCC	强	较好 实现try/confirm/cancel三个方法	没有全局锁，只本地锁	高，短事务
Saga	弱	相对复杂 事件驱动或集中式服务	最弱，无锁，长事务，易脏读（最大问题）	高，无锁，长事务，可并行
XA	无	好	强一致 所有事务执行完才释放本地锁	差，所有事务完成才释放本地锁

思考题

结合你日常开发过程中的一个具体场景，对分布式事务的模式进行合理选型？