zookeeper

先说 Paxos，它是一个基于消息传递的一致性算法，Leslie Lamport 在 1990 年提出，近几年被广泛应用于分布式计算中，Google 的 Chubby，Apache 的 Zookeeper 都是基于它的理论来实现的，pxos 还被认为是到目前为1唯一的分布式一性算法，其它的算法都是 Paxos的改进或简化。有个问题要提一下，Paxos 有一个前提: 没有拜占庭将军问题。就是说 Paxos只有在一个可信的计算环境中才能成立，这个环境是不会被入侵所破坏的。
关于 Paxos 的具体描述可以在 Wiki 中找到: http://zh.wikipedia.org/zh-cn/Paxos 算法。网上关于 Paxos 分析的文章也很多。这里希望用最简单的方式加以描述并建立起 Paxos 和 ZKServer 的对应关系。
Paxos 描述了这样一个场景，有一个叫做 Paxos 的小岛(sland)上面住了一批居民，岛上面所有的事情由一些特殊的人决定，他们叫做议员(Senator)。议员的总数(Senator Count)是确定的，不能更改。岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有-个编号(PID)，这个编号是一直增长的，不能倒退。每个提议都需要超过半数((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 元/度。结果 S 先收到了S1 的提议，于是他做了和前面同样的操作。紧接着他又收到了 S2 的提议，结果他一查记事本，咦，这个提议的编号小于等于我的当前编号 1，于是他拒绝了这个提议:对不起，这个提议先前提过了。于是 S2 的提议被拒绝，S1 正式发布了提议:1 号提议生效S2 S1 或者 3 打听并更新了1号法令的内容，然后他可以选择继续发起 2 号提议。

好，Paxos 的精华就这么多内容。现在让我们来对号入座，看看在 ZK Server 里面 Paxos是如何得以贯彻实施的。
小岛(lsland)--ZK Server Cluster
议员(Senator)--2K Server
提议(Proposal)--ZNode Change(Create/Delete/SetData...)
提议编号(PID)--Zxid(ZooKeeper Transaction ld)
正式法令--所有 ZNode 及其数据
貌似关键的概念都能一一对应上,但是等一下,Paxos 岛上的议员应该是人人平等的吧，而ZKServer 好像有一个Leader 的概念。没错其实 Leader 的概念也应该属于 Paxos 范畴的。如果议员人人平等，在某种情况下会由于提议的冲突而产生一个“活锁”(所谓活锁我的理解正式法令--所有ZNode 及其数据
貌似关键的概念都能一对应上，但是等一下Pxs 岛上的议员应该是人人平等的吧而ZKServer好像有一个Leader 的概念，没错其实 Leader 的概念也应该属FPaxos 范晰的如果议员人人平等，在某种情况下会由于提议的冲突而产生一个“活锁”(所谓活锁我的理解是大家都没有死，都在动，但是一直解决不了冲突闻题)。Paxos 的作者 Lampot 在他的文常”The Part-Time Parliment“中阐述了这个间非给出了解决方案-一在所有议员中设立个总统，只有总统有权发出提议，如果议员有自己的提议，必须发给总统并山总统来提出。好，我们又多了一个角色:总统。
总统--ZK Server Leader
义一个问题产生了，总统怎么选出来的?现在我们假设总统已经选好了，下面看看 ZK Server 是怎么实施的
情况一:
屁民甲(Client)到装个议员(ZKServer)那果询间(Get)某条法令的情况(ZNode 的数)，议员毫不犹段的拿出他的记事本(local storage)，查阅法令并告诉他结果，同时声明:我的数据不定是最新的。你想要最新的数据? 没问题，等着，等我找总统 Snc一下再告诉你.
情况二:
屁民Z(Client)到某个议员(ZK Server)那里要求政府归还欠他的一万元钱，议员让他在办公室等着，自己将间题反映给了总统，总统询向所有议员的意见，多数议员表示欠屁民的钱定要还，于是总统发表声明，从国库中拿出一万元还债，国库总资“由 100 万变成99 万。屁民乙章到钱回夫了(Client 随数返回)。
情况三:
总统突然挂了，议员接二连三的发现联系不上总统，于是各自发表声明,推选新的总统，总统大选期间政府停业，拒绝屁民的请求。
到此为止，当然还有很多其他的情况，但这些情况总是能在 axos 的算法中找到原型并加以解决。这也正是我们认为 Paxos 是 Zookeeper 的灵魂的原因。当然 ZK Server 还有很多属于自己特性的东西: Session,Watcher，Version 等等等等，需要我们花更多的时间去研究和学习。

为什么使用zookeeper

大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进程(如资源、任务分配等)
目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器ZooKeeper:提供通用的分布式锁服务，用以协调分布式应用。 Keepalived监控节点不好管理
Keepalive采用优先级监控
没有协同工作
功能单一
Keepalive可扩展性差

工作原理

每个Server在内存中存储了一份数据2.Zookeeper启动时，将从实例中选举一个leader ( Paxos)3.Leader负责处理数据更新等操作4.一个更新操作成功，当且仅当大多数Server在内存中成功修改数据。

参数解释

tickTime:发送心跳的间隔时间I单位:毫秒
dataDir:zookeeper保存数据的目录。
clientPort: 客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。
initLimit:这个配置项是用来配置 Zookeeper 接受客户端(这里所说的客户端不是用户连接Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的Follower 服务器)初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 5 个心跳的时间(也就是 tickTime)长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒
syncLimit:这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的时间长度，总的时间长度就是 2*2000=4秒server.A=B:C:D:其中A是一个数字，表示这个是第几号服务器;B 是这个服务器的ip地址;C表示的是这个服务器与集群中的 Leader 服务器交换信息的端口;D表示的是万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于B都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号

服务器角色

领导者 (leader)，负责进行投票的发起和决议，更新系统状态
学习者 (learner)，包括跟随者 (follower) 和观察者(observer)，follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
U
》客户端(client)，请求发起方

Zookeeper的核心是原子广播,这个机制保证了各个Server之间的同步。

实现这个机制的协议叫做Zab协议。

Zab协议有两种模式，它们分别是恢复模式( 选主)和广播模式( 同步 。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后恢复模式就结束了。

状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号( zxid ) 来标识事务。所有的提议(proposal)都在被提出的时候加上了zxid，实现中zxid是一个64位的数字，它高32位是epoch用来标识eader关系是否改变，每次一个eader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
每个Server在工作过程中有三种状态:
LOOKING:当前Server不知道leader是谁，正在搜寻
LEADING:当前Server即为选举出来的leader
FOLLOWING :leader已经选举出来，当前Server与之同步