作者:佚名 2021-09-29 09:07:37
开发
前端
分布式 PC 和 3PC 是一种强一致性事务,不过还是有数据不一致,阻塞等风险,而且只能用在数据库层面。
原子性(Atomicity),可以理解为一个事务内的所有操作要么都执行,要么都不执行。
一致性(Consistency),可以理解为数据是满足完整性约束的,也就是不会存在中间状态的数据,比如你账上有400,我账上有100,你给我打200块,此时你账上的钱应该是200,我账上的钱应该是300,不会存在我账上钱加了,你账上钱没扣的中间状态。
隔离性(Isolation),指的是多个事务并发执行的时候不会互相干扰,即一个事务内部的数据对于其他事务来说是隔离的。
Redis 的事务不能保证所有操作要么都执行要么都不执行。
Redis事务中的某个命令失败了,之后的命令还是会被处理,Redis 不会停止命令,意味着也不会回滚。
是一种强一致性设计
引入一个事务协调者的角色来协调管理各参与者(也可称之为各本地资源)的提交和回滚,二阶段分别指的是准备(投票)和提交两个阶段
正常情况
异常情况
协调者故障分析
通过选举得到新协调者
总结
TCC
思想上类似2PC,TCC 就是通过代码人为实现了两阶段提交
TCC模型还有个事务管理者的角色,变成多点,引入集群。用来记录TCC全局事务状态并提交或者回滚事务
引入超时,超时后进行补偿,并且不会锁定整个资源
优势
劣势
撤销和确认操作的执行可能需要重试,因此还需要保证操作的幂等
利用各系统本地的事务来实现分布式事务
有一张存放本地消息的表,一般都是放在数据库中,然后在执行业务的时候将业务的执行和将消息放入消息表中的操作放在同一个事务中,保证消息放入本地表中业务肯定是执行成功的
后台任务定时去读取本地消息表,筛选出还未成功的消息再调用对应的服务,服务更新成功了再变更消息的状态。
重试就得保证对应服务的方法是幂等的,而且一般重试会有最大次数,超过最大次数可以记录下报警让人工处理
实现的是最终一致性
利用MQ事务
先给 Broker 发送事务消息即半消息,半消息不是说一半消息,而是这个消息对消费者来说不可见,然后发送成功后发送方再执行本地事务
再根据本地事务的结果向 Broker 发送 Commit 或者RollBack命令
RocketMQ的发送方会提供一个反查事务状态接口,如果一段时间内半消息没有收到任何操作请求,那么 Broker 会通过反查接口得知发送方事务是否执行成功,然后执行Commit 或者RollBack命令。
如果是 Commit 那么订阅方就能收到这条消息,然后再做对应的操作,做完了之后再消费这条消息即可
如果是RollBack那么订阅方收不到这条消息,等于事务就没执行过
消息事务实现的也是最终一致性
长事务的解决方案,更适合于“业务流程长、业务流程多”的场景
特别是针对参与事务的服务是遗留系统服务,此类服务无法提供TCC模式下的三个接口,就可以采用Saga模式
针对每一个分布式事务的每个执行操作或者是步骤都是一个 Ti,例如扣减库存是T1、创建订单是T2、支付服务是T3。那么针对每个Ti都对应一个补偿动作Ci,例如回复库存C1、订单回滚C2、支付回滚C3
优势
劣势
两种恢复策略
向前恢复:对于执行不通过的事务,会尝试重试事务,这里有一个假设就是每个子事务最终都会成功。这种方式适用于必须要成功的场景
向后恢复:在执行事务失败时,补偿所有已完成的事务,是“一退到底”的方式。
两种模式
编排
控制
标题名称:分布式事务知识小结
转载注明:http://www.shufengxianlan.com/qtweb/news26/316026.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联