赞
踩
2pc就是 2 phase commit 二阶段提交,又叫XA Transactions,这是2pc的一种实现协议,基于数据库层面的。
MySQL 从 5.5 版本开始支持,SQL Server 2005 开始支持,Oracle 7 开始支持。
其中,XA 是一个两阶段提交协议,该协议分为以下两个阶段:
第一阶段:事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作,并反映是 否可以提交.
第二阶段:事务协调器要求每个数据库提交数据。 其中,如果有任何一个数据库否决此次提交,那么所有数据库都会被要求回滚它们在此事务 中的那部分信息。
Seata是由TM,RM,TC。 其中TM和RM是在客户端,TC是事务协调者是需要单独部署的服务端。
AT是2pc的变种,不过不是在数据库层面实现的分布式事务一致性,而是通过保存日志,通过日志来回滚
是两阶段提交协议的演变,比XA协议快一点:
写隔离性质:
读隔离:
在数据库本地事务隔离级别 读已提交(Read Committed) 或以上的基础上,Seata(AT 模式)的默认全局隔离级别是 读未提交(Read Uncommitted) 。
如果应用在特定场景下,必需要求全局的 读已提交 ,目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。
具体点过程:
过程(具体看官网):
UNDO_LOG
表中。product
表中,主键值等于 1 的记录的 全局锁 。注意!seata的at模式下讲的undolog是指seata服务器保存的实现事务的undolog,并不是要操作的数据库自身事务的undolog!
收到 TC 的分支回滚请求,开启一个本地事务,执行如下操作。
通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
数据校验:拿 UNDO LOG 中的后镜与当前数据进行比较,如果有不同,说明数据被当前全局事务之外的动作做了修改。这种情况,需要根据配置策略来做处理,详细的说明在另外的文档中介绍。
根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句:
提交本地事务。并把本地事务的执行结果(即分支事务回滚的结果)上报给 TC。
适用场景:对性能要求不太苛刻,需要代码无侵入、易维护
seata也支持XA模式,XA和AT的区别是,XA是基于数据库提供的一致性协议,而AT是seata通过额外的数据源来维护undolog表来保证一致性。
刚性事务:遵循 ACID 原则,强一致性。
柔性事务:遵循 BASE 理论,最终一致性;
与刚性事务不同,柔性事务允许一定时间内,不同节点的数据不一致,但要求最终一致
按规律进行通知,不保证数据一定能通知成功,但会提供可查询操作接口进行核对。这种方案主要用在与第三方系统通讯时,比如:调用微信或支付宝支付后的支付结果通知。这种 方案也是结合 MQ 进行实现,例如:通过 MQ 发送 http 请求,设置最大通知次数。达到通 知次数后即不再通知。
适用场景:银行通知、商户通知等(各大交易业务平台间的商户通知:多次通知、查询校对、对 账文件),支付宝的支付成功异步回调
实现:业务处理服务在业务事务提交之前,向实时消息服务请求发送消息,实时消息服务只记录消息数据,而不是真正的发送。业务处理服务在业务事务提交之后,向实时消息服务确认发送。只有在得到确认发送指令后,实时消息服务才会真正发送。
防止消息丢失:
1、做好消息确认机制(pulisher,consumer【手动 ack】)
2、每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送一遍
适用场景:高并发的订单创建与确认、支付
以谷粒商城的下订单与确认订单、支付为例
为了防止订单创建的时候,远程锁定库存服务锁定成功,订单其他方法失败,导致订单回滚,而库存不回滚。远程锁定库存服务在锁定库存之后会自动触发库存检查解锁逻辑——即发送消息给延迟队列(stock.locked),50min后检查订单状态,确定是否解锁,就解决了“库存服务锁定成功,订单服务失败订单回滚”的问题
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。