分布式事务理论基础
背景介绍
公司系统最近完善了微服务架构,以前单实例主从mysql进行了多实例拆分,根据业务分摊主库压力。基于微服务架构设计功能,总是绕不开分布式事务的问题,针对各种分布式事务解决方案进行了详细调研,这一篇文章,主要介绍一下分布式事务理论基础,有了这些理论才能结合业务选择合适的方案。(ps:最佳实践是,通过合理设计尽量避免分布式事务,本地事务才是最高效、最稳定的)
CAP理论和BASE理论
CAP理论
一致性(Consistency) 、可用性(Availability) 、分区容错性(Partition tolerance)
BASE理论
基本可用(Basically Available)、软状态(Soft state)、最终一致性(Eventually consistent)
关于CAP理论和BASE理论的文章太多了,这里不做详细介绍。
读到这里,读者至少需要搞清楚几个问题?
- CAP理论和BASE理论的关系
- CAP理论和分布式事务有什么关系
- BASE理论和分布式事务有什么关系
一句话概括:分布式事务无法同时满足CAP,BASE理论是对CAP中一致性和可用性权衡的结果。我们不都舍弃,找一个折中 的办法。 不能同时拥有,也不想放弃任何一个。那就一个区一半吧。
刚性事务和柔性事务
刚性事务:遵循ACID原则,强一致性。
柔性事务:遵循BASE理论,最终一致性;与刚性事务不同,柔性事务允许一定时间内,不同节点的数据不一致,但要求最终一致。
DTP模型(刚性事务)
XA、2PC、两阶段提交事务都是DTP模型。
DTP模型(Distributed Transaction Processing Reference Model) 是X/Open 组织定义的一套分布式事务的标准。
X/Open DTP 定义了三个组件: AP,TM,RM。
AP(Application Program):应用程序,我们的业务代码。
RM(Resource Manager):资源管理器,这里可以理解为一个DBMS系统,或者消息服务器管理系统,应用程序通过资源管理器对资源进行控制。资源必须实现XA定义的接口。
TM(Transaction Manager):事务管理器,负责协调和管理事务,提供给AP应用程序编程接口(TX协议)以及管理资源管理器
DTP模型分为两个阶段:准备阶段、提交阶段
开源实现方式:Atomikos
最大努力通知(柔性事务)
最简单的一种柔性事务,适用于一些最终一致性时间敏感度低的业务,且被动方处理结果不影响主动方的处理结果。典型的使用场景:如银行通知、商户通知等。
可靠消息最终一致性(柔性事务)
基于Rocket MQ事务消息,实现可靠消息最终一致性。引入rocketMq,中间环节较多,时效性差。
TCC模式(柔性事务)
TCC(Try-Confirm-Cancel)两阶段补偿型。开发难度大,每个子事务需要开发三个接口(Try、Confirm、Cancel),性能高。
主流的分布式事务框架
后面的文档会对主流框架,挨个说明对比。
基于mybatis plus和shardingsphere实现以下方案:
- Atomikos使用
- Seata使用
- Servicecomb-pack使用
参考文章:
https://blog.csdn.net/liaomin416100569/article/details/78651525
https://www.jianshu.com/p/d70df89665b9