Zookeeper

1. Zookeeper基本概念
- 1.1 Zookeeper概述
- 1.2 Zookeeper集群角色
- 1.3 Zookeeper特性
2. Zookeeper 数据类型
- 2.1 Zookeeper与文件系统的对比
- 2.2 数据结构图
- 2.3 节点类型
- 2.4 节点属性
3. 集群模式的Zookeeper
- 3.1 Zookeeper的启动与客户端连接
- 3.2 客户端shell的基本操作
4. Zookeeper 特点
- 4.1 Watch机制特征
- 4.2 数据发布/订阅
- 4.3 提供集群选举
- - 4.3.1 全新集群选举
  - 4.3.2 非全新集群选举
5. Paxos算法
- Zookeeper选举机制就是基于Paxos算法的！！！
- 5.1 Paxos算法中角色
- 5.2 Proposer生成提案
- 5.3 Acceptor接受提案
- 5.4 Learner学习被选定的value
- 5.5 算法描述
- 5.6 保证Paxos算法的活性（避免进入提案死循环）

只有弱者会逞强，只有强者懂示弱。刻薄因为底子薄，尖酸因为心里酸。

1. Zookeeper基本概念

1.1 Zookeeper概述

Zookeeper是一个分布式协调服务的开源框架。主要用来解决分布式集群中应用系统的一致性问题。

ZooKeeper本质上是一个分布式的小文件存储系统。提供类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。

1.2 Zookeeper集群角色

Leader
Zookeeper集群工作的核心，事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性；集群内部各个服务器的调度者。对于 create，set，delete等有写操作的请求，则需要统一转发给leader处理，leader需要决定编号、执行操作，这个过程称为一个事务。
Follower
处理客户端非事务（读操作）请求，转发事务请求给Leader；参与集群Leader选举投票。
Observer
观察者角色，观察Zookeeper集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给Leader服务器进行处理。不参与任何形式的投票只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。

1.3 Zookeeper特性

全局数据一致： 集群中每个服务器保存一份相同的数据副本，client无论连接到哪个服务器，展示的数据都是一致的，这是最重要的特征；
可靠性： 如果消息被其中一台服务器接受，那么将被所有的服务器接受。
顺序性： 包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
数据更新原子性： 一次数据更新要么成功（半数以上节点成功），要么失败，不存在中间状态；
实时性： Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

2. Zookeeper 数据类型

2.1 Zookeeper与文件系统的对比

ZooKeeper与标准文件系统的相似处：

拥有一个层次的命名空间，都是采用树形层次结构，ZooKeeper树中的每个节点被称为—Znode。
和文件系统的目录树一样，ZooKeeper树中的每个节点可以拥有子节点。

ZooKeeper与标准文件系统的不同处：

Znode兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL（Access Control List，访问控制表）、时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有子Znode。用户对Znode具有增、删、改、查等操作（权限允许的情况下）。
Znode具有原子性操作，读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。
Znode存储数据大小有限制。ZooKeeper虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以KB为大小单位。ZooKeeper的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小至多1M，当时常规使用中应该远小于此值。
Znode通过路径引用，如同Unix中的文件路径。路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。在ZooKeeper中，路径由Unicode字符串组成，并且有一些限制。字符串"/zookeeper"用以保存管理信息，比如关键配额信息。

2.2 数据结构图

2.3 节点类型

Znode分为以下四种：

永久节点： 这个节点被创建之后，永久存在。除非手动删除。
永久顺序节点（永久序列化节点）： 这个节点被创建之后，永久存在，创建出来的时候，会在节点名字的后面加上一串数字，这个数字的大小表示了创建节点的先后顺序。数字越大，表示越新的数据。
临时节点： 这个节点被创建出来，生命周期依赖于当前的会话。当会话结束的时候，临时节点就会被删除。临时节点下，不能再有子节点。
临时顺序节点（临时序列化节点）： 这个节点被创建出来，生命周期依赖于当前的会话。当会话结束的时候，临时节点就会被删除。创建出来的时候，会在节点名字的后面加上一串数字，这个数据的大小。表示了创建节点的先后顺序。数字越大，表示越新的数据。

2.4 节点属性

