从 paxos 到 zookeeper 总结（一）分布式架构

引言

本篇说了什么？本篇主要讲分布式系统。从分布式系统的历史开始，讲到网络的加入带来的不稳定的因素，为了描述和解决这些问题产生了诸多概念和理论模型，比如副本、分布式一致性、分布式协调，CAP、2PC等，这些概念是我们这篇要说的，也是了解分布式架构的基础知识。

一、分布式系统

1.1、集中式到分布式

从20世纪60年代大型主机被发明出来以后，在很长的一段时间内，大型主机引领了计算机行业的发展，在大型主机的研究上比较知名的如IBM，大型主机时代集中式的计算机系统架构成为了主流。

所谓的集中式系统就是指由一台或多台计算机组成中心节点，数据集中存储于这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均能由其集中处理。

• 优点

也就是说，在集中式系统中，每个终端或客户端机器仅仅负责数据的录入和输出，而且数据的存储和控制处理完全交由主机来完成。集中式系统最大的特点就是部署结构简单，也无需考虑如何对服务进行多个节点的部署，也就不用考虑多个节点之间的分布式协作问题。

• 缺点

但传统集中式处理模式越来越不能适应人们的需求，它存在的问题也越来越明显，比如：

1. 大型机操作复杂，人才培养成本就非常高。
2. 大型主机非常昂贵，不是所有企业都有能力采购，扩容也比较困难。
3. 集中式的系统架构体系存在诸多单点问题，一旦一台大型主机出现了故障，那么这个系统就处于不可用状态。

另一方面，从20世纪80年代以来，计算机系统向网络化和微型化的发展日趋明显，随着PC机性能的不断提升和网络技术的快速普及，很多企业开始放弃原来的大型主机，改用小型机和普通PC服务器来搭建分布式的计算机系统，比如阿里集团从2009年开始启动的“去IOE”计划，其电商系统开始正式迈入分布式系统时代。

1.2、概念

在《分布式系统感念与设计》一书中，对分布式系统做了以下定义

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

1.3、分布式系统的特征

• 分布性

分布式系统中的多台计算机都会在空间上随意分布的，同时，机器的分布情况也会随时变动。

• 对等性

组成分布式系统的所有的计算机都是对等的。副本是分布式系统最常见的概念之一指的是分布式系统对数据和服务提供的一种冗余方式。数据副本是指在不同的节点上持久化同一份数据，当某一个节点上的存储数据丢失的时候，可以从副本读取到该数据，这个是解决分布式系统数据丢失最有效的手段。另一类就是服务副本，指多个节点提供同样的服务，每个节点都有能力接受来自外部的请求并进行相应的处理。

• 并发性

同一个分布式系统的多个节点，可能会并发的操作一些共享的资源，诸如数据库的分布式存储等，如何准确并高效的协调分布式并发操作也成为分布式系统架构与设计的最大挑战之一，我们后面讲到的ZooKeeper就是用来提供分布式协调服务的。

• 缺乏全局时钟

一个典型的分布式系统是由一系列在空间上随意分布的多个进程组成的，就很难定义两个事件谁先谁后，系统缺乏一个全局的时钟序列控制。

• 故障总是会发生

组成分布式系统的所有计算机都有可能发生任何形式的故障

1.4、分布式环境的各种问题

• 通信异常

从集中式到分布式演变的过程中，必然引入了网络因素，而且网络本身的不可靠性，因此也引入了额外的问题。分布式系统需要在各个节点进行网络通信，因此每次网络通信都会都会伴随着网络不可用的风险。另外即使分布式系统之间的网络通信是正常的，其延时也是远远大于单机操作。通常单机访问延时大概在10 ns 左右正常一次网络通信延迟在0.1~1ms 左右。差距105倍因此消息丢失和消息延迟变得非常普遍。

• 节点故障

节点故障则是分布式环境下另一个常见的问题，指的是组成分布式系统的机器的节点出现了宕机或者僵死的现象，一般来说每个节点都有可能出现故障，并在每天都有可能发生。

