[toc]

零、遇到的问题

分布式数据库,需要业务操作保证数据事务唯一!
image.png

单体应用被拆分成微服务应用,原来的三个模块被拆分成三个独立的应用,分别使用三个独立的数据源,业务操作需要调用三个服务来完成。此时每个服务内部的数据一致性由本地事务来保证,但是全局的数据—致性问题没法保证。
用户购买商品的业务逻辑。整个业务逻辑由3个微服务提供支持:

  1. 仓话服务:对给定的商品扣除仓储数量。
  2. 订单服务:根据平购需求创建订单。
  3. 根户服务:从用户帐户中扣除余额。

一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用,就会产生分布式事务问题

一、简介

官方地址:http://seata.io/zh-cn/
Seata是一款开源的分布式事务解决方案,致力于在微服务架构下提供高性能和简单易用的分布式事务服务
image.png

1. 处理过程

image.png

  1. [TM向TC申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的XID;
  2. XID在微服务调用链路的上下文中传播;
  3. RM向TC注册分支事务,将其纳入XID对应全局事务的管辖;
  4. TM向TC发起针对XID的全局提交或回滚决议;
  5. TC调度XID下管辖的全部分支事务完成提交或回滚请求。

2. 组件概念

  1. Transaction ID XID:全局唯一的事务ID
  2. Transaction Coordinator(TC) :事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚;
  3. Transaction Manager(TM) : 控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议;
  4. Resource Manager(RM) :控制分支事务,负责分支注册,状态汇报,并接收事务协调器的指令,驱动分支(本地)事务的提交和回滚;

二、执行流程

image.png

  1. TM开启分布式事务(TM向TC注册全局事务记录)
  2. 换业务场景,编排数据库,服务等事务内资源(RM向TC汇报资源准备状态)
  3. TM结束分布式事务,事务一阶段结束(TM通知TC提交/回滚分布式事务)
  4. TC汇总事务信息,决定分布式事务是提交还是回滚
  5. TC通知所有RM提交/回滚资源,事务二阶段结束。

image.png

1. AT模式如何做到对业务的无侵入??

AT模式
前提

  1. 基于支持本地ACID事务的关系型数据库。
  2. Java应用,通过JDBC访问数据库。

整体机制
两阶段提交协议的演变:

  1. 一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源。
  2. 二阶段:
    2.1 提交异步化,非常快速地完成。
    2.2 回滚通过一阶段的回滚日志进行反向补偿。

2. 一阶段加载

image.png
在一阶段,Seata 会拦截“业务SQL”,

  1. 解析SQL语义,找到“业务SQL”要更新的业务数据,在业务数据被更新前,将其保存成“before image",
  2. 执行“业务SQL”更新业务数据,在业务数据更新之后,
  3. 其保存成“after image”,最后生成行锁。
    以上操作全部在一个数据库事务内完成,这样保证了一阶段操作的原子性。

3. 二阶段提交

image.png
二阶段如是顺利提交的话,
因为“业务SQL”在一阶段已经提交至数据库,所以Seata框架只需将一阶段保存的快照数据和行锁删掉,完成数据清理即可。

4. 二阶段回滚

image.png
二阶段回滚:
二阶段如果是回滚的话,Seata就需要回滚一阶段已经执行的“业务SQL”,还原业务数据。
回滚方式便是用“before image”还原业务数据;但在还原前要首先要校验脏写,对比“数据库当前业务数据”和“after image”,如果两份数据完全一致就说明没有脏写,可以还原业务数据,如果不一致就说明有脏写,出现脏写就需要转人工处理。

Q.E.D.


只有创造,才是真正的享受,只有拚搏,才是充实的生活。