通过命令get，可以获得节点的属性

节点属性名	解释
cZxid	Znode创建的事务id
ctime	节点创建时的时间戳.
mZxid	Znode被修改的事务id，即每次对Znode的修改都会更新mZxid
mtime	节点最新一次更新发生时的时间戳
pZxid
cversion	子节点的版本号。当znode的子节点有变化时，cversion 的值就会增加1
dataVersion	数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题
aclVersion
ephemeralOwner	如果该节点为临时节点, ephemeralOwner值表示与该节点绑定的session id. 如果不是, ephemeralOwner值为0.
dataLength	节点存的数据的长度
numChildren	该节点下的孩子节点个数（不递归计算）

对于zk来说，每次的变化都会产生一个唯一的事务id，mzxid（ZooKeeper Transaction Id）。通过mzxid，可以确定更新操作的先后顺序。例如，如果mzxid1小于mzxid2，说明mzxid1操作先于mzxid2发生，mzxid对于整个zk都是唯一的，即使操作的是不同的Znode。

在client和server通信之前,首先需要建立连接,该连接称为session。连接建立后,如果发生连接超时、授权失败,或者显式关闭连接,连接便处于CLOSED状态, 此时session结束，这时候临时节点就会消失。

3. 集群模式的Zookeeper

3.1 Zookeeper的启动与客户端连接

myid的路径：（你安装的路径）zkdata/myid

3.2 客户端shell的基本操作

help 可以查看 zk shell 中的命令

创建节点 create
查看节点数据
ls命令可以列出Zookeeper指定节点下的所有子节点，只能查看指定节点下的第一级的所有子节点；
get命令可以获取Zookeeper指定节点的数据内容和属性信息
更新节点
删除节点
监听

4. Zookeeper 特点

4.1 Watch机制特征


一次性触发	事件发生触发监听，一个watcher event就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发
事件封装	ZooKeeper使用WatchedEvent对象来封装服务端事件并传递。WatchedEvent包含了每一个事件的三个基本属性：通知状态（keeperState），事件类型（EventType）和节点路径（path）
event异步发送	watcher的通知事件从服务端发送到客户端是异步的
先注册再触发	Zookeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端

4.2 数据发布/订阅

ZooKeeper提供了分布式数据发布/订阅功能，即所谓的配置中心，一个典型的发布/订阅模型系统定义了一种一对多的订阅关系，能让多个订阅者同时监听某一个对象，当这个对象自身状态变化时，会通知所有订阅者。ZooKeeper中引入了Watcher机制来实现这种分布式的通知功能。总的来说可以概括为以下三个过程：客户端向服务端注册Watcher、服务端事件发生触发Watcher、客户端回调Watcher得到触发事件情况 。触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等。发布者将数据发布到ZooKeeper的一个节点上，通过数据发布/订阅功能，从而实现动态更新数据的目的，实现配置信息的集中式管理和数据的动态更新。

4.3 提供集群选举

选举过程中， ZooKeeper 服务器有 4 种状态，它们分别为


竞选状态（locking）	随从状态(following,同步leader状态,参与投票 )
观察状态(observing,同步leader状态,不参与投票)	领导者状态(leading)

数据 ID：这是服务器中存放的最新数据版本号，该值越大说明数据越新，在选举过程中数据越新权重越大。

逻辑时钟：通俗地讲，逻辑时钟被称为投票次数，同一轮投票过程中的逻辑时钟值是相同的，逻辑时钟起始值为 0 ，每投完一次票，这个数据就会增加。如果某台机器宕机，那么这台机器不会参与投票，因此逻辑时钟也会比其他的低。

ZooKeeper 选举机制有两种类型，分别为全新集群选举和非全新集群选举：

简单来说：
全新集群选举就是第一次启动zk服务：	每台主机中zk服务在启动起来的时候，都会给自己投上一票，投票之后还会和其他的机器进行沟通投票的情况，一旦参与投票的机器数据过半，对比每台机器的 myid，谁的myid大，谁是leader
非全新集群选举就是服务器挂了的时候，要重新选leader：	先去做判断，剩余的机器是否过半，如果不过半，整个集群服务挂了。剩余的机器数量过半。先去判断谁的数据是最新的，最新的那台机器作为leader。如果数据都是最新的，比较 myid，谁的myid大，谁就是leader

