Zookeeper架构详解

Posted 2023-04-18

参考技术A 下图是 Zookeeper 的架构图，ZooKeeper 集群中包含 Leader、Follower 以及 Observer 三个角色：

Client 是 Zookeeper 的客户端，请求发起方。

Observer 能很好的对 Zookeeper 集群进行扩展，Observer 可以提供 Client 读写，但不参与投票。因此，Observer 节点对集群不影响投票耗时，也不影响集群选举。另外，加入 Observer 对读性能是一个很大的提升。

应用通过客户端库来对ZooKeeper实现了调用。客户端库负责与ZooKeeper服务器端进行交互。
下展示了客户端与服务器端之间的关系。每一个客户端导入客户端库，之后便可以与任何ZooKeeper的节点进行通信。
ZooKeeper服务器端运行于两种模式下： 独立模式（standalone） 和 仲裁模式（quorum） 。
独立模式 几乎与其术语所描述的一样： 有一个单独的服务器，ZooKeeper状态无法复制 。
在 仲裁模式下 ，具有 一组 ZooKeeper服务器，我们称为ZooKeeper集合（ZooKeeper ensemble），它们之前可以进行状态的复制，并同时为服务于客户端的请求。
从这个角度出发，我们使用术语“ZooKeeper集合”来表示一个服务器设施，这一设施可以由独立模式的一个服务器组成，也可以仲裁模式下的多个服务器组成。

基于此，如果想搭建一个能够允许 N 台机器 down 掉的集群，那么就要部署一个由 2*N+1 台服务器构成的 ZooKeeper 集群。 因此，如果部署了 3 个 Zookeeper 节点（非 Observer），则如果至少有 2个节点可用则整个集群就可用，意味着 1 个节点故障，不影响 Zookeeper 集群对外提供服务；如果部署了 5 个节点，意味着 2 个节点同时故障，Zookeeper 集群依然能够正常对外提供服务。

部署的节点数一般为奇数个，这里不是说不能为偶数个。

通过以上可以发现，3台服务器和4台服务器都最多允许1台服务器挂掉，5台服务器和6台服务器都最多允许2台服务器挂掉,明显4台服务器成本高于3台服务器成本，6台服务器成本高于5服务器成本。这是由于半数以上投票通过决定的。

在对ZooKeeper集合执行任何请求前，一个客户端必须先与服务建立会话。会话的概念非常重要，对ZooKeeper的运行也非常关键。客户端提交给ZooKeeper的所有操作均关联在一个会话上。 当一个会话因某种原因而中止时，在这个会话期间创建的临时节点将会消失。

会话提供了顺序保障 ，这就意味着同一个会话中的请求会以 FIFO（先进先出） 顺序执行。通常，一个客户端只打开一个会话，因此客户端请求将全部以FIFO顺序执行。如果客户端拥有多个并发的会话，FIFO顺序在多个会话之间未必能够保持。而即使一个客户端中连贯的会话并不重叠，也未必能够保证FIFO顺序。

会话的生命周期（lifetime）是指会话从创建到结束的时期，无论会话正常关闭还是因超时而导致过期。
一个会话的主要可能状态大多是简单明了的： CONNECTING 、 CONNECTED 、 CLOSED 和 NOT_CONNECTED 。状态的转换依赖于发生在客户端与服务之间的各种事件（见下图）。

如果一个客户端与服务器因超时而断开连接，客户端仍然保持CONNECTING状态。 如果因网络分区问题导致客户端与ZooKeeper集合被隔离而发生连接断开，那么其状态将会一直保持，直到显式地关闭这个会话，或者分区问题修复后，客户端能够获悉ZooKeeper服务器发送的会话已经过期。 发生这种行为是因为ZooKeeper集合对声明会话超时负责，而不是客户端负责。直到客户端获悉ZooKeeper会话过期，否则 客户端不能声明自己的会话过期。 然而， 客户端可以选择关闭会话。

创建一个会话时，你需要设置会话超时这个重要的参数，这个参数设置了ZooKeeper服务允许会话被声明为超时之前存在的时间。 如果经过时间t之后服务接收不到这个会话的任何消息，服务就会声明会话过期。 而在客户端侧，如果经过t/3的时间未收到任何消息，客户端将向服务器发送心跳消息。在经过2t/3时间后，ZooKeeper客户端开始寻找其他的服务器，而此时它还有t/3时间去寻找。

