随着计算机科学和互联网的发展，分布式场景变得越来越常见，能否处理好分布式场景下的问题，成为衡量一个工程师是否合格的标准。本文我们介绍下分布式系统相关的理论知识，这些理论是我们理解和处理分布式问题的基础。

CAP理论

CAP理论是在1998年由计算机科学家Eric Brewer提出的。介绍下CAP理论。

• Consintency：一致性，即访问所有节点得到的结果是一致的，这里的一致性指强一致。
• Availability：可用性，即所有节点保持高可用，这里的高可用还包括不能出现过高的延迟。
• Partition tolerance：分区容错性，节点之前网络不可用时，系统仍然可以对外提供服务。 CAP理论的原理是：一个系统最多可以同时满足以上三个条件中的两个，不可能三个同时满足。
  之前看到过一个更容易理解的解释方法：
• C代表一致
• A代表同一时间
• P代表不同空间 CP：不同空间，如果数据一致必然不会在同一时间
  AP：不同空间，如果在同一时刻可以从任意空间取数据必然会导致数据状态不一致
  CA：任意时刻获取数据都保证一致，必然P只能是1

结合现实中的业务场景，P（分区容错性）是每一个系统必须满足的要求，我们实际的选择就只有CP和AP两种模型了。 CP模型的特点是，一致性要求高，像我们熟悉的Zookeeper就是典型的CP模型。 AP模型的特点是，保证高可用，数据保持最终一致性，不追求实时的一致性。比较典型的有Eurka

Base理论

Base的全称：Basically Available（基本可用）、Soft state（软状态）和Eventual consistency（最终一致性）。

• Basically Available：指核心服务/部分服务可用，或响应延时变长。
• Soft state：指数据同步完部分节点还没有全部同步完成的状态。
• Eventual consistency：经过系统内部协调，经过有限时间，系统内各节点最终达成一致状态。 Eventual consistency在实践中往往还需要注意几点：
• 会话一致性，在单次会话中如果数据已经更新，不能再读到旧数据
• 节点有效性，一个节点上的数据如果已经更新，不能再读到旧数据 Base理论更适合大型分布式系统的整体设计，不同于ACID的强一致模型。它允许通过牺牲强一致来增强系统的可用性，允许经过一定时间数据达到最终一致。在实际业务场景中可以把Base和ACID结合使用。

2PC

引用维基百科的定义：“二阶段提交（英语：Two-phase Commit）是指在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。通常，二阶段提交也被称为是一种协议（Protocol）”
二阶段提交，存在协调者和执行者两种角色。

第一阶段：提交请求阶段

1. 协调者向所有执行者发送请求，询问任务是否可执行。
2. 执行者执行事务的操作，并记录“日志”，但是不进行commit。
3. 执行者执行完事务之后，返回给协调者执行状态。如果事务执行成功，返回准备完毕状态；如果事务执行失败，返回终止状态。

如果有一个或多个执行者返回终止，发起回滚流程：

1. 协调者向所有执行者发起回滚请求。
2. 执行者收到回滚请求，根据第一阶段第二步记录的日志，执行回滚操作。
3. 执行者回滚完成后，给协调者返回回滚完成。
4. 协调者收到所有执行者返回回滚完成，事务回滚成功。

如果协调者接收到所有执行者返回准备完毕,执行第二阶段。
第二阶段：提交执行阶段

1. 协调者向所有执行者发起“正式提交”的请求。
2. 执行者执行commit操作，并释放相关锁资源。
3. 执行者向协调者发送commit成功消息。
4. 协调者接收到所有执行者的commit成功消息后，完成事务。 协调者在第二阶段，必须完成任务。

二阶段提交的优缺点：

• 优点：原理简单，实现简单。
• 缺点：协调者存在单点问题；所有执行者互相等待，导致阻塞；第一阶段执行者出现故障，协调者就无法判断执行者是否成功执行，只能依赖自身的超时机制来保障回滚；第二阶段，如果执行者发生故障，无法完成commit操作，会导致数据不一致。

