为什么使用Zookeeper

Zookeeper是一个分布式的、开源的分布式应用协调服务，从设计角度理解的话：就是观察者模式（简单理解就比如你关注了别人微博，别人发布了一个新消息，你接收到了）设计的分布式服务管理框架。（即管理着一些数据，这些数据发生变化的时候要给观察者提供响应）
目前，大部分应用需要开发私有的一个主控、协调器或控制器的协调程序来管理物理分布的子进程（如资源、任务分配等），但是协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器，所以Zookeeper应用而生
Zookeeper是一个为分布式应用提供一致性服务的软件，提供的服务包括：
统一命名服务、同一配置管理、同一集群管理、服务节点动态上下线，软负载均衡等。
总之，Zookeeper 是分布式应用在其上（Zookeeper）进行注册即可实现集群中的主从管理模式。

Zookeeper中的内部原理

1、选举机制

半数机制：集群中半数以上机器alive则集群可用。所以 zookeeper更适合装在奇数台机器上（容忍度：奇数台和偶数台机器的容忍度是一样的。3:1,4:1）。并且不同于其他框架的主从机制，zookeeper并没有在配置文件中界定leader和follower的具体对象，而是在集群启动的时候通过内部选举的方式临时产生一个leader。
Server一共有如下三种状态：
LOOKING ：当前Server不知道leader是谁，正在搜寻
LEADING ：当前Server即为选举出来的leader
FOLLOWING ：leader已经选举出来，当前Server与之同步

具体leader如何产生看下面这个例子：

1. 服务器 1 启动，此时只有它一台服务器启动了，它发出去的报没有任何响应，所以它的选举状态只能是搜寻其他响应即Looking状态。
2. 服务器 2 启动，它与最开始启动的服务器 1 进行通信，互相交换自己的选举结果，由于两者都没有历史数据即所谓zxid，所以 myid 值较大的服务器 2 胜出，但是由于没有达到超过半数以上（3个）的服务器都同意选举它，所以服务器 1、2 还是继续保持LOOKING 状态。
3. 服务器 3 启动，根据前面的理论分析，服务器 3 成为服务器 1、2、3 中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的临时leader。
4. 服务器 4 启动，根据前面的分析，理论上服务器 4 应该是服务器 1、2、3、4 中最大的，但是由于前面已经有半数以上的服务器选举了服务器 3，所以他也只能当follower了。
5. 服务器 5 启动，同 4 一样当follower了。
   总结两句话：打铁还需自身硬，把握时机很重要。
   Zookeeper——Paxos作为灵魂
   Paxos，它是一个基于消息传递的一致性算法。

