ZooKeeper架构篇 - 分布式协调服务ZooKeeper

前言

本文基于 ZooKeeper 3.8.0 版本。

ZooKeeper集群搭建

准备四台服务器，IP地址分别为10.211.55.6、10.211.55.7、10.211.55.8、10.211.55.9

下载并解压 ZooKeeper 文件，四台服务器进入 data 目录分别创建一个 myid 文件，文件内容分别为1、2、3、4。然后分别进入 conf 目录，复制 zoo_sample.cfg文件到 zoo.cfg 文件。

每台服务器的 zoo.cfg 文件分别添加如下：

server.1=10.211.55.7:2188:3188
server.2=10.211.55.6:2188:3188
server.3=10.211.55.8:2188:3188
server.4=10.211.55.9:2188:3188:observer

其中作为 Observer 角色的 10.211.55.9 服务器的 zoo.cfg 文件额外添加如下：

peerType=observer

启动 ZooKeeper，命令如下：

./bin/zkServer.sh start

查看 ZooKeeper 的角色，命令如下：

./bin/zkServer.sh status

关闭 ZooKeeper，命令如下：

./bin/zkServer.sh stop

可视化工具可以选择 PrettyZoo

下载地址

mac版本安装失败解决方案

分布式架构

从集中式到分布式

集中式系统存在单点问题。一旦一台大型主机出现故障，导致整个系统不可用。

随着业务规模的扩大，集中式为代表的大型机的性能可能会出现瓶颈。

而大型机只能通过堆硬件的方式来垂直拓展，成本高而收效低。

而分布式相较于集中式具备高性能、高可用、可拓展三个重要的特性。

集中式的特点

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

集中式的最大的特点就是部署结构简单。由于集中式系统往往基于底层性能强大的大型主机，所以无需考虑对服务进行多个节点的部署，也就不用考虑多个节点之间的分布式协作问题。

分布式的特点

在《分布式系统概念与设计》一书中，对分布式系统定义为：一个硬件或者软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

分布式系统具备如下几个特点：

• 分布式：分布式系统中的多台计算机都会在空间上随意分布，同时，机器的分布情况也会随时变动。
• 对等性：分布式系统中的计算机没有主从之分，各个计算机节点都是对等的。为了对外提供高可用的服务，可以对数据和服务进行副本处理。数据副本是指在不同的节点上持久化同一份数据，当一个节点存储的数据丢失时，可以从副本上读取该数据。服务副本是指多个节点提供相同的服务，每个节点都有能力接收来自外部的请求并进行处理。
• 并发性：分布式系统中的多个节点可能会并发进行一些操作。
• 缺乏全局时钟：分布式系统缺乏一个全局的时钟序列控制。
• 故障总是会发生：分布式系统的各个计算机，都有可能发生任何形式的故障。一个被大量工程实践所检验过的黄金定理是：任何在设计阶段考虑到的异常情况，一定会在系统实际运行中发生，并且在系统实际运行过程中还会遇到很多在设计时未能考虑到的异常故障。

分布式环境的问题

在分布式环境下，可能会遇到网络、存储方面的问题：

• 网络故障：分布式系统需要在各个节点之间进行网络通信。由于网络本身的不可靠性，因此每次网络通信可能会面临网络不可用的问题。此外，也有可能遇到网络延迟、丢包、乱序等问题。如果发生局部网络异常导致只有部分节点之间可以正常通信，从而出现网络分区问题。极端情况下这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能，包括对数据的事务处理，这会给分布式一致性带来非常大的挑战。
• 存储故障：分布式系统的某个节点出现单点问题，比如宕机、磁盘损坏等。

CAP理论

一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）、分区容错性（P：Partition tolerance），最多只能同时满足其中两项。

