1.分布式-理论

BASE（Basically Available、Soft state、Eventual consistency）是基于CAP理论逐步演化而来的，核心思想是即便不能达到强一致性（Strong consistency），也可以根据应用特点采用适当的方式来达到最终一致性（Eventual consistency）的效果。
两个对冲理念：ACID和BASE

ACID是传统数据库常用的设计理念，追求强一致性模型。

BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

1.Basically Available(基本可用)

基本可用本质是一种妥协，也就是出现节点故障或者系统过载时，通过牺牲非核心

功能的可用性，保障核心功能的稳定运行。

实现基本可用的几个策略：

流量削峰
延迟响应，异步处理
体验降级
过载保护熔断/限流
故障隔离

2.Soft state（软状态）

弱状态允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延迟。

原子性是硬状态，要求多个节点的数据副本都是一致的。

3.Eventually consistent（最终一致性）

分布式系统不能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据

一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制

方案设计等等因素。

四、什么是分布式事务

分布式事务是相对本地事务而言的，对于本地事务，利用数据库本身的事务机制，

就可以保证事务的ACID特性

1.本地事务ACID

ATOMICITY

原子性：一个事务中所有操作必须全部完成,要么全部不完成；

CONSISTENCY

一致性：在事务开始或结束时，数据库应该在一致状态；

ISOATION

隔离性：事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知；

DURABILITY

持久性：一旦事务完成，就不能返回，事务对数据所做的变更完全保存在数据库中；

2.分布式事务

在分布式环境下，会涉及到多个数据库。分布式事务其实就是将对一个库事务的概念

扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。

分布式事务处理的关键是：

需要记录事务在任何节点所做的所有动作；
事务进行的所有操作要么全部提交，要么全部回滚；

五、分布式事务解决方案

1.二阶段提交2PC

这是最传统的分布式事务协议。它分为两个阶段：准备阶段和提交阶段。在准备阶段，事务协调者询问所有参与节点是否准备好提交事务；如果所有节点都回复"准备好"，则进入提交阶段，协调者命令所有节点提交事务；如果有任何节点无法准备，协调者命令所有节点回滚。

2PC缺点：

1.性能阻塞问题

执行过程中，所有参与节点都是事务阻塞性的，当参与者占有公共资源时，其他第三方节点访问公共资源就不得不处于阻塞状态，为了数据的一致性而牺牲了可用性，对性能影响较大，不适合高并发高性能场景

2.可靠性问题

2PC非常依赖协调者，当协调者发生故障时，尤其是第二阶段，那么所有的参与者就会都处于锁定事务资源的状态中，而无法继续完成事务操作（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

3.数据一致性问题

在阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

4.二阶段无法解决的问题

协调者在发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了，那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

2.三阶段提交3PC

3PC，三阶段提交协议，是二阶段提交协议的改进版本。三阶段提交有两个改动点：

在协调者和参与者中都引入超时机制

为了解决2PC中协调者单点故障的问题，3PC引入了预提交阶段

所以3PC分为3个阶段：CanCommit 准备阶段、PreCommit 预提交阶段、DoCommit 提交阶段

3PC缺点

与2PC相比，3PC降低了阻塞范围，并且在等待超时后，协调者和参与者会中断事务，避免了协调者单点问题，阶段三中协调者出现问题时，参与者会继续提交事务。但数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 doCommit 指令时，此时如果协调者请求中断事务，而协调者因为网络问题无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

2PC和3PC都无法保证数据绝对的一致性，一般为了预防这种问题，可以添加一个报警，比如监控到事务异常的时候，通过脚本自动补偿差异的信息。

3.TCC（Try-Confirm-Cancel）

TCC模型将事务操作分为三个阶段：Try（预留资源）、Confirm（确认提交）和Cancel（取消释放）。在Try阶段，每个参与者尝试预留资源但不实际提交，如果所有参与者都能预留成功，则在Confirm阶段真正提交事务；否则，在Cancel阶段撤销之前的操作。

4.Saga

Saga通过一系列的短事务（也称为子事务）来模拟长事务，每个子事务都是可补偿的。如果某个子事务失败，Saga会执行之前所有子事务的补偿操作，从而达到事务的最终一致状态。

5.基于消息的最终一致性:

在这种模式下，服务之间通过消息队列异步通信，利用消息的发送与确认机制保证最终一致性。通常包括发布/订阅模型和事件驱动架构，如 Saga 也可以通过这种方式实现。

6.最大努力通知

最大努力通知也称为定期校对，是对MQ事务方案的进一步优化。它在事务主动方增加了消息校对的接口，如果事务被动方没有接收到主动方发送的消息，此时可以调用事务主动方提供的消息校对的接口主动获取。

最大努力通知，事务主动方尽最大努力（重试，轮询....）将事务发送给事务接收。被动方也可调用接口校对并消费。

7.事务补偿机制

通过业务层面的设计实现事务的补偿逻辑，允许服务在失败后通过反向操作恢复到一致状态，适用于对实时性要求不高的场景。