#JAVA破局之路#分布式事务解决方案),分布式事务详解(mysql事务如何实现的( 五 )


缺点:
如果参与者收到了preCommit消息后 , 出现了网络分区 , 那么参与者等待超时后 , 都会进行事务的提交 , 这必然会出现事务不一致的问题 。
2.4TCC方案TCC其实就是采用的补偿机制 , 其核心思想是:针对每个操作 , 都要注册一个与其业务逻辑对应的确认和补偿(撤销)操作 。
其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作 。 Try部分完成业务的准备工作 , confirm部分完成业务的提交 , cancel部分完成事务的回滚 。
#JAVA破局之路#分布式事务解决方案),分布式事务详解(mysql事务如何实现的
文章图片
优点:跟2PC、3pc比起来 , 实现以及流程相对简单了一些 , 但数据的一致性比2PC也要差一些
缺点:TCC属于应用层的一种补偿方式 , 所以需要程序员在实现的时候多写很多补偿的代码 , 而且补偿的时候也有可能失败 , 在一些场景中 , 一些业务流程可能用TCC不太好定义及处理 。
2.5MQ(事务消息)目前 , 仅阿里云的RocketMQ支持事务消息 。 帮助用户实现类似X/OpenXA的分布事务功能 , 通过MQ事务消息能达到分布式事务的最终一致 。
#JAVA破局之路#分布式事务解决方案),分布式事务详解(mysql事务如何实现的
文章图片
流程说明:
1.发送方向MQ服务端发送消息
2.MQServer将消息持久化成功之后 , 向发送方ACK确认消息已经发送成功 , 此时消息为半消息
3.发送方开始执行本地事务逻辑
4.发送方根据本地事务执行结果向MQServer提交二次确认(Commit或是Rollback) , MQServer收到Commit状态则将半消息标记为可投递 , 订阅方最终将收到该消息;MQServer收到Rollback状态则删除半消息 , 订阅方将不会接受该消息
5.在断网或者是应用重启的特殊情况下 , 上述步骤4提交的二次确认最终未到达MQServer , 经过固定时间后MQServer将对该消息发起消息回查
6.发送方收到消息回查后 , 需要检查对应消息的本地事务执行的最终结果
7.发送方根据检查得到的本地事务的最终状态再次提交二次确认 , MQServer仍按照步骤4对半消息进行操作其中 , 事务消息发送对应步骤1、2、3、4 , 事务消息回查对应步骤5、6、7
2.6Lcn事务2.6.1背景LCN名称是由早期版本的LCN框架命名 , 在设计框架之初的1.0~2.0的版本时框架设计的步骤是如下,各取其首字母得来的LCN命名 。
锁定事务单元(lock)
确认事务模块状态(confirm)
通知事务(notify)
2.6.2框架定位LCN并不生产事务 , LCN只是本地事务的协调工
TX-LCN定位于一款事务协调性框架 , 框架其本身并不操作事务 , 而是基于对事务的协调从而达到事务一致性的效果 。
2.6.3事务控制原理TX-LCN由两大模块组成,TxClient、TxManager ,
TxClient作为模块的依赖框架 , 提供TX-LCN的标准支持 , TxManager作为分布式事务的控制方 。 事务发起方或者参与都由
TxClient端来控制 。
原理图:
#JAVA破局之路#分布式事务解决方案),分布式事务详解(mysql事务如何实现的
文章图片
·1.创建事务组
是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象 , 然后拿到事务标示GroupId的过程 。
·2.加入事务组
添加事务组是指参与方在执行完业务方法以后 , 将该模块的事务信息通知给TxManager的操作 。
·3.通知事务组
是指在发起方执行完业务代码以后 , 将发起方执行结果状态通知给TxManager,TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务 , 并返回结果给事务发起方 。
2.7Seata事务2.7.1背景Seata(SimpleExtensibleAutonomousTransactionArchitecture)是阿里巴巴开源的分布式事务中间件 , 以高效并且对业务0侵入的方式 , 解决微服务场景下面临的分布式事务问题 。