一致性：数据在多个副本之间是否能够保持一致的特性。对于一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进行更新并且更新成功后，其它节点上的数据也要得到相应的更新。如果能够做到对一个数据项的更新操作执行成功，所有的用户都可以读取到最新值，那么这样的系统也被认为是具有强一致性（或者严格的一致性）。

可用性：系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。“有限的时间”是指合理的响应时间，不同场景下响应时间的期望值有所不同。“返回结果”是指系统在完成用户请求的处理后，返回一个正常的响应结果，即成功或者失败，不能是一个让用户感到困惑的结果。

分区容错性：分布式系统在遇到网络分区时，仍然需要保证对外提供满足一致性和可用性的服务，除非是整个网络都发生了故障。“网络分区”是指分布式系统中，不同的节点分布在不同的子网络，由于一些特殊原因导致这些子网络之间出现网络不连通的情况，从而使整个系统的网络环境被切分成了若干孤立的区域。

BASE理论

BASE 是 Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致性）的简写。BASE 是对 CAP 一致性和可用性权衡的结果，面向的是大型高可用可拓展的分布式系统，核心思想是即使无法做到强一致性，但是每个应用可以根据自身的业务特点，采用适当的方式使系统达到最终一致性。也就是说牺牲强一致性来获得可用性，并且允许数据在一段时间内是不一致的，但是最终达到一致性状态。

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

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

软状态：也称为弱状态，是指允许系统中的数据存在中间状态，并认为这种中间状态的存在不会影响系统的整体可用性，即允许在不同节点的数据副本之间进行数据同步的过程存在延时。

最终一致性：系统中的所有数据副本，在经过一段时间的同步后，最终能够达到一个一致性的状态。

一致性协议

2PC

即 Two Phrase Commit，二阶段提交。

它是计算机网络尤其是在数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性而设计的一种算法。通常二阶段提交协议也被认为是一种一致性协议，用来保证分布式系统的数据一致性。目前，绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的。

阶段一、执行事务/准备阶段

1、协调者向所有参与者发送 Prepare 请求，询问是否可以执行事务提交操作，然后等待各参与者的响应。

2、各参与者执行事务操作，并将 Undo、Redo 信息记录到事务日志中。

3、各参与者向协调者反馈事务询问的响应（如果参与者成功执行了事务操作则反馈 Yes，否则反馈 No）。

阶段二、提交事务/提交阶段

如果协调者收到的反馈都是 Yes，则提交事务。如果有任意一个参与者反馈的是 No 或者在等待超时后协调者没有接收到所有参与者的反馈，则中断事务。

提交事务

1、协调者向所有参与者发送 Commit 请求。

2、参与者接收到 Commit 请求后，提交事务，并且在提交完成后释放占用的事务资源。

3、参与者在完成事务提交后，向协调者发送 Ack 消息。

4、协调者接收到所有参与者的 Ack 消息后，完成事务。

中断事务

1、协调者向所有参与者发送 Rollback 请求。

2、参与者接收到 Rollback 请求后，使用 Undo 信息进行事务回滚，并且在回滚完成后释放占用的事务资源。

3、参与者在完成事务回滚后，向协调者发送 Ack 消息。

4、协调者接收到所有参与者的 Ack 消息后，中断事务。

优点：

• 原理简单
• 实现方便

缺点：

• 同步阻塞：协调者在等待其它参与者响应的过程中，参与者处于阻塞状态，无法进行其它操作。
• 单点问题：如果协调者出现问题，整个二阶段提交流程无法流转。
• 数据不一致：在阶段二中，如果协调者发送完 Commit 请求后，发生了局部网络异常，导致只有部分参与者接收到了请求并进行事务提交，其它没有收到的参与者无法进行事务提交，最终导致数据不一致。
• 太过保守：缺乏完善的容错机制，任意一个节点的失败都会导致整个事务的失败。在阶段一时，如果有参与者出现故障，导致协调者只能依靠自身的超时机制判断是否需要中断事务。

3PC

即 Three-Phrase Commit，三阶段提交。

