🌏【架构师指南】分布式技术知识点总结（上）

分布式架构介绍

什么是分布式系统？

分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

分布式与集群的区别

• 集 群 : 多个服务器做同一个事情。

• 分布式 : 多个服务器做不同的事情。

分布式系统特性

分布性

空间随机分布。这些计算机可以分布在不同的机房，不同的城市，甚至不同的国家。

对等性

分布式系统中的计算机没有主/从之分，组成分布式系统的所有节点都是对等的。

并发性

同一个分布式系统的多个节点，可能会并发地操作一些共享的资源，诸如数据库或分布式存储。

缺乏全局时钟

既然各个计算机之间是依赖于交换信息来进行相互通信，很难定义两件事件的先后顺序，缺乏全局始终控制序列。

故障总会发生

组成分布式的计算机，都有可能在某一时刻突然间崩掉。分的计算机越多，可能崩掉一个的几率就越大。如果再考虑到设计程序时的异常故障，也会加大故障的概率。

处理单点故障

单点 SPoF（Single Point of Failure）：某个角色或者功能只有某一台计算机在支撑，在这台计算机上出现的故障是单点故障。

分布式系统面临的问题

• 通信异常

• 网络分区

• 节点故障

• 三态：(成功、失败、超时)

• 重发

• 幂等：一次和多次请求某一个资源对于资源本身应该具有同样的结果

分布式理论

数据一致性

分布式数据一致性，指的是数据在多份副本中存储时，各副本中的数据是一致的。

一致性分类

强一致性：写入了什么，读出来也是什么

弱一致性：不承诺立即读取到写入值

最终一致性：弱一致性的一种

不一致时间窗口

系统无法保证强一致性的时间片段，最终一致性变种：

• 因果一致性：（AB 为因果关系）

• 读己之所写一致性

• 会话一致性

• 单调读一致性

• 单调写一致性

CAP 定理

一致性（Consistency）

所有节点访问时都是同一份最新的数据副本

可用性（Availability）

每次请求都能获取到非错的响应，但是不保证获取的数据为最新数据

分区容错性（Partition tolerance）

分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障

由于 CAP 不可能同时满足，而分区容错性对于分布式系统而言是必须的，即一般采用 CP 或 AP

BASE 定理

• Basically Available(基本可用)

• Soft state（软状态）

• Eventually consistent（最终一致性）

分布式一致性协议

2PC（2 Prepare Commit）

优点：

原理简单

缺点：

同步阻塞

在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，即当参与者占有公共资源时，其他节点访问公共资源会处于阻塞状态。

单点问题

若协调器出现问题，那么整个二阶段提交流程将无法运转，若协调者是在阶段二中出现问题时，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作。

数据不一致

在阶段二中，执行事务提交的时候，当协调者向所有的参与者发送 Commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完 Commit 请求之前自身发生了崩溃，导致最终只有部分参与者收到了 Commit 请求，于是会出现数据不一致的现象。

太过保守

在进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，此时协调者只能依靠自身的超时机制来判断是否需要中断事务，这样的策略过于保守，即没有完善的容错机制，任意一个结点的失败都会导致整个事务的失败。

3PC（三阶段提交协议）

1. 首先对于协调者和参与者都设置了超时机制（在 2PC 中，只有协调者拥有超时机制，即如果在一定时间内没有收到参与者的消息则默认失败）,主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地 commit 从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。

2. 通过 CanCommit、PreCommit、DoCommit 三个阶段的设计，相较于 2PC 而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的 。

3. PreCommit 是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。

注意：一旦进入阶段三，可能会出现 2 种故障：协调者出现问题协调者和参与者之间的网络故障如果出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交

• 可以看出 3PC 比 2PC 多一个预先判断 commit 操作动作，减少故障发生概率（CanCommit）。-> PreCommit -> DoCommit

• 并且还多了一个超时机制在参与者和协调者。

问题：3PC 协议并没有完全解决数据一致问题。

NWR 协议

NWR 是一种在分布式存储系统中用于控制一致性级别的一种策略。在亚马逊的云存储系统（Dynamo）中，就应用 NWR 来控制一致性。

• N：在分布式存储系统中，有多少份备份数据

• W：代表一次成功的更新操作要求至少有 w 份数据写入成功

• R： 代表一次成功的读数据操作要求至少有 R 份数据成功读取

如何判断数据的新旧？

这需要向量时钟来配合，所以对于 Dynamo 来说，是通过 NWR 协议结合向量时钟来共同完成一致性保证的。

