微服务实战 06 分布式事务框架 seata 入门
参考《Spring Cloud Alibaba 微服务原理与实战》
分布式事务框架 seata
seata 是一个开源的分布式事务框架,它提供了 AT 、 TCC 、Sage 和 XA 事务模式
XA协议请看这篇文章
TCC协议请看这篇文章
AT 模式
AT 模式 是基于XA演进而来的一种分布式事务模式,它同样分为三大模块
- TM : 事务管理器
- RM:资源管理器
- TC:事务协调器
其中TM 和 RM 为 Seata 的客户端与业务系统集成,TC作为Seata的服务器单独部署。
执行流程:
- TM向TC注册全局事务,并生成一个全局唯一的XID
- RM向TC注册分支事务,并将其纳入该XID对应的全局事务范围
- RM向TC汇报资源准备情况
- TC汇总所有事务参与者的执行状态,决定分布式事务是全部回滚还是提交
- TC通知所有RM提交/回滚事务
AT模式和XA一样,也是一个两阶段事务模型
AT 和 TCC的区别
AT 模式基于 支持本地 ACID 事务 的 关系型数据库:
- 一阶段 prepare 行为:在本地事务中,一并提交业务数据更新和相应回滚日志记录。
- 二阶段 commit 行为:马上成功结束,自动 异步批量清理回滚日志。
- 二阶段 rollback 行为:通过回滚日志,自动 生成补偿操作,完成数据回滚。
相应的,TCC 模式,不依赖于底层数据资源的事务支持: - 一阶段 prepare 行为:调用 自定义 的 prepare 逻辑。
- 二阶段 commit 行为:调用 自定义 的 commit 逻辑。
- 二阶段 rollback 行为:调用 自定义 的 rollback 逻辑。
Saga 模式
Saga模式又称为长事务解决方案,其核心思想:把一个业务流程中的长事务拆分为多个本地短事务,业务流程中的每个参与者都提交真实的提交给该本地短事务,当其中一个参与者事务执行失败,则通过补偿机制补偿前面已经成功的参与者。
- 事务从前到后正常执行
- 在执行中一个事务遇到异常,执行补偿机制
两种补偿恢复方式 - 向后恢复:如果任意一个子事务执行失败,则把之前的捷星的结果注意撤销
- 向前恢复:不进行补偿,而是对失败的事务进行重试
优势:
- 与XA和TCC相比,一阶段直接提交本地事务;没有锁等待,性能较高;在事件驱动的模式下,段十五可以异步执行;补偿机制的实现比较简单
缺点: - Saga并不提供原子性和隔离性执行。
Saga 的实现方式
根据Saga模式的定于i,先将长事务拆分多个本地短事务,每个服务的本地事务按照执行孙旭注意提交,一旦其中一个服务的事务出现异常,则采用补偿的方式逐一撤回。这一过程会涉及Saga的协调模式
两种常用的协调模式
- 事件/编排式: 把Saga的决策和执行顺序逻辑分布在Saga的每一个参与者中,他们通过交换事件的方式来进行沟通
- 命令/协同式:把Saga的决策和执行顺序逻辑集中在一个Sage控制类中,他以命令/回复的方式之与没想服务进行通信,告诉他们应执行哪些操作
事件/编排式
在基于事件的编排模式中,第一个服务执行完一个本地事务之后,发送一个事件。这个事件会被一个或者多个服务监听,监听到事件的服务再执行本地事务并发布新的事件,直到该业务流程中最后一个服务的本地事务执行结束。
上图看着复杂,但其实非常简单,通过事件机制,从上往下执行,任何一个执行失败,再通过时间机制向上回滚
命令/协同式
命令/协同式 需要定义一个Saga协调器,负责告诉每一个参与者该做什么,Saga协调器以命令/回复的方式与每项服务进行通信
命令/协同式 其实是把整个流程的调用交由Saga协调器管理,按照流程循序依次调用,在任何一个环节执行失败,他都需要向每个参与者发送命令撤销前的事务操作。