3PC

三阶段提交：三阶段提交就是把二阶段提交的第一阶段拆分成了两个阶段，带来的好处是，提前预知风险，减少执行者互相阻塞。

第一阶段：CanCommmit

1. 协调者向所有执行者发送CanCommit的请求。
2. 执行者根据自身状况预判是否可以执行Commit，返回“Can”或者“No”。如果有执行者返回“No”或者有执行者请求超时，协调者向所有执行者发送回滚操作，执行者接收到回滚操作（此时的回滚，是比较轻量的）ACK。 如果所有执行者都返回“Can”，则进入下一阶段。

第二阶段：PreCommit

1. 协调者向所有执行者发送PreCommit请求。
2. 执行者执行事务，并记录“日志”，但是不做commit，事务执行完返回“Pre”或者“No”。 如果有执行者返回“No”或者有执行者请求超时，协调者向所有执行者发送回滚操作，执行者接收到回滚操作，执行完回滚，ACK。 如果所有执行者都返回“Can”进入下一阶段。

第三阶段：DoCommit

1. 协调者向所有执行者发送DoCommit请求。
2. 执行者执行Commit事务，并释放锁，事务执行完返回“完成”或者“失败”
3. 如果所有执行者都返回“完成”，协调者完成事务。如果有的执行者返回“失败”或者超时，协调者向所有执行者发送“回滚”操作，执行者执行“回滚”，回滚完毕ACK。 优点：三阶段提交缓解了二阶段提交执行者的阻塞问题。但是并没有从根本上解决协调者的单点、网络延迟等问题。

Paxos算法：

“Paxos算法是莱斯利·兰伯特（英语：Leslie Lamport）于1990年提出的一种基于消息传递且具有高度容错特性的共识（consensus）算法”。 Paxos算法有两部分：Basic Paxos和Multi-Paxos。 Basic Paxos是解决多节点如何就某一个值达成共识；Multi-Paxos是多组Basic Paxos如何把一些列值达成共识。Multi-Paxos没有严格的证明过程，更多的是作为解决分布式问题的指导思想。我们这里主要介绍下Basic Paxos算法。 Basic Paxos中有三种角色： Proposer（提议者）、Acceptor（接受者）、Learner（学习者）。

• Proposer：提出“提议”
• Acceptor：对“提议”进行投票
• Learner：记录被批准的“提议” 在算法具体实现时，通常Proposer是第一个接收到客户端请求的节点，节点既是Proposer又是Acceptor。这样可以把算法逻辑尽量集中在服务内部，与客户端解耦。 证明过程可参照维基百科：传送门

最终算法：

通过一个决议分为两个阶段：

阶段一：Prepare阶段

1. Proposer选择一个提案编号M，向超过半数的Acceptor发送编号为M的Prepare请求。
2. 如果一个Acceptor收到编号为M的Prepare请求，并且M大于Acceptor已经响应过的所有提案编号。Acceptor给Proposer返回自己已经批准过的最大编号的提案，同时自己承诺不再批准编号小于M的提案。

阶段二：Accept阶段

1. 如果超过半数的Acceptor给Proposer返回了Prepare响应，Proposer就会发送一个编号为M、值为N的Accept请求给Acceptor
2. 如果Prepare接收到此请求，并且未对编号大于M的Prepare请求响应，Acceptor就通过这个提案。

我们举一个实际的例子：

P1 P2代表两个Proposer A1 A2 A3代表三个Acceptor

阶段一：Prepare阶段

P1向A1、A2、A3发送编号为1的提案；P2向A1、A2、A3发送编号为2的提案。

