目录
1 zookeeper简介
zookeeper：动物管理员
zookeeper是分布式应用程序的协调服务框架 是Hadoop的重要组件 zookeeper是Google的chubby一个开源实现 是Hadoop的分布式协调服务
2 zookeeper具体应用场景
1.Hadoop 使用zookeeper的事件处理确保整个集群只有一个NameNode 存储配置信息等
2.Hbase 使用zookeeper的事件处理确保整个集群只有一个HMaster 察觉HRegionServer联机和宕机 存储访问控制列表等
3.分布式环境下的统一命名服务
4.分布式环境下的配置管理
5.数据发布/订阅
6.分布式环境下的分布式锁
7.集群管理问题
3 分布式编程容易出现的问题
分布式编程的思想：人多干活快 即多台机器同时处理一个任务
1.活锁 在程序里 由于某些条件的发生碰撞 导致重新执行 再碰撞 再执行 如此循环重新 就形成了活锁
2.需要考虑集群的管理问题 需要有一套机制来检测到集群节点的状态变化
3.如果用一台机器做集群管理 存在单点故障问题 所以针对集群管理 也需要形成一个集群
4.管理集群里Leader的选举问题（根据一定的算法和规则来选举） 包括要考虑Leader挂掉之后 如何从剩余的follower里选举出Leader
5.分布式锁的实现
4 集群架构剖析
4.1 zookeeper之攘其外
zookeeper服务端有两种不同的运行模式。单机的称为”独立模式“，但是独立模式存在单点故障的问题，所以在实际开发中很少使用；集群的称为仲裁模式，不存在单点故障问题，实际开发中使用较多。
主从架构：Master + Slave
1.客户联系某一个柜员说要存钱
2.柜员告知Leader说客户要存钱
3.Leader发起投票，通知其他四个柜员，现在有人要存钱，允不允许他往里存
4.柜员收到后 允许存钱 反馈给领导
5.领导看到反馈允许存钱 给柜员发通知 进行存钱操作 更新一下客户的账户余额数据
对外视图统一 叫攘其外
4.2 zookeeper之安其内
1.leader很重要 如果挂了怎么办
开始选举新的leader
2.zookeeper服务器的四种状态
looking：服务器处于寻找leader群首的状态
leading：服务器作为群首时的状态
following：服务器作为follower跟随者时的状态
observing：服务器作为观察者时的状态
3.集群启动时的leader选举
以三台机器组成的zookeeper集群为例
原则：集群中过半server启动后，才能选举出leader
每个server投票信息vote信息结构为（sid，zxid）
server1~3初始投票信息分别为：
server1 -> (1, 0)
server2 -> (2, 0)
server3 -> (3, 0)
leader选举公式：
server1 (sid1, zxid1)
server2 (sid2, zxid2)
zxid大的server胜出；若zxid相等，再根据判断sid判断，sid大的胜出
4.集群运行时新leader的选举
4.3 脑裂和服务器数量选取
1.服务器数量选取
ZK集群的服务器的数量通常为奇数台（3，5，7，9）
2.脑裂
