分布式事务
2022-05-19 16:08:27 2 举报AI智能生成
简单介绍分布式事务详情
作者其他创作
大纲/内容
什么是分布式事务
分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务。简言之：跨jvm进程产生分布式事务。分布事务问题也叫分布式数据一致性问题：在分布式场景中保证多个节点数据的一致性
分布式事务模型
XA分布式规范：仅仅是个规范
2PC分布式规范
具体步骤
1、准备阶段
TM先发送个prepare消息给各个数据库，让各个库先把分布式事务里要执行的各种操作，各个数据库会准备好随时可以提交或者是回滚
各个数据库都返回一个响应消息给事务管理器，如果成功了就发送一个成功的消息，如果失败了就发送一个失败的消息
2、提交阶段
第一种情况，TM发现某个数据库告诉他说，我这儿失败了
把本地的那个事务回滚，然后各个库都回滚好了以后就通知TM，TM就认为整个分布式事务都回滚了
把本地的那个事务回滚，然后各个库都回滚好了以后就通知TM，TM就认为整个分布式事务都回滚了
第二种情况，TM接收到所有的数据库返回的消息都是成功
提交好了通知下TM，所有数据库的事务都提交成功了通知TM,TM就认为整个分布式事务都执行成功 了
提交好了通知下TM，所有数据库的事务都提交成功了通知TM,TM就认为整个分布式事务都执行成功 了
缺陷
同步阻塞：在阶段一里执行prepare操作会占用资源，一直到整个分布式事务完成，才会释放资源
单点故障：TM是个单点，如果TM在第二阶段出现故障，那么RM会一直锁定
脑裂问题：在阶段二中，如果发生了脑裂问题，那么就会导致某些数据库没有接收到commit消息，有些库收到了commit消息，结果有些库没有收到
3PC分布式规范
针对2PC做的一个改进，主要就是为了解决2PC协议的问题
具体步骤
1、CanCommit阶段
TM发送一个CanCommit消息给各个数据库，然后各个库返回个结果,不会执行实际的SQL语句的
就是各个库看看自己网络环境啊，各方面是否ready，这个阶段会有超时中止机制
就是各个库看看自己网络环境啊，各方面是否ready，这个阶段会有超时中止机制
2. PreCommit阶段
会执行各个SQL语句，只是不提交
如果有个库对CanCommit消息返回了失败,TM发送abort消息给各个库,取消分布式事务
3. DoCommit阶段
PreCommit阶段都返回了成功，那么发送DoCommit消息给各个库，提交事务，各个库如果都返回提交成功给TM，那么分布式事务成功
如果有个库对PreCommit返回的是失败，那么TM认为分布式事务失败，直接发abort消息给各个库，回滚，各个库回滚成功之后通知TM，分布式事务回滚成功
改进点
引入了CanCommit阶段，用于询问所有参与者是否可以执行事务并且响应，他可以尽早发现无法执行操作而中止后续行为
DoCommit阶段 。事务协调者和参与者都引入了超时机制，一旦超时，事务协调者和参与者会继续提交事务，并且认为处于成功状态，因为在这种情况下，事务默认成功的可能性比较大
资源阻塞问题也能减轻
缺陷
如果TM在DoCommit阶段发送了abort消息给各个库，结果因为脑裂问题，某个库没接收到abort消息，自己还因为超时机制的执行了commit操作
总结
不管是2PC还是3PC 都是数据一致性解决方案的实现
解决方案
TCC补偿方案
具体步骤
1.Try 阶段主要是对业务系统做数据检测及资源预留
2.Confirm ：确认真正执行的任务，只操作Try阶段预留的资源
3.Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
接口的幂等性保证，try confirm和cancel都可能多次调用
可靠消息最终一致性方案
具体步骤
1.A系统先发送一个prepared消息到mq，如果这个prepared消息发送失败那么就直接取消操作别执行了
2.如果这个消息发送成功过了，那么接着执行本地事务，如果成功就告诉mq发送确认消息，如果失败就告诉mq回滚消息
3.如果发送了确认消息，那么此时B系统会接收到确认消息，然后执行本地的事务
4.mq会自动定时轮询所有prepared消息回调你的接口，问你，这个消息是不是本地事务处理失败了，所有没发送确认消息？那是继续重试还是回滚？一般来说这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，别确认消息发送失败了。
5.这个方案里，要是系统B的事务失败了咋办？重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如B系统本地回滚后，想办法通知系统A也回滚；或者是发送报警由人工来手工回滚和补偿
使用场景
调用起来很耗时的操作
最大努力通知方案
最大努力通知也称为定期校对，是对MQ事务方案的进一步优化。它在事务主动方增加了消息校对的接口，如果事务被动方没有接收到消息，此时可以调用事务主动方提供的消息校对的接口主动获取。
但是最大努力通知，事务主动方尽最大努力（重试，轮询....）将事务发送给事务接收方，但是仍然存在消息接收不到，此时需要事务被动方主动调用事务主动方的消息校对接口查询业务消息并消费，这种通知的可靠性是由事务被动方保证的。
最大努力通知适用于业务通知类型，例如微信交易的结果，就是通过最大努力通知方式通知各个商户，既有回调通知，也有交易查询接口。
在可靠消息事务中，事务主动方需要将消息发送出去，并且消息接收方成功接收，这种可靠性发送是由事务主动方保证的；
服务框架
seata
AT模式（AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，几乎0学习成本。）
XA模式
TCC模式
saga模式
ByteTCC
tcc-transaction
himly
0 条评论
下一页