1. A1、A2收到编号为1的提案，因为之前没有接收过提案，所以A1和A2给P1返回响应，并郑重承诺“不再响应编号小于等于1的Prepare请求；不会通过编号小于1的提案”
2. A1、A2收到P2发来的编号为2的提案，因为2>1,所以A1和A2给P2返回响应，并郑重承诺“不再响应编号小于等于2的Prepare请求；不会通过编号小于2的提案”
3. A3收到P2发来的编号为2的提案，因为A3之前没有收到过提案，所以给P2返回响应，并郑重承诺“不再响应编号小于等于2的Prepare请求；不会通过编号小于2的提案”
4. A3收到P1发来的编号为1的提案，因为上一步A3作出的承诺而且提案编号1<2，所以A3对次请求不做响应。

阶段二：Accept阶段

因为P1和P2在Prepare阶段都收到了超过半数Acceptor的响应，所以二者都会发起Accept请求。
P1发起编号为1，值为1的请求；P2发起编号为2，值为2的请求。

• A1、A2、A3收到P1的Accept请求，应为编号1<2,所以编号为1的提案被拒绝。
• A1、A2、A3收到P2的Accept请求，应为编号2=2,所以编号为2的都返回响应，通过。

提案获取： Acceptor把批准的提案，发送给Learner的一个leader组，该小组负责把提案信息扩散到所有Learner节点。
Paxos的业界典型实现：Chubby

Raft算法

Raft算法在近几年几乎成了共识性算法的首选。像Etcd、Consul、Tidb都使用了Raft算法。 Raft算法中的节点，存在三种状态Follower（跟随者）和Candidate（候选人）、 Leader（领导者） 3 种状态。

集群诞生：
集群刚刚启动的时候，所有的节点都是Follower，Follower没有收到来自Leader的心跳检测，他会自己提升自己为Candidate，Candidate向别的节点请求选票，如果Candidate接收到大于半数节点的选票，Candidate就会变为Leader。

第一次集群状态一致：
系统的所有改变都要通过Leader节点进行，每一次变更操作都被记录到日志中。
客户端的请求需要先发送到Leader节点
Leader节点第一次把日志发送给Follower节点
Leader节点等待超过半数的节点，已经成功记录了日志（并未提交）
Leader节点commit当前值
Leader通知Follower节点值已经被commit，Follower节点也提交日志。
现在集群达到了第一次启动后的一致状态。

选主：

在Raft算法中有两个超时设置，来控制选主。

1. 主节点判定超时：Follower在一段时间之后如果没有收到Leader节点的存活检测，就会把自己提升为Candidate。我们假设Follower把这个超时时间设置为150-300ms之间的随机值（150-300ms只是一个示例）。
2. 主节点被判定超时后，Follower把自己提升为Candidate开始新的一轮选举。
3. Candidate先投票给自己
4. Candidate发送投票请求到其他节点
5. 接收到Candidate请求的节点，如果在这一轮选举中还没有进行过投票，就给当前发来请求的Candidate节点投票。
6. Candidate节点会在一定范围内随机设置选举的超时时间
7. 一旦Candidate接收到超过半数的支持者，就会把自己提升为Leader。
8. Leader发送“Append Entries messages”给他的Follower。而且信息会以心跳检测的形式，周期性的发送，Follower收到“Append Entries messages”给Leader返回响应。心跳检测会一直存在，直到Follower等待心跳检测超时，把自己提升为Candidate。
9. Candidate要获得超过半数Follower的选票保证一次选举中只能有一位Leader，如果没有的话选举失败。这时，Candidate会随机等待一段时间重新发起下一轮投票，直到选出一位Leader。

日志复制：

一旦我们集群中有了Leader，就需要复制所有的变更到集群中的所有节点，通过发送“Append Entries message”消息来完成日志复制。

1. 客户端发送信息给Leader，Leader节点把请求信息记录日志。
2. 在下一次心跳检测时，把日志发送给Follower。
3. Follower接收到请求给Leader返回响应，一旦超过半数的节点返回响应，Leader节点就commit日志信息。
4. 给客户端返回响应,同时通知Follower节点commit日志。

节点变更：