4.3.1 全新集群选举

假设，目前有 5 台服务器，它们的编号分别是1 ~ 5 ，同时他们的myid也为1 ~ 5，按编号依次启动 ZooKeeper 服务。

服务器 1 启动，首先会给自己投票。其次发投票信息，由于其他机器还没有启动所以它无法接收到投票的反馈信息，因此服务器 1 处于 locking 状态。
服务器 2 启动，首先会给自己投票。其次在集群中启动 ZooKeeper 服务的机器发起投票对比，这时它会与服务器 1 交换结果，由于服务器 2 的myid大，所以服务器 2 胜出，此时服务器 1 会将票投给服务器 2 ，但服务器2票数并小于集群半数(票数 2< 5/2 )，所以两个服务器依旧处于是locking状态。
服务器 3 启动，首先会给自己投票。其次与之前启动的服务器 1 和服务器 2 交换信息，由于服务器 3 的myid最大，所以服务器 3 胜出，那么服务器 1 和 2 会将票投给服务器 3 ，此时服务器3票数大于半数( 票数 3 > 5/2 )，所以服务器 3 成为 leader状态，服务器 1 和 2 成为follower状态。
服务器 4 启动，首先给自己投票。其次与之前启动的服务器 1 、 2 和 3 交换信息，尽管服务器 4 的myid大，但是服务器 3 已经胜出。所以服务器 4 只能成为follower状态。
服务器 5 启动，同服务器 4 一样，均成为follower状态。

4.3.2 非全新集群选举

对于正常运行的 ZooKeeper 集群，一且中途有服务器宕机，则需要重新选举时，选举的过程中就需要引入服务器 ID 、数据 ID 和逻辑时钟。这是由于 ZooKeeper 集群已经运行过段时间，那么服务器中就会存在运行的数据。

首先，统计逻辑时钟是否相同，逻辑时钟小，则说明途中可能存在宕机问题，因此数据不完整,那么该选举结果被忽略，重新投票选举
其次，统一逻辑时钟后，对比数据ID值，数据ID反应数据的新旧程度，因此数据ID大的胜出
最后，如果逻辑时钟和数据ID都相同的情况下(通常情况下都是满足)，那么比较myid值大则胜出

简单地讲,非全新集群选举时是优中选优,保证 Leader 是 ZooKeeper 集群中数据最完整、最可靠的一台服务器。

5. Paxos算法

Zookeeper选举机制就是基于Paxos算法的！！！

Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。（个人认为可以去掉之一）
详细了解Paxos算法，请看这位大佬的，本块内容借鉴于此

5.1 Paxos算法中角色

Proposer ：
只要Proposer发的提案被Acceptor接受（刚开始先认为只需要一个Acceptor接受即可，在推导过程中会发现需要半数以上的Acceptor同意才行），Proposer就认为该提案里的value被选定了
Acceptor ：
只要Acceptor接受了某个提案，Acceptor就任务该提案里的value被选定了
Learners ：
Acceptor告诉Learner哪个value被选定，Learner就认为那个value被选定

具体实现中，一个进程可能同时充当多个角色。比如一个进程可能既是Proposer又是Acceptor又是Learner。

5.2 Proposer生成提案

提案生成算法：

Proposer选择一个新的提案编号N，然后向某个Acceptor集合（半数以上）发送请求，要求该集合中的每个Acceptor做出如下响应（response）。


a. 向Proposer承诺保证不再接受任何编号小于N的提案。
b. 如果Acceptor已经接受过提案，那么就向Proposer 响应已经接受过的编号小于N的最大编号的提案。

我们将该请求称为编号为N的Prepare请求。

如果Proposer收到了半数以上的Acceptor的响应，那么它就可以生成编号为N，Value为V的提案[N,V]。这里的V是所有的响应中编号最大的提案的Value。如果所有的响应中都没有提案，那么此时V就可以由Proposer 自己选择。
生成提案后，Proposer将该提案发送给半数以上的Acceptor集合，并期望这些Acceptor能接受该提案。我们称该请求为Accept请求。（注意：此时接受Accept请求的Acceptor集合不一定是之前响应Prepare请求的Acceptor集合）

