1. Zookeeper深入剖析

1.1 ZK特性与集群架构设计

ZK主要分为三种角色：

• Leader（领导者）：一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。
• Follower（跟随者）：一个Zookeeper集群可能同时存在多个Follower，它会响应Leader的心跳。Follower可以处理客户端的读请求，但写请求转发给Leader处理，并且负责参与新 leader的选举、响应 leader 的提议。
• Observer（观察者）：无投票权，不参加选举， 也不响应提议。Observer不需要将事务持久化到磁盘，如果重启需要从 leader 重新同步整个名字空间。

ZK特性：

• 顺序一致性
• 实时性
• 原子性

1.2 ZK数据结构与存储

1.2.1 ZK数据结构模型

节点存储容量不能超过1M。

ZNode节点类型：

Znode的分为四类：

• 持久节点（persistent node）：节点会被持久化处理，执行命令： create /apps/app1 "order" 。
• 临时节点（ephemeral node）：客户端断开连接后，ZooKeeper会自动删除临时节点， 执行命令：create -e /apps/app1 "order" 。
• 顺序节点（sequential node）：每次创建顺序节点时，ZooKeeper都会在路径后面自动添加上10位的数字，从1开始，最大值为2147483647 （2^32-1），每个顺序节点都有一个单独的计数器，并且单调递增的，由 leader 实例维护，执行命令： create -s /apps/app1 "order" 。
• 临时顺序节点（EPHEMERAL_SEQUENTIAL）：基本特性与临时节点一致，创建节点的过程中，zookeeper会在其名字后自动追加一个单调增长的数字后缀，作为新的节点名。

ZNode节点属性：

1.2.2 ZK数据存储方式

数据存储方式分为三类：

1. 内存数据

内存数据结构分为三类：

• DataTree： 内存数据存储的核心
• DataNode： 数据存储的最小单元
• ZKDatabase： ZK的内存数据库

2. 事务日志

事务日志处理流程：

事务日志文件内容示例：

查看日志命令：

产生的日志内容：

3. 数据快照（snapshot）

数据快照用来记录Zookeeper服务器上某一时刻的全量内存数据内容，并将其写入指定的磁盘文件中。Zookeeper在进行若干次事务日志记录后，将内存数据库的全量数据Dump到本地文件中，这个就是数据快照

快照查看命令：

其处理步骤如下：

1. 检查是否需要进行数据快照，每一次事务日志记录之后，Zookeeper都会检测是否需要进行数据快照，考虑到数据快照对于Zookeeper机器的影响，需要尽量避免ZK集群中的所有机器在同一时刻进行数据快照。采用过半随机策略进行数据快照操作。
2. 切换事务日志文件，表示当前的事务日志已经写满，需要重新创建一个新的事务日志。
3. 创建数据快照的异步线程，创建单独的异步线程来进行数据快照以避免影响Zookeeper主线程的运行状态。
4. 获取全量数据和会话信息，从ZKDatabase数据库中获取到DataTree和会话信息。
5. 生成快照数据文件名，ZK根据当前已经提交的最大ZXID来生成数据快照文件名。
6. 数据序列化，首先序列化文件头信息，然后再对会话信息和DataTree分别进行序列化，同时生成一个Checksum校验文件，一并写入快照文件中。

1.3 ZK的应用场景

1.3.1 服务注册发现

分布式服务架构中，服务的注册与发现是最核心的基础服务之一，注册中心可以看做是分布式服务架构的通信中心。

Zookeeper集群，通过监听机制，实现服务信息的订阅：

Zookeeper是采用ZAB协议保证了数据的强一致性。ZAB协议的实现原理是怎样？ZK是如何实现选举， Paxos算法又是如何运用的？

1.3.2 分布式锁

分布式锁的实现需要注意的：

同步访问共享资源。

• 锁的可重入性：递归调用不会被阻塞、不会发生死锁(synchronized methodA(), ReentrantLock)
• 锁的超时：避免死锁、死循环等意外情况
• 锁的阻塞：保证原子性等 ->下单（范围广， 包含商品， 账户资金， 下单信息生成，将粒度细化。）
• 锁的特性支持：阻塞锁、可重入锁、公平锁、联锁、信号量、读写锁

分布式锁的使用需要注意：

• 分布式锁的开销， 能不能用就不用
• 加锁的粒度
• 加锁的方式（并发量大， 缓存做实现）

基于ZK的分布式锁实现：

整体思想：每个客户端发起加锁时，生成一个唯一的临时有序节点。 如何判断锁是否创建呢？只需要判断是否存在临时节点（若存在， 则根据序号判断）。

ZK的分布式锁的优缺点

优点： 可以有效的解决单点问题，不可重入问题，非阻塞问题以及锁无法释放的问题。

