cyxCoder

一、两段提交和三段提交

分布式系统为解决跨多个节点的事务一致性问题，保障分布式事务的ACID （Atomic原子性，Consistency一致性，Isolation隔离性，Durability持久性）提出了2PC、3PC两个概念。

先了解2个角色定义：

• 协调者:负责管理和控制整个分布式事务流程的节点。
• 参与者:实际执行事务操作的节点。

1.1、两段提交（2PC, Two-Phase Commit）

2PC- 阶段1：提交事务请求（投票阶段）

• 协调者向所有参与者发送prepare请求，询问是否可以执行提交操作。
• 参与者根据自身状态决定是否可以继续，并将决策持久化。如果可以，则进入“已准备”状态；否则拒绝。

2PC- 阶段2：执行事务提交（commit、rollback）

• 若所有参与者都回复可以提交，协调者发送commit指令，各参与者执行实际的事务操作并确认。
• 如果有任何一个参与者不同意，协调者发送rollback指令，所有参与者回滚操作。

两段提交简单易懂，实现较为直接，但会出现一些问题：

• 同步阻塞问题：当部分参与者不可用时，其他参与者会被阻塞。
• 单点故障问题：提交的时候协调者发生故障。
• 数据不一致问题。

1.2、三段提交（3PC, Three-Phase Commit）

三段提交其实就是在两段提交的第一阶段与第二阶段之间插入了一个预提交阶段

3PC- 阶段1：是否提交（类似2PC的阶段1）

• 协调者询问参与者是否可以执行事务，参与者若认为可以执行则回复Yes。

3PC- 阶段2：预先提交（如果预提交有返回未成功则事务中断，回滚，成功就提交）

• 协调者收到所有Yes后，发送预提交消息给所有参与者。
• 参与者接收到消息后，执行事务操作但不提交，而是进入预备提交状态，并返回结果给协调者。

3PC- 阶段3：提交（commit、rollback）

三阶段提交是“非阻塞”协议。

3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

二、CAP 理论

CAP理论，也被称为布鲁尔定理，是分布式系统设计中的一个核心概念。它指出在一个分布式系统中，不可能同时完全实现以下三个特性：

• 一致性（Consistency）：所有节点在同一时间具有相同的数据副本。
• 可用性（Availability）：每个请求都能在合理的时间内收到响应，而不必担心系统故障。
• 分区容忍性（Partition Tolerance）：即使网络分区发生，系统仍能继续运作。

根据CAP理论，在任何给定的时间点，一个分布式系统只能同时满足上述三个特性中的两个。这意味着必须在设计时做出权衡：

• CA(放弃P)：即将所有的数据放在一个节点，这样满足一致性、可用性，但在实际的分布式环境中，P是不可避免的。
• AP(放弃C)：优先保证可用性和分区容忍性，可能会牺牲数据的一致性。放弃强一致性，用最终一致性来保证。
• CP(放弃A)：优先保证一致性和分区容忍性，可能会牺牲系统的可用性。一旦系统遇见故障，受到影响的服务器需要等待一段时间，在恢复期间无法对外提供服务。

三、BASE 理论

BASE理论是分布式系统设计中的一个重要概念，它与传统的ACID事务特性形成对比。BASE理论强调的是系统的可用性和分区容忍性，而不是严格的强一致性。以下是BASE理论的详细介绍：

Basically Available（基本可用）

• 系统保证大部分时间是可用的，即使在部分组件故障的情况下也能提供服务。
• 用户可能会遇到一些延迟或降级的服务，但不会完全不可用。（服务降级、页面降级）

Soft State（软状态）

• 系统中的数据可以有一段时间内的不一致，即允许存在中间状态。
• 数据的状态可以在一段时间内发生变化，直到最终达到一致。

Eventually Consistent（最终一致性）

• 系统经过一段时间后，数据会最终达到一致状态。
• 这段时间的长短取决于系统的实现和网络状况等因素。
• 在某些场景下，用户可能看到的数据不是最新的，但最终会更新到最新状态。