5.3 Acceptor接受提案

Acceptor可以忽略任何请求（包括Prepare请求和Accept请求）而不用担心破坏算法的安全性。
如果Acceptor收到一个编号为N的Prepare请求，在此之前它已经响应过编号大于N的Prepare请求。则该Acceptor 忽略编号为N的提案。当然，也可以回复一个error，让Proposer尽早知道自己的提案不会被接受。

因此，一个Acceptor只需记住：1. 接受编号大于（已接受提案中的最大编号）的提案，同时响应给Proposer已接受过中编号最大的提案（如果有）2.忽略编号小于（已接受提案中的最大编号）

5.4 Learner学习被选定的value

Learner学习（获取）被选定的value有如下三种方案：

5.5 算法描述

Paxos算法分为两个阶段。具体如下：

阶段一：
a. Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求
b. 如果一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的所有Prepare请求的编号，那么它就会将它已接受过的编号最大的提案（如果有的话）作为响应反馈给Proposer，同时该Acceptor承诺不再接受任何编号小于N的提案
阶段二：
a. 如果Proposer 收到半数以上 Acceptor对其发出的编号为N的 Prepare请求的响应，那么它就会发送一个针对 [N,V]提案的Accept请求给半数以上的Acceptor。注意：V就是收到的响应中编号最大的提案的value，如果响应中不包含任何提案，那么V就由Proposer 自己决定
b. 如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor 没有对编号大于N的Prepare请求做出过响应，它就接受该提案

5.6 保证Paxos算法的活性（避免进入提案死循环）

通过选取主Proposer，就可以保证Paxos算法的活性，这样得到一个既能保证安全性，又能保证活性的Paxos算法

深入浅出Zookeeper特性以及Paxos算法相关推荐

Zookeeper--ZAB与Paxos算法联系与区别
ZAB与Paxos算法的联系与区别两者联系两者都存在一个类似于Leader的进程角色,由其负责协调多个Follower进程的运行 Leader进程会等待超过半数的Follower做出正确的反馈后, ...
Paxos算法之旅（四）zookeeper代码解析--转载
ZooKeeper是近期比较热门的一个类Paxos实现.也是一个逐渐得到广泛应用的开源的分布式锁服务实现.被认为是Chubby的开源版,虽然具体实现有很多差异.ZooKeeper概要的介绍可以看官方文 ...
Zookeeper笔记（二）Paxos算法与Zookeeper的工作原理
Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目, 它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务.状态同步服务.集群管理.分布式应用配置项的管 ...
深入浅出理解Paxos算法
Paxos算法是莱斯利·兰伯特(英语:Leslie Lamport,LaTeX中的「La」)于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法. Paxos算法一开始非常难以理解,但是一 ...
Paxos算法与Zookeeper分析
1 Paxos算法 1.1 基本定义算法中的参与者主要分为三个角色,同时每个参与者又可兼领多个角色: ⑴proposer 提出提案,提案信息包括提案编号和提议的value; ⑵acceptor 收到 ...
Zookeeper与paxos算法
一. zookeeper是什么官方说辞:Zookeeper 分布式服务框架是Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如 ...
Zookeeper Paxos算法一致性协议
前言 Paxos 一致性协议可以说是一致性协议研究的起点,也以难以理解闻名.其实协议本身并没有多难理解,它的难理解性主要体现在:为何如此设计协议以及如何证明其正确性.本文尝试通过流程图来说明协议的内容 ...
微信PaxosStore：深入浅出Paxos算法协议
引言早在1990年,Leslie Lamport(即 LaTeX 中的"La",微软研究院科学家,获得2013年图灵奖)向ACM Transactions on Computer ...
Zookeeper的Paxos算法，（2P/3P/CAP/BASE）一致性协议简单介绍
2P/3P提交(为了保证事务的ACID) 2P 就是二段提交(RDBMS经常就这种机制,保证强一致性),3P就是三段提交: 2P提交 -- 1阶段:提交事务请求(投票阶段) ...

深入浅出Zookeeper特性以及Paxos算法