在仲裁模式下，客户端有多个服务器可以连接，而在独立模式下，客户端只能尝试重新连接单个服务器。在仲裁模式中，应用需要传递可用的服务器列表给客户端，告知客户端可以连接的服务器信息并选择一个进行连接。

当尝试连接到一个不同的服务器时，非常重要的是， 这个服务器的ZooKeeper状态要与最后连接的服务器的ZooKeeper状态保持最新。
ZooKeeper通过在服务中排序更新操作来决定状态是否最新。 ZooKeeper确保每一个变化相对于所有其他已执行的更新是完全有序的。因此，如果一个客户端在位置i观察到一个更新，它就 不能连接到只观察到i'<i的服务器上。
在ZooKeeper实现中，系统根据每一个更新建立的顺序来分配给事务标识符。下图描述了在重连情况下 事务标识符（zkid） 的使用。当客户端因超时与s1 断开连接后，客户端开始尝试连接s2 ，但s2 延迟于客户端所知的变化。然而，s3 对这个变化的情况与客户端保持一致，所以s3 可以安全连接。

Zookeeper 集群高可用部署详解

干货分享 | Zookeeper技术：分布式架构详解分布式技术详解分布式事务

点击蓝字

关注我们

//

 选择“置顶公众号”，精品文章第一时间送达！

//

一、分布式架构详解

1、分布式发展历程

1.1 单点集中式

特点：App、DB、FileServer都部署在一台机器上。并且访问请求量较少

1.2  应用服务和数据服务拆分

 特点：App、DB、FileServer分别部署在独立服务器上。并且访问请求量较少

1.3  使用缓存改善性能

 特点：数据库中频繁访问的数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的压力

 

1.4 应用服务器集群

 特点：多台应用服务器通过负载均衡同时对外提供服务，解决单台服务器处理能力上限的问题

 

1.5 数据库读写分离

 特点：数据库进行读写分离（主从）设计，解决数据库的处理压力

 

1.6 反向代理和CDN加速

 特点：采用反向代理和CDN加快系统的访问速度

 

1.7 分布式文件系统和分布式数据库

 特点：数据库采用分布式数据库，文件系统采用分布式文件系统

随着业务的发展，最终数据库读写分离也将无法满足需求，需要采用分布式数据库和分布式文件系统来支撑

分布式数据库是数据库拆分后的最后方法，只有在单表规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的机器上

 

二、 分布式技术详解

1. 并发性

2. 分布性

　　大任务拆分成多个任务部署到多台机器上对外提供服务

3. 缺乏全局时钟  

　　时间要统一

4. 对等性

　　一个服务部署在多台机器上是一样的，无任何差别

5. 故障肯定会发生

　　 硬盘坏了 CPU烧了....

三、分布式事务

1. ACID

原子性（Atomicity）：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。

　　　　　　　　　　　  比如A有500元，B有300元，A向B转账100，无论怎么样，A和B的总和总是800元
隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
持久性（Durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

2. 2P/3P

2P= Two Phase commit   二段提交（RDBMS（关系型数据库管理系统）经常就是这种机制，保证强一致性）

3P= Three Phase commit  三段提交

说明：2P/3P是为了保证事务的ACID（原子性、一致性、隔离性、持久性）

2.1 2P的两个阶段

阶段1：提交事务请求（投票阶段）询问是否可以提交事务

阶段2：执行事务提交（commit、rollback） 真正的提交事务

 

2.2 3P的三个阶段

阶段1：是否提交-询问是否可以做事务提交
阶段2：预先提交-预先提交事务
阶段3：执行事务提交（commit、rollback）真正的提交事务

 

说明：3P把2P的阶段一拆分成了前面两个阶段

3. CAP理论

一致性（Consistency）：分布式数据库的数据保持一致

可用性（Availability）：任何一个节点挂了，其他节点可以继续对外提供服务

分区容错性（网络分区）Partition tolerance：一个数据库所在的机器坏了，如硬盘坏了，数据丢失了，可以新增一台机器，然后从其他正常的机器把备份的数据同步过来

CAP理论的特点：CAP只能满足其中2条

CA(放弃P)：将所有的数据放在一个节点。满足一致性、可用性。
AP(放弃C)：放弃强一致性，用最终一致性来保证。
CP(放弃A)：一旦系统遇见故障，受到影响的服务器需要等待一段时间，在恢复期间无法对外提供服务。

举例说明CAP理论：

