这里开一个新坑就是分布式事务，为了学这一块内容准备这样做
- 学习分布式事务前的基本知识
- 围绕这些解决方案的实现原理是什么
- 不同的解决方案与不同的实现原理进行对比
- 看看都有哪些解决方案，以及它们的优缺点
CAP
分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。这被称为CAP理论
-
C 一致性(Consistency)：要求分布式系统中的所有副本或节点在任何时刻都具有相同的数据值。当系统接收到更新请求后，所有节点必须保证在一定时间内达到一致的状态(强一致性)
-
A 可用性(Availability)：要求分布式系统在任何时刻都能够响应用户的请求并提供正常的服务。即使在节点故障或网络分区等情况下，系统仍然能够继续运行并提供服务
-
P 分区容错性(Partition tolerance)：指系统能够继续运行并保持一致性和可用性，即使在不可避免的网络分区(分布式系统中的消息丢失或延迟)发生时
根据上面三者可以组合的情况有
- CA(一致性和可用性)：系统追求强一致性和高可用性，但在发生网络分区时，系统会停止对外服务，直到分区问题解决。关系型数据库通常采用这种方案。
- AP(可用性和分区容错性)：系统追求高可用性和分区容错性，即使发生网络分区，系统仍然可以继续运行，但可能导致数据的一致性问题。例如，大规模分布式系统如互联网应用中的NoSQL数据库常采用这种方案。
- CP(一致性和分区容错性)：在这种方案中，系统追求强一致性和分区容错性，但在发生网络分区时，可能会牺牲可用性。这意味着系统可能在网络分区期间无法提供服务。例如，一些分布式数据库系统采用这种方案。
- CAP的一致性指的是强一致性
- CAP中分布式事务的一致性是多个节点状态的一致性，而ACID中事务的一致性指的是DB的约束定义的前后一致性
- 根据 CAP 各个的描述可以得出系统三者不可能同时满足，需要在系统设计时根据情况舍弃
BASE
BASE是Basically Available（基本可用）、**Soft state（软状态）和Eventually consistent（最终一致性）**三个短语的简写，BASE是基于CAP定理逐步演化而来，对CAP中一致性和可用性权衡的结果，核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual consistency)
- Basically Available(基本可用): 指分布式系统在出现不可预知故障的时候，允许损失部分可用性(系统仍然可用)
- Soft state(软状态): 弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
- Eventually consistent(最终一致性): 强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性
BASE理论提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。
分布式的理论基础是CAP，分布式系统中，P(分区容错)是必选项，所以只能在AP或者CP中选择。
-
分布式理论的CP -> 刚性事务，遵循ACID，对数据要求强一致性
-
分布式理论的AP+BASE -> 柔性事务，遵循BASE，允许一定时间内不同节点的数据不一致，但要求最终一致
刚性事务基于分布式理论的CP，遵循ACID，对数据要求强一致性。包括 2PC、3PC
柔性事务基于分布式理论的AP，遵循BASE，允许一定时间内不同节点的数据不一致，但要求最终一致。它们又可以分为两种
- 基于补偿的有 TCC 与 SAGA
- 基于最终一致性的有 本地消息、事务消息、尽最大努力通知
整体分布式事务实现原理根据资源在分布式事务的角色可以分为：
-
AP 应用程序处理器，一般是发起分布式事务的一方
-
RM 资源管理器，负责管理和控制分布式系统中的特定资源或数据库。资源管理器协调事务的执行，包括处理事务的提交和回滚，以及确保数据的一致性和完整性。
-
TM 事务管理器，负责协调和管理分布式事务的执行。事务管理器协调不同资源管理器的操作，以确保所有参与的资源在事务提交或回滚时保持一致性，并提供事务的ACID
-
TC 事务协调者，维护全局和分支事务的状态，驱动全局事务提交或回滚(Seata 引入)
根据分布式事务的组成分为
-
事务分支：每个服务管理的事务组成部分，称为事务分支，
RM服务会在全局事务上，注册一个事务分支 -
分支操作：对于
RM服务，在TCC事务模式下，会实现Try/Confirm/Cancel三个操作，多个分支操作配合完成一个分支事务 -
本地事务：
RM服务可能访问一个数据库，创建一个本地事务，也可能访问多个数据库，创建多个本地事务
找了一下分布式事务的实现方案，发现两种 DTM 与 SEATA
| 特性 | DTM | SEATA |
|---|---|---|
| 语言 | Go、Java、python、php、c#… | Java、Go、Python |
| 异常处理 | 子事务屏障自动处理 | 手动处理 |
| TCC事务 | ✓ | ✓ |
| XA事务 | ✓ | ✓ |
| AT事务 | 建议使用XA | ✓ |
| SAGA事务 | 支持并发 | 状态机模式 |
| 二阶段消息 | ✓ | ✗ |
| 单服务多数据源 | ✓ | ✗ |
| 通信协议 | HTTP、gRPC | dubbo、gRPC |
| 仓库 | https://github.com/dtm-labs/dtm.git | https://github.com/seata/seata.git |
接下来异常介绍几种分布式事务的实现原理、优缺点以及适用场景
- 二阶段提交
- 三阶段提交
- TCC
- SAGA
- AT
- 通知型事务
- 二阶段消息(DTM)
- 异常处理优化(DTM)
- Percolator