浅谈分布式系统与一致性协议（一）

系列文章目录

浅谈分布式系统与一致性协议（一）
浅谈分布式系统与一致性协议（二）
浅谈分布式系统与一致性协议（三）
深入浅出之etcd
深入浅出之etcd(二)
etcd版本之v3
etcd之安全性阐述
etcd的多版本并发控制

---

分布式文件系统

现如今，计算能力的提升很多时候都源自系统采用了分布式架构，简单来说分布式文件系统就是一组计算机节点和软件共同对外提供服务的系统。在分布式系统中各个节点之间的协作是通过网络进行的，仅通过消息传递进行通信和协调。
分布式系统的设计目标通常包括几个方面：

• 可用性：可用性是分布式系统的核心需求，衡量了一个分布式系统持续对外提供服务的能力。
• 可扩展性：增加及其后不会改变或者极少改变系统行为，并且获得相似的线性的性能提升
• 容错性：系统发生错误时，具有对错误进行规避以及从错误中恢复的能力 性能：对外服务的响应延时和吞吐率要满足用户的需求

使用分布式系统遇到的挑战也比较多，具体表现为

• 节点之间的网络通信是不可靠的
• 节点自身宕机
• 同步调用使系统变得不具备可扩展性

CAP原理

• C：Consistency(一致性)。即所有节点上的数据时刻保持同步。一致性严谨的表述就是原子的读写，数据的写操作对后面的读操作是可见的。
• A：Avaliability(可用性)。任何非故障的节点必须在有限的时间内给出响应，不论请求是否成功。
• P：Tolerance to the partition of network（分区容错性）当节点故障，无法进行正常通信，在丢失消息的情况下，系统能正常工作

首先CAP原理是不可能三者同时被满足的，最多只能同时满足两个。因为是分布式系统，我们首要实现分区容错性，即原理P，下面给出只能实现AP和CP的简要说明

AP满足但不满足C：要求系统高可用性和具备分区容错的能力，只能放弃一致性。当发生网络分区时，节点之间不能通信，为了满足高可用性，在有限事件给出响应，节点只能使用本地的数据提供服务，这样就导致了数据的不一致。

CP满足但不满足A：满足CP的分布式系统要求数据强一致的，当出现网络分区时会导致同步的时间延长，在此期间，节点对请求可能不会响应，这样不满足系统的高可用性

CAP原理指出分布式系统不能同时满足这三种属性，了解CAP帮助我们更好地理解实际的分布式协议的实现过程对CAP的取舍。

一致性模型详谈

我们知道分布式系统会构建集群来保证分区容错性，那么如何保证集群中的数据的一致性？

一致性与结果的正确性无关，是系统对外呈现的状态是否一致。若所有的节点达成一个错误的共识也是一致性的一种表现

对于一致性模型，可以从客户端和服务端两个视角进行分析。客户端角度，一致性主要指并发访问时如何获取更新过的数据的问题。服务端角度，如何将更新复制到整个系统，保证数据的最终一致性。因此一致性模型可以分两个角度查看：

• 以数据为中心的一致性模型
• 以用户为中心的一致性模型

以数据为中心的一致性模型

• 严格一致性（Strong Consistency）：即强一致性，时要求最高的一致性模型。任何一个写操作在任意时刻对所有进程都是可见的，同时还要维护一个绝对全局时间顺序。一旦存储器中的值发生改变，那么不管读写之间的时间间隔多么小，之后的进程读出的都是最新值。强一致性很难高效的实现，通常会采用顺序一致性模型
• 顺序一致性（Sequential Consistency）：全局时钟导致很难实现严格的一致性，而顺序一致性采用分布式时钟实现。顺序一致性指所有的进程都以相同的顺序看到了修改。读操作未必能及时得到其他进程对同一数据的写操作，但是每个进程读到该数据不同值的顺序一致。即只要求系统中所有进程达成自己的一致性即可，所谓“错一起错，对一起对”
• 因果一致性（Causal Consistency）：仅要求有因果关系的操作顺序性得到保证，非因果关系的操作顺序性没有要求。即具有因果关系的写操作，每个进程看到的顺序应该是一致的，不存在因果关系的并发写操作在不同主机之间被看到的顺序可以不一致。熟知的例子是微信朋友圈评论，知乎这种问答应用场景中的数据一致性的设计采用因果一致性，保证回答在问题之后