有3台机器分别有3个数据库分别有两张表,数据都是一样的
Machine1-db1-tbl_person、tbl_order
Machine2-db2-tbl_person、tbl_order
Machine3-db3-tbl_person、tbl_order
1）当向machine1的db1的表tbl_person、tbl_order插入数数据时，同时要把插入的数据同步到machine2、machine3，这就是一致性
2）当其中的一台机器宕机了，可以继续对外提供服务，把宕机的机器重新启动起来可以继续服务，这就是可用性
3）当machine1的机器坏了，数据全部丢失了，不会有任何问题，因为machine2和machine3上还有数据，重新加一台机器machine4，把machine2和machine3其中一台机器的备份数据同步过来就可以了，这就是分区容错性

4. BASE理论

基本可用（bascially available）、软状态（soft state）、最终一致性（Eventually consistent）
基本可用：在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级）
软状态：允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。
　　　　1、这里的中间状态是指不同的data replication之间的数据更新可以出现延时的最终一致性
　　　　2、如CAP理论里面的示例，当向machine1的db1的表tbl_person、tbl_order插入数数据时，同时要把插入的数据同步到machine2、machine3，当machine3的网络有问题时，同步失败，但是过一会网络恢复了就同步成功了，这个同步失败的状态就称为软状态，因为最终还是同步成功了。
最终一致性：data replications经过一段时间达到一致性。

5. Paxos算法

5.1 介绍Paxos算法之前我们先来看一个小故事

拜占庭将军问题

　　拜占庭帝国就是5~15世纪的东罗马帝国，拜占庭即现在土耳其的伊斯坦布尔。我们可以想象，拜占庭军队有许多分支，驻扎在敌人城外，每一分支由各自的将军指挥。假设有11位将军，将军们只能靠通讯员进行通讯。在观察敌人以后，忠诚的将军们必须制订一个统一的行动计划——进攻或者撤退。然而，这些将军里有叛徒，他们不希望忠诚的将军们能达成一致，因而影响统一行动计划的制订与传播。
　　问题是：将军们必须有一个协议，使所有忠诚的将军们能够达成一致，而且少数几个叛徒不能使忠诚的将军们作出错误的计划——使有些将军进攻而另一些将军撤退。
　　假设有9位忠诚的将军，5位判断进攻，4位判断撤退，还有2个间谍恶意判断撤退，虽然结果是错误的撤退，但这种情况完全是允许的。因为这11位将军依然保持着状态一致性。

总结：
1）11位将军进攻城池
2）同时进攻（议案、决议）、同时撤退（议案、决议）
3）不管撤退还是进攻，必须半数的将军统一意见才可以执行
4）将军里面有叛徒，会干扰决议生成

5.2 下面就来介绍一下Paxos算法

Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。 

Paxos：多数派决议（最终解决一致性问题）

Paxos算法有三种角色：Proposer，Acceptor，Learner

Proposer：提交者（议案提交者）

          提交议案(判断是否过半)，提交批准议案(判断是否过半)

Acceptor：接收者（议案接收者）

          接受议案或者驳回议案，给proposer回应(promise)

Learner：学习者（打酱油的）

         如果议案产生，学习议案。

设定1：如果Acceptor没有接受议案，那么他必须接受第一个议案

设定2：每个议案必须有一个编号，并且编号只能增长，不能重复。越往后越大。

设定3：接受编号大的议案，如果小于之前接受议案编号，那么不接受

设定4：议案有2种(提交的议案，批准的议案)

1）Prepare阶段（议案提交）

a）Proposer希望议案V。首先发出Prepare请求至大多数Acceptor。Prepare请求内容为序列号K

b）Acceptor收到Prepare请求为编号K后，检查自己手里是否有处理过Prepare请求。

c）如果Acceptor没有接受过任何Prepare请求，那么用OK来回复Proposer，代表Acceptor必须接受收到的第一个议案（设定1）

d）否则，如果Acceptor之前接受过任何Prepare请求（如：MaxN），那么比较议案编号，如果K<MaxN，则用reject或者error回复Proposer

e）如果K>=MaxN，那么检查之前是否有批准的议案，如果没有则用OK来回复Proposer，并记录K

f）如果K>=MaxN，那么检查之前是否有批准的议案，如果有则回复批准的议案编号和议案内容（如：<AcceptN, AcceptV>， AcceptN为批准的议案编号，AcceptV为批准的议案内容）

2）Accept阶段（批准阶段）

