分布式事务思维导图
2024-01-14 18:24:22 0 举报
AI智能生成
分布式事务思维导图是一份展示分布式事务核心概念、理论、协议和技术的文件。它涵盖了事务的基本概念,如原子性、一致性、隔离性和持久性(ACID),以及分布式事务的需求和挑战。此外,思维导图还介绍了分布式事务的处理方式,包括两阶段提交(2PC)、三阶段提交(3PC)和TCC(Try-Confirm-Cancel)协议。此外,还涵盖了分布式事务的实际应用,例如数据库分片、微服务和云计算等领域。这份思维导图对于理解分布式事务的原理和应用具有重要的参考价值。
作者其他创作
大纲/内容
分布式理论基础
CAP理论
CAP理论概述
CAP理论是计算机科学中的一个重要理论,用于指导分布式系统的设计和实现
CAP理论指出,一个分布式系统无法同时满足一致性、可用性和分区容忍性三个特性
CAP理论在分布式系统设计中具有重要意义,帮助设计师在满足不同需求的前提下进行权衡和取舍
CAP理论中各特性的定义
一致性:指分布式系统中的数据在同一时刻具有相同的值
可用性:指分布式系统在正常运行状态下,用户请求总是能够得到响应
分区容忍性:指分布式系统在遇到网络分区等异常情况时,仍能保持部分可用状态
CAP理论在实践中的应用
在设计分布式系统时,需要根据实际需求,权衡CAP理论中的三个特性,进行相应的取舍
在某些场景中,可能会牺牲一致性或可用性,以换取更高的分区容忍性
在另一些场景中,可能需要牺牲分区容忍性,以换取更高的一致性或可用性
CAP理论的发展
随着分布式系统的不断发展,CAP理论也在不断完善和扩展
新的理论,如BASE理论,提出了在满足基本可用性和软状态允许的情况下实现最终一致性的解决方案
BASE理论
BASE理论概述
BASE理论是一种分布式系统架构理论,用于保证系统的可用性和一致性
BASE理论包括基本可用(BA)、软状态(S)和最终一致性(E)三个原则
BASE理论应用场景
在分布式数据库系统中,BASE理论可以用于保证数据的一致性和可用性
在微服务架构中,BASE理论可以用于处理服务之间的调用和通信问题
BASE理论实现难点
在实现BASE理论时,需要权衡系统的可用性和一致性,以实现最佳的性能和可靠性
在分布式系统中,实现最终一致性需要解决数据复制、数据同步等问题
在微服务架构中,实现BASE理论需要解决服务之间的通信协议、异常处理等问题
强一致性模型
DTP模型
DTP模型概述
DTP模型是一种分布式事务处理模型,用于解决分布式系统中的事务管理问题
DTP模型由三个主要组件构成:应用程序、事务管理器和资源管理器
DTP模型通过定义一系列协议和接口,实现分布式系统中的事务管理功能
DTP模型的组件
应用程序:负责定义事务操作和提交、回滚等操作
事务管理器:负责管理和协调分布式事务,包括事务的提交、回滚、隔离等
资源管理器:负责管理和提供分布式系统中的资源,如数据库、消息队列等
DTP模型的工作原理
应用程序通过事务管理器与资源管理器交互,完成事务操作
事务管理器负责维护事务的状态,并在必要时协调资源管理器进行提交、回滚等操作
资源管理器负责处理事务相关的操作,如数据库的读写、消息队列的发送等
DTP模型的优点
DTP模型提供了一种统一的分布式事务处理模型,简化了分布式系统的设计和开发
DTP模型实现了事务的隔离和一致性,提高了分布式系统的可靠性和性能
DTP模型通过定义标准接口和协议,便于不同系统和技术之间的互操作性
XA规范
2PC
阶段一:TM(事务管理器)通知各个RM(资源管理器)准备提交它们的事务分支
阶段二:TM根据阶段1各个RM prepare的结果,决定是提交还是回滚事务
存在的问题
同步阻塞
单点故障
数据不一致
3PC
3PC是对2PC的改进版本
两个改动点
引入超时机制,协调者和参与者都引入超时机制
在第一阶段和第二阶段之间插入准备阶段
CanCommit
PreCommit
doCommit
最终一致性模型
TCC
try阶段:调用 Try 接口,尝试执行业务,完成所有业务检查,预留业务资源
Confirm 或 Cancel 阶段
两者是互斥的只能进入其中一个,且都满足幂等性,允许失败重试
comfirm:对业务系统做确认提交,确认执行业务操作,
不做其他业务检查,只使用 Try 阶段预留的业务资源
不做其他业务检查,只使用 Try 阶段预留的业务资源
cancel:在业务执行错误,需要回滚的状态下执行业务取消,释放预留资源
confirm/cancel失败了如何处理:
TCC 中会添加事务日志,如果 Confirm 或者 Cancel 阶段出错,
则会进行重试,所以这两个阶段需要支持幂等;如果重试失败,
则需要人工介入进行恢复和处理等。
TCC 中会添加事务日志,如果 Confirm 或者 Cancel 阶段出错,
则会进行重试,所以这两个阶段需要支持幂等;如果重试失败,
则需要人工介入进行恢复和处理等。
可靠消息的最终一致性
异步化在分布式系统设计中随处可见,基于消息队列的最终一致性就是一种异步事务机制,
在业务中广泛应用
在业务中广泛应用
本地消息表
核心思想是将分布式事务拆分成本地事务进行处理,通过消息日志的方式来异步执行。
1、上游系统通过本地事务保证业务数据和消息数据同时写入成功
2、上游系统启动定时任务扫描消息表来发送消息到下游,
通过MQ服务的发送确认模式,保证消息投递到MQ中,
发送成功可以删除本地消息表或设置为已完成
通过MQ服务的发送确认模式,保证消息投递到MQ中,
发送成功可以删除本地消息表或设置为已完成
3、下游系统消费消息时需采用主动提交模式,确保消息消费成功,消费不成功,消息会重复投递
所以下游系统需要实现幂等性
所以下游系统需要实现幂等性
上述过程MQ很重要,确保消息不丢失,如果不信任MQ的数据保存,一种更严苛的做法是,上游系统删除消息表
需要接受下游系统发送的消费完成的消息后,再删除。
需要接受下游系统发送的消费完成的消息后,再删除。
RocketMq 事务消息
最大努力通知
最大努力通知型( Best-effort delivery)是最简单的一种柔性事务,
适用于一些最终一致性时间敏感度低的业务,且被动方处理结果
不影响主动方的处理结果。典型的使用场景:如银行通知、商户通知等
一般符合以下特点:
1、不可靠消息:业务活动主动方,在完成业务处理之后,向业务活动的被动方发送消息,
直到通知N次后不再通知,允许消息丢失(不可靠消息)。
2、定期校对:业务活动的被动方,根据定时策略,向业务活动主动方查询(主动方提供查询接口),
恢复丢失的业务消息。
适用于一些最终一致性时间敏感度低的业务,且被动方处理结果
不影响主动方的处理结果。典型的使用场景:如银行通知、商户通知等
一般符合以下特点:
1、不可靠消息:业务活动主动方,在完成业务处理之后,向业务活动的被动方发送消息,
直到通知N次后不再通知,允许消息丢失(不可靠消息)。
2、定期校对:业务活动的被动方,根据定时策略,向业务活动主动方查询(主动方提供查询接口),
恢复丢失的业务消息。
数据一致性算法
Paxos
ZAB协议
Raft
Gossip
具体实现或框架
Seata
0 条评论
下一页