以用户为中心的一致性模型

最终一致性（Eventual Consistency）：最终一致性即更新的间隔时间比较长，所有的副本都能达到最终一致性。最终一致性情况下，系统能保证用户最终读取到最后更新过的数据。DNS系统在最终一致性方面做的很出色，一个更新的域名 IP，会根据配置策略和缓存控制策略，最终所有的用户都会看到最新的值

复制状态机
复制状态机主要用来管理存在于多个副本中的数据，它的基本思想是一个分布式的复制状态机系统由多个复制单元组成，每个复制单元均是状态机，它的状态保存在一组变量中。状态机的状态只能够通过外部命令来实现。

状态变量通常是基于日志操作实现的，每个复制单元存储着一个包含一系列指令的日志，并且严格按照顺序执行日志上的指令。因为每个外部命令都将产生相同的日志，每个日志都是按照相同得顺序包含相同的指令，所以每一个服务器都会执行相同的指令序列，并且最终达到一致性的状态。所以在复制状态机模型下，一致性算法的主要工作就是办证日志一致性

复制状态机的运行过程如下图：
服务器上的一致性模块负责接受外部命令，然后追加到自己的操作日志上。它与其他服务器上的一致性模块进行通信保证每一个服务器上的日志最终以相同的顺序包含相同的指令。一旦指令被正确复制，那么每一个服务器的状态机都按照操作日志处理他们，将结果返回给客户端。

复制状态机的工作是基于以下假设的：如果每个具有相同的初始状态，并且每个接收到的命令也相同，处理这些命令的顺序也相同，那么他们处理完命令之后的状态也相同。因为所有的复制节点具备相同的状态，他们独立的从日志中读取信息作为输入命令，所以即使某个节点发生故障，不会影响整个集群的可用性。

注意，指令在状态机上的执行顺序并不等于指令的发出顺序或者接收顺序。复制状态机只是保证所有的状态机都会以相同的顺序执行这些指令

拜占庭将军问题

拜占庭将军问题是对现实世界的模型化。由于硬件错误，网络拥塞，链接断开，遭到恶意攻击等原因，计算机和网络出现不可预料的行为。

拜占庭错误在计算机在计算机领域特指分布式系统中的恶意节点扰乱系统正常运行，包括选择性不传递消息，选择性伪造消息。拜占庭错误是一个悲观错误模型，若系统出现多个拜占庭错误时，系统依然可以给出一致性的决定，那么这个系统就能处理处理其他类型的错误。

进程失败错误是一个乐观的错误模型。这个模型假设某个节点出错时，这个节点会停止运行，其他节点会知道这个几点出错。若系统出现多个进程错误时都无法保证一致性决定，那么这个协议就无法处理多个其他类型的错误

FLP不可能性

FLP定理简单概括为在异步通信场景下，当只有一个节点故障时，其他节点也不能达成一致。首先，这里的节点故障时没被其他节点发现的，其他节点认为该节点只是消息延迟或者还没处理。下面举个小栗子

甲，乙，丙三人分开进行投票（投票结果为0或者1），可能会有人睡着。当甲投票0，乙投票1，这是丙的投票结果很重要，若丙睡着了（模拟节点故障），在他醒来之前，甲和乙都无法达成最终的结果，即使重新投票也会陷入循环。

FLP定理说明了在允许节点失效的情况下，异步通信的分布式协议无法保证有限时间的一致性。所以一个正确的一致性算法在异步通信的情况下无法同时保证一致性和可终止性。这个前提时异步通信，“异步通信”与“同步通信”的区别是没有时钟，不同时间同步，不能时间超时，不能探测失败，消息可乱序，消息可任意延迟。所以根据FLP定理，Paxos，Raft协议在工程上的实现是有取舍的

总结

除了错误模型，不同的系统条件也会影响一致性。例如，同步/异步通信。由于FLP定理决定了异步通信+响应时间无上限，不存在解决一个节点膨蝰的一致性协议，因此解决拜占庭将军问题的一致性算法，例如Paxos,Raft都会用到同步假设