它是二阶段提交的改进型，将二阶段提交的 “准备阶段” 一分为二，形成了由 canCommit、preCommit、doCommit 三个阶段组成的事务处理协议。相较于二阶段提交只有协调者有超时机制，三阶段提交对参与者增加了超时机制。

阶段一、canCommit

1、协调者向所有的参与者发送 canCommit 请求，询问是否可以执行事务提交操作，并且等待各参与者的响应。

2、参与者如果认为自己可以顺利执行事务，则反馈 YES 响应并进入预备状态；否则反馈 NO 响应。

阶段二、preCommit

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

如果有任何一个参与者反馈的是 NO 响应，或者等待超时后协调者无法接收到所有参与者的反馈响应，则中断事务。

事务预提交

1、协调者向所有参与者发送 preCommit 请求。

2、参与者执行事务操作，并将 Undo、Redo 信息记录到事务日志中。

3、如果参与者成功执行了事务操作，则向协调者反馈 ACK 响应；否则反馈 NO 响应。

中断事务

1、协调者向所有参与者发送 abort 请求。

2、参与者中断事务。

阶段三、doCommit

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

如果有任何一个参与者反馈的是 NO 响应，或者等待超时后协调者无法接收到所有参与者的反馈响应，则中断事务。

事务提交

1、协调者向所有参与者发送 doCommit 请求。

2、参与者提交事务，并且在提交完成之后释放在整个事务执行过程中占用的事务资源，完成事务提交之后向协调者发送 ACK 响应。

3、协调者接收到所有参与者反馈的 ACK 响应后完成事务。

中断事务

1、协调者向所有参与者发送 abort 请求。

2、参与者利用阶段二中记录的 Undo 信息执行事务回滚，并且在回滚完成后释放在整个事务执行期间占用的事务资源。在完成事务回滚后，向协调者发送 ACK 响应。

3、协调者接收到所有参与者反馈的 ACK 响应后中断事务。

优点：

• 降低了参与者的阻塞范围：阶段二的参与者在等待指定时间后仍未接收到协调者发送的 preCommit 请求则取消阻塞，可以做其它事；阶段三的参与者在等待指定时间后仍未接收到协调者发送的 doCommit 请求则提交事务。
• 对参与者增加超时机制，即使协调者出现单点故障后，整个三阶段提交流程继续流转。

缺点：

• 数据不一致：在阶段三时，如果发生网络分区问题，协调者所在的节点无法与参与者进行正常的通信，参与者由于超时机制最终会提交事务，这会带来数据不一致的问题。

ZooKeeper架构

介绍

ZooKeeper 是一个开源的分布式协调服务，是 Google Chubby 的开源实现。ZooKeeper 的设计目标是将那些复杂并且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

分布式协调服务：分布式场景下存在多个节点，每个节点都可以提出请求，经过协调服务的协调，使各节点达成一致，从而确定最终的请求。用于解决分布式环境下的多进程的同步控制，使其顺序访问某个临界区，防止产生脏数据。

ZooKeeper 是一个典型的分布式数据一致性的解决方案，可以保证如下的分布式一致性特性：

• 顺序一致性：从同一个客户端发起的事务请求，最终会严格按照其发起顺序应用到 ZooKeeper 中。
• 原子性：所有事务请求的处理结果在整个集群中的所有机器的应用情况都是一致的，要么全部应用，要么全部没有应用。
• 单一视图：无论客户端连接的是哪个 ZooKeeper 服务器，其看到的服务端数据模型都是一致的。
• 可靠性：一旦服务端成功应用了一个事务，并且完成了对客户端的响应，那么该事务所引起的服务端状态变更会一直保留下来，除非有另一个事务又对其进行了修改。
• 实时性：可以保证一定的时间段内，客户端最终一定能够从服务端读取到最新的数据状态。

通过 sync 方法，也提供了强一致性的保证。