Zookeeper理解
1 Zookeeper介绍Zookeeper是一个开源分布式应用协调服务。
简单来说，zookeeper = 通知机制 + 文件系统
zookeeper 为什么是奇数
zookeeper有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。也就是说如果有2个zookeeper，那么只要有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1。
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
1.1 主要角色
来自服务器端的
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
>> 领导者（leader），负责进行投票的发起和决议，更新系统状态（数据同步），发送心跳。
>> 学习者（learner），包括跟随者（follower）和观察者（observer）。
>> 跟随者（follower），用于接受客户端请求、向客户端返回结果，在选主过程中参与投票。
>> 观察者（Observer），可以接受客户端请求，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度。
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
1）leader失效后会在follower中重新选举新的leader
2）每个follower都和leader有连接，接受leader的数据更新操作
3）客户端可以连接到每个server，每个server的数据完全相同
4）每个节点的服务Server，记录事务日志和快照到持久存储
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
1.2 工作原理
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，恢复模式不接受客户端请求，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
1.2.1 Zookeeper节点数据操作流程
1）写操作
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
发起提案 proposal
quorum 法定人数
1）在Client向Follwer 或 Observer 发出一个写的请求；
2）Follwer 或 Observer 把请求发送给Leader；
3）Leader接收到以后向所有follower发起提案；
4）Follwer收到提案后执行写操作，然后把操作结果发送给Leader；
5）当多数follower返回提案结果后，leader会commit该提议，通知其他Follower 和 Observer 同步信息；
6）Follwer 或Observer把请求结果返回给Client。
2）读操作
1）在Client向Follwer 或 Observer 发出一个读的请求；
2）Follwer 或 Observer 把请求结果返回给Client；
1.3 数据模型
1）ZooKeeper本质上是一个分布式的小文件存储系统；
2）Zookeeper表现为一个分层的文件系统目录树结构（不同于文件系统的是，节点可以有自己的数据，而文件系统中的目录节点只有子节点），每个节点可以存少量的数据。
3）每个节点称做一个ZNode。每个ZNode都可以通过其路径唯一标识。
4）圆形节点可以含有子节点，多边形节点不能含有子节点。一个节点对应一个应用，节点存储的数据就是应用需要的信息，比如HA状态active、standby。
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
1.4 主要特点
最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的特性；
可靠性：具有简单、健壮、良好的性能，如果消息被某一台服务器接受，那么它将被所有的服务器接受；
实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。 但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口；
等待无关(wait-free)：慢的或者失效的client，不得干预快速的client的请求，使得每个client都能有效的等待；
原子性：更新只能成功或者失败，没有中间状态；
顺序性：按照客户端发送请求的顺序更新数据；
1.5 应用场景
数据发布与订阅
应用配置集中到节点上，应用启动时主动获取，并在节点上注册一个watcher，每次配置更新都会通知到应用。
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
发布订阅模式
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
命名空间服务
分布式命名服务，创建一个节点后，节点的路径就是全局唯一的，可以作为全局名称使用。
分布式通知/协调
不同的系统都监听同一个节点，一旦有了更新，另一个系统能够收到通知。
分布式锁
Zookeeper能保证数据的强一致性，用户任何时候都可以相信集群中每个节点的数据都是相同的。一个用户创建一个节点作为锁，另一个用户检测该节点，如果存在，代表别的用户已经锁住，如果不存在，则可以创建一个节点，代表拥有一个锁。
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif[][][]
集群管理
每个加入集群的机器都创建一个节点，写入自己的状态。监控父节点的用户会收到通知，进行相应的处理。离开时删除节点，监控父节点的用户同样会收到通知。
http://blog.运维网.com/static/js/ueditor1.4.3/themes/default/images/spacer.gif
页:
[1]