首页 思维导图 详情

分布式事务

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