• 网络分区

当网络由于发生异常情况，导致分布式系统中部分节点之间的网络延迟不断增大，最终导致组成部分分布式系统的所有节点中，只有部分节点之间能够进行正常的通信，而另一些节点则不能--------我们将这个现象称为网络分区，就是俗称的脑裂。当网络分区出现时，分布式系统出现局部小集群，在极端情况下，这些局部小集群会独立完成原本要整个分布式系统才能完成的功能，包括对数据的事务处理，这就对分布式一致性提出了非常大的挑战。

• 三态

在与传统的单机系统中，应用程序在调用一个函数之后，能够得到一个非常明确的响应成功或者失败。在分布式环境下，网络可能会出现各种各样的问题，由于网络出现异常的情况下，就可能出现超时现象。因此分布式系统的每一个请求与相应，存在特有的三态概念，即成功，失败与超时。超时通常又有如下两种情况。

1. 由于网络出现原因该请求并没有成功的发送到接收方，而是在发送过程中发生了数据丢失的情况。
2. 该请求成功的被接收方接收，并进行了处理，但是在响应反馈发送方的时候发生了消息丢失的情况。

当出现这样的超时现象时，网络通信的发起方时无法确定当前请求是否被处理成功的。

二、分布式一致性和分布式事务处理

2.1、分布式一致性问题

在分布式系统中另一个需要解决的重要问题就是数据的复制。在我们日常的开发经验中，相信很多开发人员都碰到过这样的问题：假设客户端C1将系统中的一个值K由V1更新为V2，但客户端C2无法立即读取到K的最新值，需要在一段时间之后才能读取到。读者可能也已经猜到了，上面这个例子就是常见的数据库之间复制的延时问题。

分布式系统对于数据的复制需求一般都来自于以下两个原因。

• 为了增加系统的可用性，以防止单点故障引起的系统不可用。
• 提高系统的整体性能，通过负载均衡技术，能够让分布在不同地方的数据副本都能够为用户提供服务。

数据复制在可用性和性能方面给分布式系统带来的巨大好处是不言而喻的，然而数据复制所带来的一致性挑战，也是每一个系统研发人员不得不面对的。

所谓分布式一致性问题，是指分布式环境中引入数据复制机制后，不同数据节点间可能出现的，并无法依靠计算机应用程序自身解决的数据不一致情况。简单地讲，数据一致性就是指在对一个副本进行更新的同时，必须确保也能够更新其他副本，否则不同副本之间的数据将不再一致。

那怎么来解决这个问题呢？顺着上面提到的复制延时问题，很快就有人想到了一种解决办法，那就是：

“既然是由于延时引起的问题，那我可以将写入的动作阻塞，直到数据复制完成后，才完成写入动作。”

没错，这似乎能解决问题，而且有一些系统的架构也确实直接使用了这个思路。但这个思路在解决一致性问题的同时，又带来了新的问题：写入的性能。如果你的应用场景有非常多的写请求，那么使用这个思路之后，后续的写请求都将会阻塞在前一个请求的写操作上，导致系统整理性能急剧下降。

总的来讲，我们无法找到一种能够满足分布式系统所有系统属性的分布式一致性解决方案。因此，如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。于是，一致性级别由此诞生。

• 强一致性：这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响比较大。
• 弱一致性：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不具体承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。弱一致性还可以再进行细分：
  • 会话一致性：该一致性级别只保证对于写入的值，在同一个客户端会话中可以读到一致的值，但其他的会话不能保证。
  • 用户一致性：该一致性级别只保证对于写入的值，在同一个用户中可以读到一致的值，但其他用户不能保证。
• 最终一致性：最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常重要的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型。

2.2、从ACID到CAP/BASE

下面我们继续来看分布式一致性和分布式事务处理的问题

2.2.1、ACID

先介绍一下事务，ACID，事务隔离性，分布式事务的概念

• 事务

