AT事务模式分布式事务工作机制
1.前提
基于支持本地 ACID 事务的关系型数据库;(mysql、oracle)
Java 应用,通过JDBC访问数据库;
整体机制
就是两阶段提交协议的演变:
一阶段:
“业务数据“和“回滚日志记录“在同一个本地事务中提交,释放本地锁和连接资源;
二阶段:
如果没有异常异步化提交,非常快速地完成;
如果有异常回滚通过一阶段的回滚日志进行反向补偿;
具体举例说明整个AT分支的工作过程;
举例; update product set name = ‘GTS’ where name = ‘TXC’;
AT分支事务的业务逻辑:
一阶段过程:
1、解析SQL,得到SQL的类型(UPDATE),表(product),条件(where name = ‘TXC’)等相关的信息
2、查询前镜像:根据解析得到的条件信息,生成查询语句,定位数据;
select id, name, since from product where name = 'TXC';
得到前镜像:查询结果
3、执行业务 SQL:更新这条记录的 name 为 'GTS';
4、查询后镜像:根据前镜像的结果,通过 主键 定位数据; 得到后镜像:
select id, name, since from product where id = 1;
5、插入回滚日志:把前后镜像数据以及业务SQL相关的信息组成一条回滚日志记录,插入到 UNDO_LOG 表中;
6、分支事务提交前,向TC注册分支,申请table表中,主键值等于1的记录的全局锁(在当前的同一个全局事务id范围内是可以申请到全局锁的,不同的全局事务id才会排斥);
7、本地事务提交:业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交;
8、将本地事务提交的结果上报给TC;
二阶段-回滚:
1、收到 TC 的分支回滚请求,开启一个本地事务,执行如下操作;
2、通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录;
3、数据校验:拿 UNDO LOG 中的后镜像与当前数据进行比较,如果有不同,说明数据被当前全局事务之外的动作做了修改,这种情况,需要人工来处理;
4、根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句:
update product set name = ‘TXC’ where id = 1;
5、提交本地事务,并把本地事务的执行结果(即分支事务回滚的结果)上报给TC
二阶段-提交
1、收到TC的分支提交请求,把请求放入一个异步任务的队列中,马上返回提交成功的结果给TC;
2、异步任务阶段的分支提交请求将异步和批量地删除相应UNDO LOG记录;
回滚日志表:
Field Type
branch_id bigint PK
xid varchar(100)
context varchar(128)
rollback_info longblob
log_status tinyint
log_created datetime
log_modified datetime
CREATE TABLE `undo_log` (
`id` bigint NOT NULL AUTO_INCREMENT,
`branch_id` bigint NOT NULL,
`xid` varchar(100) NOT NULL,
`context` varchar(128) NOT NULL,
`rollback_info` longblob NOT NULL,
`log_status` int NOT NULL,
`log_created` datetime NOT NULL,
`log_modified` datetime NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
AT事务模式运行机制解读
整体机制是两阶段提交协议的演变:
一阶段:
业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源;(本地事务,就已经在数据库持久化了)
二阶段:
如果没有异常提交异步化,非常快速地完成;(正常情况,那就提交了,同步一下TC Server的状态,删除回滚日志)
如果有异常回滚通过一阶段的回滚日志进行反向补偿;(比如订单删除,库存加回去,余额加回去);
写隔离
一阶段本地事务提交前,需要确保先拿到全局锁;
拿不到 全局锁 ,不能提交本地事务;
拿 全局锁 的尝试被限制在一定范围内,超出范围将放弃,并回滚本地事务,释放本地锁;
以一个示例来说明:
两个或者多个全局事务 tx1 和 tx2,分别并发对 a 表的 m 字段进行更新操作,m 的初始值 1000;
假设tx1 先开始,开启本地事务,拿到本地锁,更新操作 m = 1000 - 100 = 900,
本地事务提交前,先拿到该记录的 全局锁 ,拿到了全局锁,本地提交并释放本地锁;
tx2后开始,开启本地事务,拿到本地锁,更新操作 m = 900 - 100 = 800,本地事务提交前,尝试拿该记录的 全局锁 ,tx1全局提交前,该记录的全局锁一直会被 tx1 持有,tx2 需要重试等待 全局锁 ;
tx1 二阶段全局提交,释放 全局锁 ,tx2 拿到 全局锁 提交本地事务;
如果 tx1 的二阶段全局回滚,则 tx1 需要重新获取该数据的本地锁,进行反向补偿的更新操作,实现分支的回滚;
此时,如果 tx2 仍在等待该数据的 全局锁,同时持有本地锁,则 tx1 的分支回滚会失败。分支的回滚会一直重试,直到 tx2 的 全局锁 等锁超时,放弃 全局锁 并回滚本地事务释放本地锁,tx1 的分支回滚最终成功;
因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的,所以不会发生 脏写 的问题;
读隔离
在数据库本地事务隔离级别 读已提交(Read Committed) 或以上的基础上,Seata(AT 模式)的默认全局隔离级别是 读未提交(Read Uncommitted);
如果应用在特定场景下,必需要求全局的 读已提交 ,目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理;
SELECT FOR UPDATE 语句的执行会申请 全局锁 ,如果 全局锁 被其他事务持有,则释放本地锁(回滚 SELECT FOR UPDATE 语句的本地执行)并重试,这个过程中,查询是被 block 住的,直到 全局锁 拿到,即读取的相关数据是 已提交 的,才返回;
出于总体性能上的考虑,Seata目前的方案并没有对所有SELECT语句都进行代理,仅针对 FOR UPDATE 的 SELECT 语句;
TCC事务模式执行机制
AT模式基本上能满足我们使用分布式事务大部分需求,但涉及非关系型数据库与中间件的操作、跨公司服务的调用、跨语言的应用调用就需要结合TCC模式;
一个分布式的全局事务,整体是两阶段提交(Try - [Comfirm/Cancel])的模型,在Seata中,AT模式与TCC模式事实上都是基于两阶段提交,它们的区别在于:
AT模式基于支持本地ACID事务的关系型数据库:
1、一阶段prepare行为:在本地事务中,一并提交“业务数据更新“和”相应回滚日志记录”;
2、二阶段 commit 行为:马上成功结束,自动异步批量清理回滚日志;
3、二阶段 rollback 行为:通过回滚日志,自动生成补偿操作,完成数据回滚;
而TCC 模式,需要我们人为编写代码实现提交和回滚:
1、一阶段 prepare 行为:调用自定义的 prepare 逻辑;(真正要做的事情,比如插入订单,更新库存,更新余额)
2、二阶段 commit 行为:调用自定义的 commit 逻辑;(自己写代码实现)
3、二阶段 rollback 行为:调用自定义的 rollback 逻辑;(自己写代码实现)
TCC模式,就是把自定义的分支事务的提交和回滚并纳入到全局事务管理中;
通俗来说,Seata的TCC模式就是手工版本的AT模式,它允许你自定义两阶段的处理逻辑而不需要依赖AT模式的undo_log回滚表;
举例:
@LocalTCC
public interface AccountService {
/**
* 扣除余额
* 定义两阶段提交
* name = reduceStock为一阶段try方法
* commitMethod = commitTcc 为二阶段确认方法
* rollbackMethod = cancel 为二阶段取消方法
* BusinessActionContextParameter注解 可传递参数到二阶段方法
*
* @param userId 用户ID
* @param money 扣减金额
* @throws Exception 失败时抛出异常
*/
@TwoPhaseBusinessAction(name = "reduceBalance", commitMethod = "commitTcc", rollbackMethod = "cancelTcc")
void reduceBalance(@BusinessActionContextParameter(paramName = "userId") Integer userId,
@BusinessActionContextParameter(paramName = "money") BigDecimal money);
/**
* 确认方法、可以另命名,但要保证与commitMethod一致
* context可以传递try方法的参数
*
* @param context 上下文
* @return boolean
*/
boolean commitTcc(BusinessActionContext context);
/**
* 二阶段取消方法
*
* @param context 上下文
* @return boolean
*/
boolean cancelTcc(BusinessActionContext context);
}
@LocalTCC注解标识此TCC为本地模式,即该事务是本地调用,非RPC调用,@LocalTCC一定需要注解在接口上,此接口可以是寻常的业务接口,只要实现了TCC的两阶段提交对应方法即可;
@TwoPhaseBusinessAction,该注解标识为TCC模式,注解try方法,其中name为当前tcc方法的bean名称,写方法名便可(全局唯一),commitMethod指提交方法,rollbackMethod指事务回滚方法,指定好三个方法之后,Seata会根据事务的成功或失败,通过动态代理去帮我们自动调用提交或者回滚;
@BusinessActionContextParameter 注解可以将参数传递到二阶段(commitMethod/rollbackMethod)的方法;
BusinessActionContext 是指TCC事务上下文,携带了业务方法的参数;