在多个节点同时做成员变更期间，如果刚好发生网络分区，容易出现一个集群中多个Leader的现象，这时如果客户端还往集群发送请求，就会出现脑裂。 我们通常使用单节点变更的方式来解决Raft集群的成员变更，即每次只增删一个节点。 单节点成员的变更分为两步：

1. Leader向新节点同步数据。
2. Leader将新配置作为日志项发送到集群中的所有节点上。

Raft算法中还有一些规则需要注意：

1. 任期编号在整个集群中单调递增，一个Candidate或者Leader如果发现了比自己任期编号大的Leader节点，会自动变为Follower。
2. 如果一个节点收到小于当前任期编号的请求会直接拒绝。
3. 只要Leader节点在随机时间内一直发送心跳检测请求，Leader节点就一直是Leader。
4. 日志完整性高（最后记录的日志，任期编号大或者任期编号相同索引项大）的节点拒绝投票给日志完整性比自己低的Candidate。
5. 在一次选举过程中，一个节点只能有一次投票，最先接受到的请求，最先获得选票。

XA事务

要想理解XA事务，首先需要知道DTP 模型（ Distributed Transaction Processing），DTP模型有三个模块：

• AP：应用程序（Aplication Program），指事务的发起者通常是我们的应用程序。
• RM：资源管理器（Resource Manager），管理具体资源，而且还要具备事务提交或回滚的能力。通常是存储或者一些公共服务，比如数据库。
• TM：事务管理器（Transaction Manager），TM 是分布式事务的协调者。TM 可以和所有的RM通信。

XA规范主要规定了RM和TM之间的交互流程，依赖二阶段提交的思路。 XA规定了一些列的接口，如下图：

其中最主要的接口有：

• xa_open: 初始化RM
• xa_start: 启动XA事务
• xa_end: 结束XA事务
• xa_prepare: 准备阶段，XA事务预提交
• xa_commit：提交XA事务
• xa_rollback: 回滚XA事务 XA事务的执行流程我们也以图例的形式展示：

具体步骤：

1. AP发起事务开始请求
2. RM给TM发起请求，并调用xa_start方法标记事务开始
3. AP访问TM执行具体操作，比如数据库的具体操作语句
4. TM执行xa_end方法，标记事务结束
5. TM发起xa_prepare，通知RM进行请求提交前的准备工作，类比二阶段提交的请求提交阶段
6. TM发起xa_commit，通知RM进行提交执行，类比二阶段提交的提交执行阶段。当然如果上一阶段准备失败的话，此阶段执行xa_rollback通知RM回滚事务
7. TM调用x_close结束事务 因为像MySQL、Oracle等数据库都实现了XA事务，因此我们在做一些跨库操作的时候，不管是不是同一种数据库，只要实现了XA协议，我们都可以调用对方的API完成分布式事务。

TCC

TCC是典型的柔性分布式事务的理论，通过补偿机制，保证数据的最终一致性。TCC的三个阶段：

1. Try阶段：预执行操作，对业务系统做检测及资源预留。
2. Confirm阶段：确认执行具体操作。
3. Cancel阶段：取消执行业务操作。 TCC理解起来比较简单，但是再具体实现时，需要着重考虑一下几个问题：请求接口的幂等设计，try过程中加锁资源的设计等等。

Quorum NWR：

NWR 模型的思想是把 CAP 的选择权交给了用户，让用户通过配置可以灵活调节CAP模型中C和A的选择比重。

• N：代表总的副本数
• W：代表写入成功W份（W个副本），才认为写入成功。
• R：代表至少读取R个备份，才认为读成功。（如果出现数据不一致，往往是挑选最新的数据）

如果 W + R > N，所以 R > N – W，也就是说，每次读取，都至少读取到一个最新的版本。
当需要高可写时，可以配置 W = 1 R = N。只要写任何节点成功就认为成功，但读的时候必须从所有的节点都读出数据 —> 弱一致性，高可用性。
当需要高可读时，可以配置 W = N R = 1。必须写所有节点成功才认为成功，这时读任何一个节点成功就认为成功 —> 强一致性，低可用性