文章目录
分布式事务的几种方案
- 2pc模式
- TCC模式:柔性事务——TCC事务补偿型
- 柔性事务-最大努力通知型方案
- 柔性事务-可靠消息+最终一致性方案(异步确保型)
1. 2pc
2pc就是 2 phase commit 二阶段提交,又叫XA Transactions,这是2pc的一种实现协议,基于数据库层面的。
MySQL 从 5.5 版本开始支持,SQL Server 2005 开始支持,Oracle 7 开始支持。
其中,XA 是一个两阶段提交协议,该协议分为以下两个阶段:
第一阶段:事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作,并反映是 否可以提交.
第二阶段:事务协调器要求每个数据库提交数据。 其中,如果有任何一个数据库否决此次提交,那么所有数据库都会被要求回滚它们在此事务 中的那部分信息。
- XA 协议比较简单,而且一旦商业数据库实现了 XA 协议,使用分布式事务的成本也比较低。
- XA 性能不理想,特别是在交易下单链路,往往并发量很高,XA 无法满足高并发场景。因为会一直锁住资源,在整个分布式事务中都一直锁住,直到提交或回滚事务,才释放锁住的资源,所以高并发场景下性能不足。
- XA 目前在商业数据库支持的比较理想,在 mysql 数据库中支持的不太理想,mysql 的 XA 实现,没有记录 prepare 阶段日志,主备切换回导致主库与备库数据不一致。
- 许多 nosql 也没有支持 XA,这让 XA 的应用场景变得非常狭隘。
- 也有 3PC,引入了超时机制(无论协调者还是参与者,在向对方发送请求后,若长时间 未收到回应则做出相应处理)
seata的AT
Seata是由TM,RM,TC。 其中TM和RM是在客户端,TC是事务协调者是需要单独部署的服务端。
- TC (Transaction Coordinator) - 事务协调者 维护全局和分支事务的状态,驱动全局事务提交或回滚。
- TM (Transaction Manager) - 事务管理器(发起者,同时也是RM的一种) 定义全局事务的范围:开始全局事务、提交或回滚全局事务。
- RM (Resource Manager) - 资源管理器(每个参与事务的微服务) 管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
AT是2pc的变种,不过不是在数据库层面实现的分布式事务一致性,而是通过保存日志,通过日志来回滚
是两阶段提交协议的演变,比XA协议快一点:
- 一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源。
- 二阶段:
- 提交异步化,非常快速地完成。
- 回滚通过一阶段的回滚日志进行反向补偿。
写隔离性质:
- 一阶段本地事务提交前,需要确保先拿到 全局锁 。
- 拿不到 全局锁 ,不能提交本地事务。
- 拿 全局锁 的尝试被限制在一定范围内,超出范围将放弃,并回滚本地事务,释放本地锁
读隔离:
在数据库本地事务隔离级别 读已提交(Read Committed) 或以上的基础上,Seata(AT 模式)的默认全局隔离级别是 读未提交(Read Uncommitted) 。
如果应用在特定场景下,必需要求全局的 读已提交 ,目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。
具体点过程:
一阶段
过程(具体看官网):
- 解析 SQL:得到 SQL 的类型(UPDATE),表(product),条件(where name = ‘TXC’)等相关的信息。
- 查询前镜像:根据解析得到的条件信息,生成查询语句,定位数据。
- 执行业务 SQL:更新这条记录的 name 为 ‘GTS’。
- 查询后镜像:根据前镜像的结果,通过 主键 定位数据。
- 插入回滚日志:把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录,插入到
UNDO_LOG
表中。 - 提交前,向 TC 注册分支:申请
product
表中,主键值等于 1 的记录的 全局锁 。 - 本地事务提交:业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。
- 将本地事务提交的结果上报给 TC(事务协调者)。
注意!seata的at模式下讲的undolog是指seata服务器保存的实现事务的undolog,并不是要操作的数据库自身事务的undolog!
二阶段-回滚
-
收到 TC 的分支回滚请求,开启一个本地事务,执行如下操作。
-
通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
-
数据校验:拿 UNDO LOG 中的后镜与当前数据进行比较,如果有不同,说明数据被当前全局事务之外的动作做了修改。这种情况,需要根据配置策略来做处理,详细的说明在另外的文档中介绍。
-
根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句:
-
提交本地事务。并把本地事务的执行结果(即分支事务回滚的结果)上报给 TC。
二阶段-提交
- 收到 TC 的分支提交请求,把请求放入一个异步任务的队列中,马上返回提交成功的结果给 TC。
- 异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。
适用场景:对性能要求不太苛刻,需要代码无侵入、易维护
seata也支持XA模式,XA和AT的区别是,XA是基于数据库提供的一致性协议,而AT是seata通过额外的数据源来维护undolog表来保证一致性。
2. 柔性事务——TCC事务补偿型
刚性事务:遵循 ACID 原则,强一致性。
柔性事务:遵循 BASE 理论,最终一致性;
与刚性事务不同,柔性事务允许一定时间内,不同节点的数据不一致,但要求最终一致
3. 柔性事务-最大努力通知型方案
按规律进行通知,不保证数据一定能通知成功,但会提供可查询操作接口进行核对。这种方案主要用在与第三方系统通讯时,比如:调用微信或支付宝支付后的支付结果通知。这种 方案也是结合 MQ 进行实现,例如:通过 MQ 发送 http 请求,设置最大通知次数。达到通 知次数后即不再通知。
适用场景:银行通知、商户通知等(各大交易业务平台间的商户通知:多次通知、查询校对、对 账文件),支付宝的支付成功异步回调
4. 柔性事务-可靠消息+最终一致性方案(异步确保型)
实现:业务处理服务在业务事务提交之前,向实时消息服务请求发送消息,实时消息服务只记录消息数据,而不是真正的发送。业务处理服务在业务事务提交之后,向实时消息服务确认发送。只有在得到确认发送指令后,实时消息服务才会真正发送。
防止消息丢失:
1、做好消息确认机制(pulisher,consumer【手动 ack】)
2、每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送一遍
适用场景:高并发的订单创建与确认、支付
以谷粒商城的下订单与确认订单、支付为例
为了防止订单创建的时候,远程锁定库存服务锁定成功,订单其他方法失败,导致订单回滚,而库存不回滚。远程锁定库存服务在锁定库存之后会自动触发库存检查解锁逻辑——即发送消息给延迟队列(stock.locked),50min后检查订单状态,确定是否解锁,就解决了“库存服务锁定成功,订单服务失败订单回滚”的问题