Paxos描述了这样一个场景，有一个叫做Paxos的小岛(Island)上面住了一批居民，岛上面所有的事情由一些特殊的人决定，他们叫做议员 (Senator)。议员的总数(Senator Count)是确定的，不能更改。岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有一个编号(PID【也就是zxid】)，这个编号是一直增长的，不能倒退。每个提议都需要超过半数((Senator Count)/2 +1)的议员同意才能生效。每个议员只会同意大于当前编号的提议，包括已生效的和未生效的。如果议员收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编号，他不断更新这个编号。整个议会不能保证所有议员记事本上的编号总是相同的。现在议会有一个目
标：保证所有的议员对于提议都能达成一致的看法。
好，现在议会开始运作，所有议员一开始记事本上面记录的编号都是 0。有一个议员发了一个提议：将电费设定为1元/度。他首先看了一下记事本，嗯，当前提议编号是0，那么我的这个提议的编号就是1，于是他给所有议员发消息：1号提议，设定电费1元/度。其他议员收到消息以后查了一下记事本，
哦，当前提议编号是0，这个提议可接受，于是他记录下这个提议并回复：我接受你的1号提议，同时他在记事本上记录：当前提议编号为1。发起提议的议员收到了超过半数的回复，立即给所有人发通知：1号提议生效！收到的议员会修改他的记事本，将1好提议由记录改成正式的法令，当有人问他电费为多少时，他会查看法令并告诉对方：1元/度。
现在看冲突的解决：假设总共有三个议员S1-S3，S1和S2同时发起了一个提议:1号提议，设定电费。S1想设为1元/度, S2想设为2元/ 度。结果S3先收到了S1的提议，于是他做了和前面同样的操作。紧接着他又收到了S2的提议，结果他一查记事本，咦，这个提议的编号小于等于我的当前编号1，于是他拒绝了这个提议：对不起，这个提议先前提过了。于是S2的提议被拒绝，S1正式发布了提议: 1号提议生效。S2向S1或者S3打听并更新了1号法令的内容，然后他可以选择继续发起2号提议。
好，这就是paxos协议的精华内容。现在让我们来对号入座，看看在ZK Server里面Paxos是如何得以贯彻实施的。
小岛(Island)——ZK Server Cluster
议员(Senator)——ZK Server
提议(Proposal)——ZNode Change(Create/Delete/SetData…)
提议编号(PID)——Zxid(ZooKeeper Transaction Id)
正式法令——所有ZNode及其数据
貌似关键的概念都能一一对应上，但是等一下，Paxos岛上的议员应该是人人平等的吧，而ZK Server好像有一个Leader的概念。没错，其实Leader的概念也应该属于Paxos范畴的。如果议员人人平等，在某种情况下会由于提议的冲突而产生一个“活锁”（所谓活锁我的理解是大家都没有死，都在动，但是一直
解决不了冲突问题）。Paxos的作者Lamport在他的文章”The Part-Time Parliament“中阐述了这个问题并给出了解决方案——在所有议员中设立一个总统，只有总统有权发出提议，如果议员有自己的提议，必须发给总统并由总统来提出。好，我们又多了一个角色：总统。
总统——ZK Server Leader

又一个问题产生了，总统怎么选出来的？也就是内部的选举机制
现在我们假设总统已经选好了，下面看看ZK Server是怎么实施的。
屁民甲(Client)到某个议员(ZK Server)那里询问(Get)某条法令的情况 (ZNode的数据)，议员毫不犹豫的拿出他的记事本(local storage)，查阅法令并告诉他结果，同时声明：我的数据不一定是最新的。你想要最新的数据？没问题，等着，等我找总统Sync一下再告诉你。

paxos算法

角色

广播机制

1.首先每个zkServer在内存中存储了一份数据（小）；
2.Zookeeper启动时，将从实例中选举一个leader（Paxos协议）
3.Leader负责处理数据更新等操作
4.一个更新操作成功时机当且仅当大多数Server在内存中成功修改数据。
Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式，它们分别是恢复模式和广播模式。
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状
态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持。
广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态。

特点	说明
最终一致性	为客户端展示同一个视图，这是zookeeper里面一个非常重要的功能。
可靠性	如果消息被到一台服务器接受，那么它将被所有的服务器接受。
实时性	在一定时间范围内，client 能读到最新数据，如果需要最新数据，应该在读数据之前调用 sync()接口。
独立性	各个Client之间互不干预
原子性	更新只能成功或者失败，没有中间状态。
顺序性	顺序性所有Server，同一消息发布顺序一致。

这就是欲攘外必先安内，只有自己内部消息安全可靠（ 选举模式选出leader才能对外服务），在对外提供服务的时候才能有一个统一的视图即能对外提供正确的服务（ 广播模式完成消息的同步）。节点故障也不担心，只需要满足过半机制也不会出现脑裂问题。
在zookeeper这样一个主从模型之下，leader和follower之间也组成一写多读。即Leader 负责进行投票的发起和决议，更新系统状态而Follower 用于接收客户请求并向客户端返回结果，并在选举 Leader 过程中参与投票。

Znode–数据模型

zookeeper的目录结构与 Unix 文件系统很类似，整体上可以看作是一棵树，这一个树形结构由zookeeper 集群自身维护，其上的每一个节点，我们称之为"znode"，各自的路径作为节点的唯一标识。
znode的类型
短暂（ephemeral）
客户端和服务器端断开连接后，创建的节点znode自动删除。
持久（persistent）
客户端和服务器端断开连接后，创建的节点znode不会自动删除。