事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务特指数据库事务。一方面，当多个应用程序并发的访问数据库时，事务可以在这些应用程序之间提供一个隔离方法，以防止彼此的操作互相干扰。另一个方面，事务为数据库操作序列提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即使在异常状态下仍能保持数据一致性的方法。

• ACID

事务具有四个特征，分别是原子性(Atomicity)，一致性(Consistency)，隔离性(Isolation)，和持久性（Durability），也就是事务的ACID特性。

• 事务的隔离性

事务的隔离性是指在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他的事务干扰。也就是说，不同的事务并发操作相同的数据时，每个事务都有各自完整的数据空间，即一个事务内部的操作及使用的数据也是对其他的并发事务是隔离的，并发执行各个事务之间不能相互干扰。

在标准SQL 规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同，如未授权读取，授权读取，可重复读取和串行化。

• 分布式事务

随着分布式计算的发展，事务在分布式计算领域中也得到了广泛的应用。在单机数据库中我们很容易能够实现一套满足的ACID特性的事务处理系统，但在分布式数据库中，数据分散在各台不同的机器上，如何对这些数据进行分布式的事务处理具有非常大的挑战。在上面（参考1.4）讲解了分布式环境中会碰到的种种问题，其中包括机器宕机和各种网络异常等。尽管存在着种种分布式问题，但是在分布式计算领域，为了保证分布式程序的可靠性，分布式事务是无法回避的。

分布式事务是指事务的参与者，支持事务的服务器，资源服务器以及事务管理器分别位于分布式系统的不同节点之上。通常一个分布式事务中会涉及对多个数据数据源或业务系统的操作。

我们可以看到，一个分布式事务可以看作是由多个分布式的操作序列组成的，通常可以把这一系列分布式的操作序列称为子事务。因此分布式事务也可以被定义为一种嵌套型的事务，同时也就具有了ACID事务特性。但由于在分布式事务中，各个子事务的执行是分布式的，因此要实现一种能够保证ACID特性的分布式事务处理系统就显得格外复杂。

2.2.2、CAP理论

可用性和一致性之间永远也无法存在一个两全其美的方案，于是如何构建一个兼顾可用性和一致性的分布式系统成为了无数工程师的难题，出现了诸如CAP和BASE这样的分布式系统的经典理论。

CAP理论告诉我们，一个分布式系统不可能同时满足一致性，可用性，分区容错性这三个基本需求，最多只能同时满足其中两项。

通常用下图来表示CAP定理。
一致性（Consistency）

在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态
对于一个将数据副本（参考1.3对等性部分）分布在不同分布式节点上的系统来说，如果对第一个节点的数据进行更新操作并且更新成功后。却没有使得第二个节点上的数据得到更新。于是在读取第二个节点的数据，得到的依旧是老的数据。这个就是典型的分布式数据不一致的情况。在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有用户都能读到最新的值，那么这样的系统就被认为具有强一致性（参考2.1一致性级别）。

可用性（Availability）

可用性是指系统的服务必须一直处于可用的状态，对于用户的每一个操作请求能够在有限时间内返回结果。

分区容错性（Partition Tolerance）

分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区的故障的时候，仍然需要能够保证对外提供满足一致性可用性的服务，除非是整个网络环境都发生了故障，比如一个5台机器的ZooKeeper的集群环境，有两台机器宕机，连接ZooKeeper的外部系统应该是没有感觉依然可以调用服务的。
网络分区是指在分布式系统中，不同的节点分布在不同的子网络中，由于一些特性的原因导致这些子网络之间出现网络不连通的情况，但各个子网络的内部网络正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要注意的是，组成一个分布式系统的每个子节点的加入与退出都可以看作是一个特殊的网络分区。

一个分布式系统无法同时满足上述三个需求，在进行对CAP定理的应用时，我们就需要抛弃其中的一项，下表所示是抛弃CAP定理中任意一项特性的场景说明。

