分布式事务
2021-09-06 14:42:33 0 举报AI智能生成
分布式事务
作者其他创作
大纲/内容
子主题
一阶段：准备阶段（Prepare phase）需要Undo和Redo日记记录
二阶段：提交阶段（commit phase）
思想
使用分布式事务成本低，适用于数据库层面
性能不理想，XA无法满足高并发场景
在MySQL中不太理想
XA应用场景不理想
同步阻塞（都被锁了），2PC两个阶段中，协调者和参与者的通信都是同步的，导致整个事务的的长时间阻塞回滚阶段，事务管理器挂了，导致AP一直被锁
总结
2PC模式基于数据库实现1.XA方案2.Seata方案-阿里
图片
1.事务询问协调者向所有的参与者发送一个包含事务内容的 canCommit 请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应
2.各参与者向协调者反馈事务询问的响应：参与者接收来自协调者的 canCommit 请求，如果参与者认为自己可以顺利执行事务，就返回 Yes，否则反馈 No 响应。
一阶段：准备阶段（CanCommit）
1.执行事务预提交
2.中断事务
二阶段：预提交阶段（PreCommit）一和二阶段就是之前2pc中的阶段1拆分的
执行提交
中断事务
1.协调者出现问题
2.协调者和参与者之间的网络故障
阶段三可能出现的问题
三阶段：提交阶段（DoCommit）
优缺点
3PC模式
Try：prepare行为，调用自定义的prepare逻辑
Confirm：commit行为（Try阶段都ok）
Cancel：rollback行为（Try阶段有失败）
比如，服务一因为宕机或者网络异常，没有try，然后整个事务失败，进行cancel，形成空回滚。处理办法：增加一个分支事务记录表，记录下来，有记录才进行cancel
1.空回滚
2.幂等
原因：由于网络原因，某个微服务可能try超时，cancel先执行，try随后才到
3.悬挂
易出现问题
优势在于可以自定义数据操作的粒度
不足之处是对于应用的侵入性非常强
业务逻辑分支都需要try、confirm、cancel三步操作
柔性事务（TCC补偿性方案）代码控制，代码侵入性非常强方案：1.Hmily框架
可靠消息，最终一致性方案A只要成功，B必须成功
强调事务不可分割
原子性 -- Atomic
事务执行前后数据的完整性保持一致
一致性 --Consistency
一个事务执行中，不能影响其他事务
隔离性--Isolation
事务一旦结束，数据就持久到数据库
持久性--Durability
ACID 特性
1.微服务-- 不同数据库
2.跨库操作
3.多服务访问同一个数据库
产生原因
主从数据库的同步问题
强一致性 --Consistency
有请求，就要有相应
可用性--Avaliablity
系统出现脑裂后，仍然提供服务（最基本的能力）
分区容忍性--Partition-tolerance
b style=\
基本可用--Baseically Avaliable
软状态--font color=\"#b71c1c\
最终一致性--Eventually consistent
BASE理论依据A-P理论发展（最终一致性）
1.他解决了什么?
一致性font color=\"#b71c1c\
一致性算法--Raft 算法(领导选举，日志复制font color=\"#b71c1c\
一致性协议之 --ZAB(使用最多)Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。
分布式事务
0 条评论
回复 删除
下一页
