1.两阶段提交方案/XA方案。
原理 这个就是所谓的XA事务,两阶段提交,有一个事务管理器的概念,负责协调多个数据库(资源管理器)的事务,事务管理器先问问各个数据库你准备好了吗?如果每个数据库都回复ok,那么就正式提交事务,在各个数据库上执行操作;如果任何一个数据库回答不ok,那么就回滚事务。
适用场景:
比较适合单块应用里,跨多个库的分布式事务。
缺点
因为严重依赖于数据库层面来搞复杂的事务,效率很低,不适合高并发的场景。
2.TCC方案
TCC全称是:Try、Confirm、Cancel。
原理
使用到了补偿的概念。整个过程分为三个阶段:
①Try阶段:这个阶段说的是对各个服务的资源做检查以及对资源进行锁定或者预留。
②Confirm阶段: 执行实际的操作。
③Cancel阶段:如果操作中任何一个失败了,那么就需要回滚进行补偿。
适用场景
这种方案说实话几乎很少用人使用,但是也有使用的场景。这个就是除非你是真的一致性要求太高,是你系统中核心之核心的场景,比如常见的就是资金类的场景,那你可以用TCC方案了,自己编写大量的业务逻辑,自己判断一个事务中的各个环节是否ok,不ok就执行补偿/回滚代码。
而且最好是你的各个业务执行的时间都比较短。
缺点 :
事物回滚严重依赖于自己写