从CAP理论中可以看出一个分布式系统不能同时满足一致性，可用性，和分区性这个三个要求。对于一个分布式系统分区容错性是必须的，因此在系统架构设计师往往需要把精力花在如何根据业务特点在一致性和可用性之间寻求平衡，也就是我们常说的CP和AP模型。

2.2.3、BASE理论

BASE是Basically Available(基本可用),Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。下面我们对BASE三要素进行详细讲解。

• 基本可用

基本可用是指分布式系统在出现不可预知的故障时，允许损失一部分的可用性但不是等价于系统不可用。

响应时间损失：正常情况下一个搜素引擎需要在0.5秒内返回结果给用户但是由于出现了故障这个时间增加到了1~2秒
功能上的损失:正常情况下，在一个电子商务网站上购物时，消费者几乎能够顺利的完成每一笔订单，但是在一些节日大促购物高峰期的时候，由于消费者购物激增行为，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

• 弱状态

弱状态也成为软状态，和硬状态相比相对，是指允许系统中的数据存在中间状态，并认为该状态的中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点之间进行数据同步的过程存在延时。

• 最终一致性

最终一致性强调的是系统中所有的数据副本，在进过一段时间后最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证最终数据能够达到一致而且不需要实时保证系统数据的强一致性。
最终一致性最在下面5项变种

1. 因果一致性
   因果一致性是指，如果进程A在更新完某个数据项后通知了进程B,那么进程B之后对该数据项的访问都应该能够获取到进程A更新的最新值，并且如果进程B要对该数据进行更新操作的话，务必基于进程A更新后的最新值即不能发生更新丢失的情况。与此同时与进程A无因果关系的进程C则没有这样的限制。
2. 读己之所写
   读己之所写是指，进程A更新一个数据项之后，他自己总是能访问到更新过的最新值。因此读己之所写也是一种特殊的一致性
3. 会话一致性
   会话一致性将系统数据的访问过程框定在了一个回话当中：系统能保证在同一个有效的回话中实现读己之所写的一致性，也就是说执行更新操作后，客户端能够在同一个回话中始终读到该数据项的最新值。
4. 单调读一致性 单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后那么系统对于该进程后续的任何数据访问都不应该返回更旧的值
5. 单调写一致性 单调写一致性是指：一个系统需要保证来自同一个进程的写操作被循序的执行

总的来说BASE 理论面向的是大型高可用可扩展的分布式系统，和传统的事务ACID特性是相反的，他完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内不一致但最终达到一致性状态。但同时在分布式场景中，不同业务单元对数据的要求是不同的，因此具体的分布式系统架构设计的过程中，ACID特性与BASE理论又往往结合在一起使用。

三、一致性协议

从上面的介绍中我们提到了，对一个分布式系统进行架构设计的过程中，往往会在系统的可用性和数据一致性之间进行反复的权衡，于是就产生了一系列的一致性协议，比如二阶段提交，三阶段提交，和Paxos算法。

3.1、2PC

2PC 即二阶段提交，是计算机网络尤其是在数据库领域内为了使基于分布式系统架构下的所有节点在事务处理过程中能够保证原子性和一致性而设计的一种算法。通常二阶段提交协议也被认为是一种一致性协议，用来保证分布式系统数据的一致性.目前，绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的。利用该协议能够非常方便的完成所有分布式事务参与者的协调，统一决定事务的提交和回滚。从而能够有效的保证分布式数据的一致性，因此二阶段提交协议被广泛的应用在许多分布式系统中。
协议说明
顾名思义二阶段提交协议，是将事务的提交过程分成了两个阶段来进行处理，如下图所示

其执行流程如下。
阶段一：提交事务请求

1. 事务询问。 协调者向所有的参与者发送事务内容，询问是否可以执行事务操作，并开始等待各参与者的响应。
2. 执行事务 各参与者节点执行事务操作，并将undo和redo信息记录到事务日志中.
3. 各参与者向协调者发送反馈事务询问的响应。 如果参与者成功执行了事务操作，那么就反馈给协调者yes的相应，表示事务可以执行；如果参与者没有成功执行事务，那么就反馈给协调者no相应，表示事务不可以执行。
   由于上面讲述的内容在形式上近似是协调者组织各参与者对一次事务操作的投票表态过程，因此二阶段提交协议的阶段一也被称为投票阶段，即各个参与者投票表明是否要继续执行接下去的事务提交操作。

