分布式事务
2021-07-02 14:38:04 0 举报AI智能生成
分布式事务常见方案
作者其他创作
大纲/内容
分布式事务
2PC 二阶段提交
二阶段提交是一种强一致性设计
引入一个事务协调者的角色来协调管理各参与者（也可称之为各本地资源）的提交和回滚
二阶段分别指的是准备（投票）和提交两个阶段
准备阶段协调者会给各参与者发送准备命令，你可以把准备命令理解成除了提交事务之外啥事都做完了
同步等待所有资源的响应之后就进入第二阶段即提交阶段（注意提交阶段不一定是提交事务，也可能是回滚事务）假如在第一阶段所有参与者都返回准备成功，那么协调者则向所有参与者发送提交事务命令，然后等待所有事务都提交成功之后，返回事务执行成功
假如在第一阶段有一个参与者返回失败，那么协调者就会向所有参与者发送回滚事务的请求，即分布式事务执行失败
第二阶段失败的话，会不断重试，直到成功为止，最后实在不行只能人工介入
2PC 是一种尽量保证强一致性的分布式事务，因此它是同步阻塞的，而同步阻塞就导致长久的资源锁定问题，总体而言效率低，并且存在单点故障问题（事务协调者存在单点故障），在极端条件下存在数据不一致的风险
2PC 适用于数据库层面的分布式事务场景
3PC 三阶段提交
相比于 2PC 它在参与者中也引入了超时机制，并且新增了一个阶段使得参与者可以利用这一个阶段统一各自的状态
3PC 包含了三个阶段，分别是准备阶段、预提交阶段和提交阶段
准备阶段的变更成不会直接执行事务，而是会先去询问此时的参与者是否有条件接这个事务，因此不会一来就干活直接锁资源，使得在某些资源不可用的情况下所有参与者都阻塞着
预提交阶段的引入起到了一个统一状态的作用，它像一道栅栏，表明在预提交阶段前所有参与者其实还未都回应，在预处理阶段表明所有参与者都已经回应了
引入了超时机制，参与者就不会傻等了，如果是等待提交命令超时，那么参与者就会提交事务了，因为都到了这一阶段了大概率是提交的，如果是等待预提交命令超时，那该干啥就干啥了，反正本来啥也没干
超时机制也会带来数据不一致的问题，比如在等待提交命令时候超时了，参与者默认执行的是提交事务操作，但是有可能执行的是回滚操作，这样一来数据就不一致了
Seata-Saga TCC模式
2PC 和 3PC 都是数据库层面的，而 TCC 是业务层面的分布式事务
Try 指的是预留，即资源的预留和锁定，注意是预留。Confirm 指的是确认操作，这一步其实就是真正的执行了。Cancel 指的是撤销操作，可以理解为把预留阶段的动作撤销了。
TCC模型还有个事务管理者的角色，用来记录TCC全局事务状态并提交或者回滚事务
TCC 对业务的侵入较大和业务紧耦合，需要根据特定的场景和业务逻辑来设计相应的操作
撤销和确认操作的执行可能需要重试，因此还需要保证操作的幂等
TCC可以跨数据库、跨不同的业务系统来实现事务
Seata-AT
向事务协调者开启一个全局事务，并且注册分支事务，事务协调者会生成一个全局事务XID
所有的本地服务的分支事务都会跟全局事务XID关联
写入业务数据和undo_log提交本地事务，上报分支事务处理结果给事务协调者
分支事务执行成功 后台有线程定时删除事务协调者对应数据库中记录的事务记录
分支事务执行失败 根据undo_log日志对数据进行回滚
基于可靠消息最终一致 Rocket MQ
RocketMQ 就很好的支持了消息事务
消息事务实现的也是最终一致性
第一步先给 Broker 发送事务消息即半消息，半消息不是说一半消息，而是这个消息对消费者来说不可见，然后发送成功后发送方再执行本地事务span style=\
再根据本地事务的结果向 Broker 发送 Commit 或者 RollBack 命令
尽最大努力通知
最大努力通知其实只是表明了一种柔性事务的思想
适用于对时间不敏感的业务
会有后台任务定时去查看未完成的消息，然后去调用对应的服务，当一个消息多次调用都失败的时候可以记录下然后引入人工，或者直接舍弃
0 条评论
回复 删除
下一页
