分布式事务 - seata

补偿协议 saga

正向服务，补偿服务都是要自己实现的
https://www.sofastack.tech/blog/sofa-meetup-3-seata-retrospect/

SEATA 模式

1、at : auto

  • before image（前镜像）
  • after image （后镜像）
  • row lock (行锁) -- 自旋锁

二阶段

1）提交
  • 删除中间数据

删除before,after image ,row lock

2）回滚
  • 还原业务数据，删除中间数据

1）校验数据脏写

diff after image & current db

  1. 还原数据

before image's 逆向SQL (undo log) -> 数据还原

3） 删除中间数据

第一阶段可能出现撞锁

image

行锁策略

1）可重入锁
允许同一事务内对同一数据的重复加锁
2）自旋锁 ： 加锁失败时重试

3）乐观锁 ： 不加锁

4）锁细化 ：（表名+主键 -> 表名+主键+更新列）

  • 不同事务更新的列不同其实也是可以并发的

2、tcc

  • 自己实现二阶段的3个方法 try,confirm , cancel
  • 不适合包含其它公司业务系统参与服务，长流程

实践经验

  • 业务模型分2阶段设计

把金额（资源）为两个字段存储。　账面金额　＝ freezeAmount + availableAmount;
×　冻结金额
×　可用金额

  • 并发控制

不像AT模式，tcc需要自己控制并发

  • 空回滚

未收到try（丢包）,收到cancel

  • 悬挂

先收到cancel，try（拥堵）后到
先收到cancel也要作记录

  • 幂等

3个方法都是保证幂等性

3、saga

  • 适合业务流程长，多
  • 参与者包含其它公司或遗留系统服务，无法提供TCC模式要求的3个接口
  • 一阶段提交本地事务 ，高性能
  • 参与者可异步执行，高吞吐
  • 补偿服务易于实现
  • 缺点：不保证隔离性

实现模式（状态机引擎，注解拦截器）

状态机引擎 解析 状态图json
DSL定义流程
异常处理：向前重试，向后补偿

  • 模式对比

java注解拦截器
事后恢复难以实现“向前重试”的策略

状态机引擎的最大优势是可以通过事件驱动的方法异步执行提高系统吞吐，可以实现服务编排需求，在 Saga 模式缺乏隔离性的情况下，可以多一种“向前重试”的事后恢复策略。注解加拦截器的的最大优势是，开发简单、学习成本低。

saga设计

  • 允许空补偿，防悬挂控制，幂等控制
  • 自定义事务恢复策略

4、xa

角色

  • TM 事务管理器

开启，提交，回滚分布式事务

  • RM 资源管理器

注册，汇报，执行资源

  • TC 事务协调器

事务管理器服务功能，存储事务日志 ，补偿异常事务

如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。

image

在 Seata 中，分布式事务的执行流程：

TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）；
TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
TC 汇总事务信息，决定分布式事务是提交还是回滚；
TC 通知所有 RM 提交/回滚 资源，事务二阶段结束；

posted @ 2021-07-04 15:07  沉梦匠心  阅读(243)  评论(0)    收藏  举报