阶段二：执行事务的提交
在阶段二总协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，正常情况下，包含一下两种可能。

• 执行事务提交

假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务提交。

1. 发送提交请求。
   协调者向所有参与者节点发出commit请求
2. 事务提交
   参与者接收到commit请求后，会正式执行事务的提交操作。并在完成提交之后释放在整个事 务执行期间占用的事务资源。
3. 反馈事务提交结果 参与者在完成事务提交之后，向协调者发送ACK消息。
4. 完成事务 协调者接收到所有参与者反馈的Ack消息，完成事务。

• 中断事务

假如任何一个参与者向协调者反馈了NO响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

1. 发送回滚请求 协调者向所有参与者节点发出Rollback请求
2. 事务回滚 参与者接收到Rollback请求后，会利用其在阶段1中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
3. 反馈事务回滚结果 参与者在完成事务回滚之后，向协调者发送Ack消息
4. 中断事务 协调者接收到所有参与者反馈的Ack消息后，完成事务中断。

以上就是二阶段提交过程中，前后两个阶段分别进行的处理逻辑。简单的讲二阶段提交就是将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事物都采用先尝试后提交的方式，因此也可以将二阶段提交看作一个强一致性的算法。

优缺点

二阶段提交的优点：原理简单，实现方便。
二阶段提交的缺点：同步阻塞，单点问题，脑裂，太过保守。

• 同步阻塞

二阶段提交存在的最大的一个问题就是同步阻塞，这会极大限制分布式系统的性能。在二阶段提交的执行过程中，所有参与该事务的逻辑都处在阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中都无法进行其他的操作。

• 单点问题

协调者在整个二阶段提交的过程中占据了非常重要的角色，一旦协调者出现了问题，那么整个二阶段提交流程都将无法运转，更为严重的是，如果协调者在阶段二出现问题的话，那么其他参与者都将会一直处于锁定事务资源的状态中，而无法完成事务操作。

• 数据不一致

在二阶段提交协议的阶段二，即执行事务提交的时候，当协调者向所有的参与者发送commit请求之后，发生了局部网络异常或者是协调者在尚未发送完commit请求之前自身发生了崩溃，导致最终只有部分参与者接收到了commit请求。于是这部分收到请求的参与者就会进行事务的提交，而其他没有收到commit请求的参与则无法进行事务提交，于是真个分布式系统便出现了数据不一致现象。

• 太过保守

如果在协调者指示参与者进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，这样的策略显得比较保守。换句话说二阶段提交协议没有设计较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。

3.2、3PC

除了引入超时机制之外，3PC把2PC的“提交事务请求”过程再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。因为同事引入了其它问题，所以实际应用并不多，我们这里略微提一下。

优缺点：

• 优点

相较于二阶段提交协议，三阶段提交协议最大的有点就是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。

• 缺点

三阶段提交协议在去除阻塞的同时也引入了新的问题，那就是在参与者接收到preCommit消息后，如果网络出现分区，此时协调者所在的节点和参与者无法进行正常的网络通信，在这种情况下该参与者依然会进行事务的提交，者必然会出现数据的不一致性。

3.3、Paxos

paxos 算法 是莱斯利,兰伯特 于1990 年提出的一种基于消息传递且具有高度容错性一致性算法，是目前公认的解决分布式一致性最有效的算法之一。

Paxos算法引入"过半"的理念，也就是少数服从多数原则，支持分布式节点角色之间轮换，这极大的避免了分布式单点的出现，因此Paxos算法既解决了无限等待问题，也解决了“脑裂”问题，是目前来说最优秀的分布式一致性协议之一。