a）Proposer收到过半Acceptor发来的回复，回复都是OK，且没有附带任何批准过的议案编号和议案内容。那么Proposer继续提交批准请求，不过此时会连议案编号K和议案内容V一起提交（<K, V>这种数据形式）

b）Proposer收到过半Acceptor发来的回复，回复都是OK，且附带批准过的议案编号和议案内容（<pok，议案编号，议案内容>）。那么Proposer找到所有回复中超过半数的那个（假设为<pok，AcceptNx，AcceptVx>）作为提交批准请求（请求为<K，AcceptVx>）发送给Acceptor。

c）Proposer没有收到过半Acceptor发来的回复，则修改议案编号K为K+1，并将编号重新发送给Acceptors（重复Prepare阶段的过程）

d）Acceptor收到Proposer发来的Accept请求，如果编号K<MaxN则不回应或者reject。

e）Acceptor收到Proposer发来的Accept请求，如果编号K>=MaxN则批准该议案，并设置手里批准的议案为<K，接受议案的编号，接受议案的内容>，回复Proposer。

f）经过一段时间Proposer对比手里收到的Accept回复，如果超过半数，则结束流程（代表议案被批准），同时通知Leaner可以学习议案。

g) 经过一段时间Proposer对比手里收到的Accept回复，如果未超过半数，则修改议案编号重新进入Prepare阶段。

5.3 Paxos示例

示例1：先后提议的场景

 

角色：

proposer：参谋1，参谋2

acceptor：将军1，将军2，将军3（决策者）

1）参谋1发起提议，派通信兵带信给3个将军，内容为（编号1）；
2）3个将军收到参谋1的提议，由于之前还没有保存任何编号，因此把（编号1）保存下来，避免遗忘；同时让通信兵带信回去，内容为（ok）；
3）参谋1收到至少2个将军的回复，再次派通信兵带信给3个将军，内容为（编号1，进攻时间1）；
4）3个将军收到参谋1的时间，把（编号1，进攻时间1）保存下来，避免遗忘；同时让通信兵带信回去，内容为（Accepted）；
5）参谋1收到至少2个将军的（Accepted）内容，确认进攻时间已经被大家接收；
6）参谋2发起提议，派通信兵带信给3个将军，内容为（编号2）；
7）3个将军收到参谋2的提议，由于（编号2）比（编号1）大，因此把（编号2）保存下来，避免遗忘；又由于之前已经接受参谋1的提议，因此让通信兵带信回去，内容为（编 号1，进攻时间1）；
8）参谋2收到至少2个将军的回复，由于回复中带来了已接受的参谋1的提议内容，参谋2因此不再提出新的进攻时间，接受参谋1提出的时间；

示例2：交叉场景

 

角色：

proposer：参谋1，参谋2

acceptor：将军1，将军2，将军3（决策者）

1）参谋1发起提议，派通信兵带信给3个将军，内容为（编号1）；

2）3个将军的情况如下
　　a）将军1和将军2收到参谋1的提议，将军1和将军2把（编号1）记录下来，如果有其他参谋提出更小的编号，将被拒绝；同时让通信兵带信回去，内容为（ok）；
　　b）负责通知将军3的通信兵被抓，因此将军3没收到参谋1的提议；

3）参谋2在同一时间也发起了提议，派通信兵带信给3个将军，内容为（编号2）；
4）3个将军的情况如下
　　a）将军2和将军3收到参谋2的提议，将军2和将军3把（编号2）记录下来，如果有其他参谋提出更小的编号，将被拒绝；同时让通信兵带信回去，内容为（ok）；
　　b）负责通知将军1的通信兵被抓，因此将军1没收到参谋2的提议；
5）参谋1收到至少2个将军的回复，再次派通信兵带信给有答复的2个将军，内容为（编号1，进攻时间1）；
6）2个将军的情况如下
　　a）将军1收到了（编号1，进攻时间1），和自己保存的编号相同，因此把（编号1，进攻时间1）保存下来；同时让通信兵带信回去，内容为（Accepted）；
　　b）将军2收到了（编号1，进攻时间1），由于（编号1）小于已经保存的（编号2），因此让通信兵带信回去，内容为（Rejected，编号2）；
7）参谋2收到至少2个将军的回复，再次派通信兵带信给有答复的2个将军，内容为（编号2，进攻时间2）；
8）将军2和将军3收到了（编号2，进攻时间2），和自己保存的编号相同，因此把（编号2，进攻时间2）保存下来，同时让通信兵带信回去，内容为（Accepted）；
9）参谋2收到至少2个将军的（Accepted）内容，确认进攻时间已经被多数派接受；