BASE理论为分布式系统的设计提供了灵活性，特别是在大规模、高并发的互联网应用中。通过接受一定程度的不一致性和延迟，系统可以在面对故障时仍然保持良好的性能和用户体验。

四、Paxos算法

Paxos算法是Leslie Lamport于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法，是分布式一致性的经典算法。

Paxos算法包含三个主要角色：

• Proposer(提议者)：提出提案（值）。
• Acceptor(接受者)：对提议投票，决定接受或拒绝提案。
• Learner(学习者)：不参与投票，学习已确定的提案。

提案ID：全局唯一且单调递增的，提议者的提案ID不仅需要保证唯一性，还需要确保在整个系统中是单调递增的。通常通过结合提议者的唯一标识和一个递增计数器来实现。

4.1、算法流程

Paxos分为两个阶段：准备阶段和接受阶段。

1. 准备阶段（Prepare Phase）

•   提议者选择一个全局唯一的提案编号n，向所有接受者发送一个带有编号n的提案预请求。
•   接受者收到请求后，若n大于其已响应的任何编号，则承诺不再接受小于n的提案，并返回其已接受的最高编号提案。

2. 接受阶段（Accept Phase）

• 提议者收到多数接受者的响应后，若发现有已接受的提案，则选择其中编号最大的提案值v；否则，使用自己的值v。
• 提议者向所有接受者发送Accept(n, v)接受请求。
• 接受者收到请求后，若n不小于其承诺的最小编号，则接受该提案并返回确认。
• 提议者收到多数接受者的确认后，提案v被确定，学习者学习该值。

用一个例子来理解这个流程：

设定A和B为提议者，提案ID分别为1和2。
设定C、D、E为接受者，负责审核提案并决定是否接受。

第一阶段：提案预请求（Prepare Request）
    A和B同时向所有接受者（C、D、E）发出提案预请求：
        A说：“大家好！我是A，我的提案ID是1，请回复我你们是否愿意接受我的提案！”
        B说：“大家好！我是B，我的提案ID是2，请回复我你们是否愿意接受我的提案！”
    接受者们的反应：
        C和D先收到了A的预请求：
            C和D检查自己的记录，发现目前没有接受过任何提案，于是回复A：“A，你的提案ID是1，我们目前没有接受过更高的提案，你可以继续！”
        E先收到了B的预请求：
            E检查自己的记录，发现目前没有接受过任何提案，于是回复B：“B，你的提案ID是2，我们目前没有接受过更高的提案，你可以继续！”
    C和D随后收到了B的预请求：
        C和D发现B的提案ID（2）比A的提案ID（1）更高，于是回复B：“B，你的提案ID是2，我们目前没有接受过更高的提案，你可以继续！”
    E随后收到了A的预请求：
        E发现A的提案ID（1）比B的提案ID（2）更低，于是拒绝A：“A，你的提案ID太低了，我已经见过更高的提案ID（2），我不能接受你的提案！”
        
第二阶段：正式提案（Propose Request）
    A收到了C和D的回复，但没有收到E的回复（因为被拒绝了）。A决定向C和D发出正式提案：
        A对C和D说：“这是我的正式提案，内容是X，请接受吧！”
        C和D接受了A的提案，并记录下来。
    B收到了C、D和E的回复，决定向所有接受者发出正式提案：
        B对C、D和E说：“这是我的正式提案，内容是Y，请接受吧！”
        C和D发现B的提案ID（2）比A的提案ID（1）更高，于是接受了B的提案，并更新自己的记录。
        E也接受了B的提案。
        
最终结果：
    B的提案（ID为2，内容为Y）被大多数接受者（C、D、E）接受，因此B的提案被选定（Chosen）。
    A的提案（ID为1，内容为X）虽然被C和D短暂接受，但由于B的提案ID更高，最终被覆盖。
 

Paxos算法通过两阶段提交和多数派原则，解决了分布式系统中的一致性问题，具备高容错性和可靠性。适用于需要高一致性的分布式系统，如分布式数据库、分布式存储系统等。