Gossip 协议（AP 协议算法）

Gossip 是一种去中心化的分布式协议，数据通过节点像病毒一样逐个传播。

因为是指数级传播，整体传播速度非常快。

优点

1. 扩展性：允许节点的任意增加和减少，新增节点的状态最终会与其他节点一致容错：任意节点的宕机和重启都不会影响 Gossip 消息的传播，具有天然的分布式系统容错特性

2. 去中心化：无需中心节点，所有节点都是对等的，任意节点无需知道整个网络状况，只要网络连通，任意节点可把消息散播到全网

3. 最终一致性：Gossip 协议实现信息指数级的快速传播，因此在有新信息需要传播时，消息可以快速地发送到全局节点，在有限的时间内能够做到所有节点都拥有最新的数据。

缺点

1. 消息延迟:节点随机向少数几个节点发送消息，消息最终是通过多个轮次的散播而到达全网；不可避免的造成消息延迟。

2. 消息冗余:节点定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤；不可避免的引起同一节点消息多次接收，增加消息处理压力

适合于 AP 场景的数据一致性处理

Paxos 算法(CP 协议算法)

Paxos 问世以来就持续垄断了分布式一致性算法，Paxos 这个名词几乎等同于分布式一致性。Google Chubby 的作者 Mike Burrows 说过这个世界上只有一种一致性算法，那就是 Paxos。

Paxos 算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性。

Basic Paxos

角色介绍

• Client：客户端

客户端向分布式系统发出请求，并等待响应。例如，对分布式文件服务器中文件的写请求。

• Proposer：提案发起者

提案者提倡客户端请求，试图说服 Acceptor 对此达成一致，并在发生冲突时充当协调者以推动协议向前发展

• Acceptor: 决策者，可以批准提案

Acceptor 可以接受（accept）提案；并进行投票, 投票结果是否通过以多数派为准, 以如果某个提案被选定，那么该提案里的 value 就被选定了

• Learner: 最终决策的学习者

Basic paxos 流程一共分为 4 个步骤:

• prepare ：Proposer 提出一个提案,编号为 N, 此 N 大于这个 Proposer 之前提出所有提出的编号, 请求 Acceptor 的多数人接受这个提案

• Promise：如果编号 N 大于此 Acceptor 之前接收的任提案编号则接收, 否则拒绝

• Accept：如果达到多数, Proposer 会发出 accept 请求, 此请求包含提案编号和对应的内容

• Accepted 如果此 Acceptor 在此期间没有接受到任何大于 N 的提案,则接收此提案内容, 否则忽略

Multi-Paxos

针对 basic Paxos 是存在一定得问题，首先就是流程复杂，实现及其困难，其次效率低（达成一致性需要 2 轮 RPC 调用）针对 basic Paxos 流程进行拆分为选举和复制的过程。

Multi-Paxos 在实施的时候会将 Proposer，Acceptor 和 Learner 的角色合并统称为“服务器”。因此，最后只有“客户端”和“服务器”。

Raft 协议

Paxos 算法的工程实现，引入主节点，通过竞选确定主节点。

节点状态

• Leader（主节点）：接受 client 更新请求，写入本地后，然后同步到其他副本

• Follower（从节点）：从 Leader 中接受更新请求，然后写入本地日志文件。对客户端提供读请求

• Candidate（候选节点）：如果 follower 在一段时间内未收到 leader 心跳。则判断 leader 可能故障，发起选主提议。节点状态从 Follower 变为 Candidate 状态，直到选主结束

竞选阶段动态流程示意

Raft 完整版的动画演示：Raft

github 提供的一个动画演示：Raft Consensus Algorithm

Lease 机制

解决双主节点的问题，主要解决思路有四种：

• 设计能容忍双主的分布式协议

• Raft 协议-通过 Term 版本高的同步低的

• 用 lease 机制

• 涉及去中心化-Gossip 协议

Lease 原理

引入中心节点负责下发 Lease

lease 时间长短一般取经验值 1-10 秒即可。太短网络压力大，太长则收回承诺时间过长影响可用性。

Lease 的容错

1. 主节点宕机 lease 机制天生即可容忍网络、lease 接收方的出错,时间即 Lease 剩余过期时长

2. 中心节点异常颁发者宕机可能使得全部节点没有 lease，系统处于不可用状态，解决的方法就是使用一个小集群而不是单一节点作为颁发者。

3. 时差问题中心节点与主节点之间的时钟可能也存在误差，只需要中心节点考虑时钟误差即可。