10）参谋1只收到了1个将军的（Accepted）内容，同时收到一个（Rejected，编号2）；参谋1重新发起提议，派通信兵带信给3个将军，内容为（编号3）；

11）3个将军的情况如下
　　a）将军1收到参谋1的提议，由于（编号3）大于之前保存的（编号1），因此把（编号3）保存下来；由于将军1已经接受参谋1前一次的提议，因此让通信兵带信回去，内容为（编号1，进攻时间1）；
　　b）将军2收到参谋1的提议，由于（编号3）大于之前保存的（编号2），因此把（编号3）保存下来；由于将军2已经接受参谋2的提议，因此让通信兵带信回去，内容为（编号2，进攻时间2）；
　　c）负责通知将军3的通信兵被抓，因此将军3没收到参谋1的提议；

12）参谋1收到了至少2个将军的回复，比较两个回复的编号大小，选择大编号对应的进攻时间作为最新的提议；参谋1再次派通信兵带信给有答复的2个将军，内容为（编号3，进攻时间2）；
13）将军1和将军2收到了（编号3，进攻时间2），和自己保存的编号相同，因此保存（编号3，进攻时间2），同时让通信兵带信回去，内容为（Accepted）；
14）参谋1收到了至少2个将军的（accepted）内容，确认进攻时间已经被多数派接受。

四. Zookeeper ZAB协议

Zookeeper Automic Broadcast(ZAB)，即Zookeeper原子性广播，是Paxos经典实现

术语：

quorum：集群过半数的集合

1. ZAB(zookeeper)中节点分四种状态

looking：选举Leader的状态（崩溃恢复状态下）

following：跟随者（follower）的状态，服从Leader命令

leading：当前节点是Leader，负责协调工作。

observing：observer(观察者)，不参与选举，只读节点。

2. ZAB中的两个模式（ZK是如何进行选举的）

崩溃恢复、消息广播

 

1）崩溃恢复

leader挂了，需要选举新的leader

 

 

a.每个server都有一张选票<myid，zxid>，如（3,9），选票投自己。
b.每个server投完自己后，再分别投给其他还可用的服务器。如把Server3的（3,9）分别投给Server4和Server5，一次类推
c.比较投票，比较逻辑：优先比较Zxid，Zxid相同时才比较myid。比较Zxid时，大的做leader；比较myid时，小的做leader
d.改变服务器状态（崩溃恢复->数据同步，或者崩溃恢复->消息广播）

相关概念补充说明：

epoch周期值

acceptedEpoch（比喻：年号）：follower已经接受leader更改年号的（newepoch）提议。

currentEpoch（比喻：当前的年号）：当前的年号

lastZxid：history中最近接收到的提议zxid(最大的值)

history：当前节点接受到事务提议的log

Zxid数据结构说明：

cZxid = 0x10000001b

64位的数据结构

高32位：10000

　　　　Leader的周期编号+myid的组合

低32位：001b

　　　　事务的自增序列（单调递增的序列）只要客户端有请求，就+1

当产生新Leader的时候，就从这个Leader服务器上取出本地log中最大事务Zxid，从里面读出epoch+1，作为一个新epoch，并将低32位置0（保证id绝对自增）

2）消息广播（类似2P提交）

 

a.Leader接受请求后，将这个请求赋予全局的唯一64位自增Id（zxid）。
b.将zxid作为议案发给所有follower。
c.所有的follower接受到议案后，想将议案写入硬盘后，马上回复Leader一个ACK（OK）。
d.当Leader接受到合法数量（过半）Acks，Leader给所有follower发送commit命令。
e.follower执行commit命令。
注意：到了这个阶段，ZK集群才正式对外提供服务，并且Leader可以进行消息广播，如果有新节点加入，还需要进行同步。

3）数据同步

a.取出Leader最大lastZxid（从本地log日志来）
b.找到对应zxid的数据，进行同步（数据同步过程保证所有follower一致）
c.只有满足quorum同步完成，准Leader才能成为真正的Leader

 

(本文版权归原作者所有。转载文章仅为传播更多信息之目的，如有侵权请与我们联系，我们将及时处理。)

—END—

长按二维码关注【IT日讯 ITDaily】

IT日讯 ITDaily