缺点： 性能上不如基于缓存实现的分布式锁。ZK的强一致性， 一个事务的操作在所有节点都同步完成。

ZK是如何实现分布式锁？

1. 排它锁

• 定义： 如果某个事务(Transaction)对数据对象(Object)加上了排他锁，那么在整个加锁期间，只允许该事务对数据进行读取或更新操作，其他任何事务不能对该数据对象做任何操作，直到该事务释放了排他锁。
• 排它锁实现流程：

• Zookeeper 的强一致性特性，能够很好地保证在分布式高并发情况下节点的创建一定能够保证全局唯一性，即Zookeeper将会保证客户端无法重复创建一个已经存在的数据节点。可以利用Zookeeper这个特性，实现排他锁。

实现步骤：

• 定义锁：通过Zookeeper上的数据节点来表示一个锁
• 获取锁：客户端通过调用 create 方法创建锁的临时节点，创建成功的客户端代表获取锁，没有获得锁的客户端在该节点上注册Watcher监听，以便实时获取lock节点的变更情况
• 释放锁符合以下两种情况都可以让锁释放

1. 当前获得锁的客户端发生宕机或异常，那么Zookeeper上这个临时节点就会被删除
2. 正常执行完业务逻辑，客户端主动删除自己创建的临时节点

共享锁

定义： 如果事务Transaction对数据对象Object加上了共享锁，在不是写操作事务下， 其他事务仍可以对

Object进行读取操作。

共享锁实现流程：

1） 定义锁

2） 获取锁

如果是读请求，则创建 /lockpath/[hostname]-R-序号 节点，如果是写请求则创建 /lockpath/[hostname]-W-序号 节点。

3） 读写顺序判断处理

• 创建完节点后，获取 /lockpath 节点下的所有子节点，并对下面所有注册的子节点变更进行Watcher监听；
• 确定自己的节点序号在所有子节点中的顺序， 针对顺序的大小， 处理读写请求流程；
• 对于读请求：1. 如果没有比自己序号更小的子节点，或者比自己序号小的子节点都是读请求，那么表明可以成功获取到了共享锁；2. 如果有比自己序号小的子节点有写请求，那么先进行等待 。
• 对于写请求，如果存在比自己更小的节点，那么进行等待；
• 接收到Watcher通知后， 再次处理上面的读写请求流程。

4） 释放锁. 与排它锁逻辑一致。

基于ZK的共享锁实现流程：

共享锁产生的羊群效应解决方案

羊群效应该如何解决呢？其实只需要改进Watch的监听处理流程：

1.3.3 利用ZK实现公平选举

ZK是如何实现集群选举呢？

1. 基于ZK的Watch机制，ZK的所有节点的读取操作，都可以附带一个Watch，一旦数据有变化，Watch就会被触发，通知客户端数据发生变动。

2. 基于ZK实现的分布式锁，这里的锁是指排它锁，任意时刻，最多只有一个进程可以获取锁。

什么是公平选举？

公平选举是要遵循公平性，大家都遵循规则，依照请求先后顺序，参与选举。

选举处理流程

三台节点向ZK集群创建Sequence类型节点，每个节点所创建的序号不一样， 他们会判断自己所创建的节点序号是否为最小，这个与顺序有关， 如果是最小， 则选取为Leader，否则为Follower角色。

如果Leader出现问题如何处理？

Leader 所在进程如果意外宕机，其与 ZooKeeper 间的 Session 结束，由于其创建的节点为Ephemeral类型，故该节点会自动被删除。

Follower角色节点是如何感知的？

在公平模式下， 每个Follower都会 Watch 序号刚好比自己序号小的节点。在上图中，调用方节点2会Watch节点/Master/Leader1，调用方节点3会Watch节点/Master/Leader2。如果Leader宕机，/Master/Leader1删除，调用方节点2就能得到通知。节点2先判断自己的序号 2 是不是当前最小的序号，在该场景下，其序号为最小，所以节点2成为新的Leader。

1.3.4 利用ZK实现非公平选举

什么是非公平选举？

非公平选举就是没有遵循选举的公平性，仍然沿用上面的例子： 村子里要选举村长，领导通知大家在明早7点前排队在前十的人就可以参与选举，这个时候有人晚到，但借关系插队排在前面，这个就是非公平选举。

选举处理流程

三台调用节点向ZK集群创建Non-sequence节点，但只会有一个调用节点创建成功，谁能够抢占资源在ZK集群创建成功，与顺序无关，则竞选为Leader，其他客户端则创建失败，成为Follower角色。

1.4 深入理解Leader选举

1.4.1 PAXOS选举算法

1. Paxos算法概述

背景：

主流分布式一致性算法包括Paxos，Raft和ZAB，它们之间有怎样的区别与关系？

Google Chubby的作者Mike Burrows说过，世上只有一种一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整或衍生版。

