分布式事务理论基础

背景介绍

公司系统最近完善了微服务架构，以前单实例主从mysql进行了多实例拆分，根据业务分摊主库压力。基于微服务架构设计功能，总是绕不开分布式事务的问题，针对各种分布式事务解决方案进行了详细调研，这一篇文章，主要介绍一下分布式事务理论基础，有了这些理论才能结合业务选择合适的方案。（ps：最佳实践是，通过合理设计尽量避免分布式事务，本地事务才是最高效、最稳定的）

CAP理论和BASE理论

CAP理论

一致性(Consistency) 、可用性(Availability) 、分区容错性(Partition tolerance)

BASE理论

基本可用（Basically Available）、软状态（Soft state）、最终一致性（Eventually consistent）

关于CAP理论和BASE理论的文章太多了，这里不做详细介绍。
读到这里，读者至少需要搞清楚几个问题？

1. CAP理论和BASE理论的关系
2. CAP理论和分布式事务有什么关系
3. 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

本文地址：https://blog.csdn.net/zjy_love_java/article/details/107193653