什么是Paxos？

Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一，其解决的问题就是在分布式系统中如何就某个值（决议）达成一致。

Paxos的作用：

常见的分布式系统中，总会发生机器宕机或网络异常（包括消息的延迟、丢失、重复、乱序）等情况。Paxos 算法是分布式一致性算法用来解决一个分布式系统如何就某个值(决议)达成一致性的问题。

2. 拜占庭问题

拜占庭将军问题是一个共识问题：一群将军想要实现某一个目标，必须是全体一致的决定，一致进攻或者一致撤退；但由于叛徒的存在，将军们不知道应该如何达成一致。

拜占庭问题情形在计算机世界中也会出现，如果三个节点中有一个异常节点，那么最坏情况下两个正常节点之间是无法保证一致性的。那么你之前听说过的 etcd 这样的系统可以保证三个节点有一个宕机的情况下依然可以对外提供一致性服务是为什么呢？因为这类系统并没有考虑拜占庭故障，在他们的假设里故障节点可能会停止服务，可能会超时，但是不会发送异常消息。尽管拜占庭的“幽灵”很难处理，但在实际工作应用中，却并不需要过分去考虑它，因为对于大多数系统来说，内部环境里，硬件故障导致消息错误的概率本身就很低，还要按照拜占庭叛徒的策略来处理故障就更为困难了。

3. Paxos角色

Paxos将系统中的角色分为三种：

• Proposer：提议者，提出提案Proposal（未经批准的决议）信息，它包括提案编号 (Proposal ID) 和提议的值 (Value)。
• Acceptor：决策者，参与决策，回应Proposers的提案。收到Proposal后可以接受提案，若Proposal获得多数Acceptors的接受，则标识该Proposal为批准。
• Learner：最终决策学习者，不参与决策，从Proposers/Acceptors学习最新达成一致的决议（Value）。在具体的实现中，一个进程可能同时充当多种角色。比如一个进程可能既是Proposer又是Acceptor或

Learner。Proposer负责提出提案，Acceptor负责对提案作出裁决（accept与否），Learner负责学习提案结果，Acceptor告诉Learner哪个value被选定，Learner则无条件认为相应的value被选定。

为了避免单点故障，会有一个Acceptor集合群，Proposer向Acceptor集合群发送提案，Acceptor集合群中，只有一半以上的成员同意了这个提案（Proposal），就认为该提案被接受选定了。

1.4.2 选主过程剖析（基于FastLeaderElection算法）

1. 第一步（初始化投票）

2. 第二步更新投票信息

3. 第三步确定集群角色

1.4.3 FOLLOW重启选举剖析

如果FOLLOW跟随者节点出现问题重启之后， 是如何实现重新选举？

第一步：

第二步：

1.4.4 LEADER重启选举剖析

Leader如果重启之后该如何选举？

第一步：

第二步：

第三步：

第四步：

1.5 ZK一致性与同步原理

1.5.1 CAP定理

CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partitiontolerance（分区容错性）这三个基本需求，最多只能同时满足其中的2个。

• Consistency（一致性）: 多个副本节点保持数据的一致性。
• Availability（可用性）： 指系统一直处于可用的状态。
• Partition Tolerance（分区容错性）： 遇到任何网络分区故障， 仍然能够保证对外提供满足一致性和可用性的服务

ZK为什么不能满足可用性呢？

集群中网络出现分割的故障，ZK将他们从自己的管理范围内踢出去， 外界就不能访问这个节点.

ZK在什么情况下是不能保证可用呢？

ZK在进行leade选举时， 集群都是不可用的状态。选举leader的期间， 持续的时间短的话是数百毫秒， 长的话持续数秒。客户端加入重试机制来做补偿。

1.5.2 ZAB协议解析

ZAB协议概述

ZAB （Atomic Broadcast Protocol）协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。

ZAB与PAXOS的联系与区别

Paxos算法的目的在于设计分布式的一致性状态机系统。

ZAB协议的设计目的在于分布式的高可用数据主备系统。

ZAB借鉴了Paxos算法，做了相应的改进，ZAB协议除了遵从Paxos算法中的读阶段和写阶段，还有加入了同步阶段。

ZAB协议两个过程：

ZAB 协议主要包括两个过程: 消息广播和崩溃恢复。和三个阶段: 分为Discovery 发现，Synchronization 同步，Broadcast 广播。

消息广播过程

Leader 节点接受事务提交，并且将新的 Proposal 请求广播给 Follower 节点，收集各个节点的反馈，决定是否进行 Commit。

崩溃恢复过程

如果在同步过程中出现 Leader 节点宕机，会进入崩溃恢复阶段，重新进行 Leader 选举，崩溃恢复阶段还包含数据同步操作，同步集群中最新的数据，保持集群的数据一致性。