zookeeper是集群管理工具吗（Zookeeper集群）
ZooKeeper 是什么？
ZooKeeper 是一个开源的分布式协调服务 。它是一个为分布式应用提供一致性服务的软件 。
Zookeeper的用途 ，使用场景
分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅 、负载均衡 、命名服务 、分布式协调/通知 、集群管理 、Master 选举 、分布式锁和分布式队列等功能 。
ZooKeeper 的目标就是封装好复杂易出错的关键服务 ，将简单易用的接口和性能高效 、功能稳定的系统提供给用户 。
zookeeper集群
zookeeper集群架构图
zookeeper集群角色
zookeeper集群角色 角色 描述 领导者（leader） 领导负责投票发起和决议 ，更新集群状态 学习者（Learner） 跟随者（follower） follower用于接收客户端请求并向客户端返回结果 ，参与选举投票 观察者（observer） observer接收客户端连接 ，将请求转给leader ，不参与投票 、只同步leader状态 。存在是为了扩展集群响应速度 客户端（client） 请求发起方zookeeper集群工作原理
Zookeeper的核心是原子广播 ，这个机制保证了各个Server之间的同步 。实现这个机制的协议叫做Zab协议 。
Zab协议有两种模式 ，它们分 别是恢复模式（选主）和广播模式（同步） 。当服务启动或者在领导者崩溃后 ，Zab就进入了恢复模式 ，当领导者被选举出来 ，且大多数Server完成了和 leader的状态同步以后 ，恢复模式就结束了 。恢复模式结束后 ，Zab进入广播模式 ，状态同步保证了leader和Server具有相同的系统状态 。
为了保证事务的顺序一致性 ，zookeeper采用了递增的事务id号（zxid）来标识事务 。所有的提议（proposal）都在被提出的时候加上 了zxid 。实现中zxid是一个64位的数字 ，它高32位是epoch用来标识leader关系是否改变 ，每次一个leader被选出来 ，它都会有一个 新的epoch ，标识当前属于那个leader的统治时期 。低32位用于递增计数 。
每个Server在工作过程中有三种状态：
LOOKING：当前Server不知道leader是谁 ，正在搜寻
LEADING：当前Server即为选举出来的leader
FOLLOWING：leader已经选举出来 ，当前Server与之同步
zookeeper集群选举的原理
半数通过
当leader崩溃或者leader失去大多数的follower ，这时候zk进入恢复模式 ，恢复模式需要重新选举出一个新的leader ，让所有的 Server都恢复到一个正确的状态 。
Zk的选举算法有两种：一种是基于basic paxos实现的 ，另外一种是基于fast paxos算法实现的 。系统默认的选举算法为fast paxos 。
A提案说 ，我要选自己 ，B你同意吗？C你同意吗？B说 ，我同意选A；C说 ，我同意选A 。(注意 ，这里超过半数了 ，其实在现实世界选举已经成功了 。但是计算机世界是很严格 ，另外要理解算法 ，要继续模拟下去 。)
接着B提案说 ，我要选自己 ，A你同意吗；A说 ，我已经超半数同意当选 ，你的提案无效；C说 ，A已经超半数同意当选 ，B提案无效 。
接着C提案说 ，我要选自己 ，A你同意吗；A说 ，我已经超半数同意当选 ，你的提案无效；B说 ，A已经超半数同意当选 ，C的提案无效 。
选举已经产生了Leader ，后面的都是follower ，只能服从Leader的命令 。而且这里还有个小细节 ，就是其实谁先启动谁当头 。
zookeeper watcher机制
Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听 ，当服务端的一些指定事件触发了这个 Watcher ，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能 ，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变 。
工作机制：
（1）客户端注册 watcher
（2）服务端处理 watcher
（3）客户端回调 watcher
Watcher 特性总结：
（1）一次性 无论是服务端还是客户端 ，一旦一个 Watcher 被 触 发 ，Zookeeper 都会将其从相应的存储中移除 。这样的设计有效的减轻了服务端的压力 ，不然对于更新非常频繁的节点 ，服务端会不断的向客户端发送事件通知 ，无论对于网络还是服务端的压力都非常大 。 （2）客户端串行执行 客户端 Watcher 回调的过程是一个串行同步的过程 。（3）轻量
3.1 、Watcher 通知非常简单 ，只会告诉客户端发生了事件 ，而不会说明事件的具体内容 。
3.2 、客户端向服务端注册 Watcher 的时候 ，并不会把客户端真实的 Watcher 对象实体传递到服务端 ，仅仅是在客户端请求中使用 boolean 类型属性进行了标记 。
（4）watcher event 异步发送 watcher 的通知事件从 server 发送到 client 是异步的 ，这就存在一个问题 ，不同的客户端和服务器之间通过 socket 进行通信 ，由于网络延迟或其他因素导致客户端在不通的时刻监听到事件 ，由于 Zookeeper 本身提供了 ordering guarantee ，即客户端监听事件后 ，才会感知它所监视 znode发生了变化 。所以我们使用 Zookeeper 不能期望能够监控到节点每次的变化 。Zookeeper 只能保证最终的一致性 ，而无法保证强一致性 。
（5）注册 watcher getData 、exists 、getChildren
（6）触发 watcher create 、delete 、setData
（7）当一个客户端连接到一个新的服务器上时 ，watch 将会被以任意会话事件触发 。当与一个服务器失去连接的时候 ，是无法接收到 watch 的 。而当 client 重新连接时 ，如果需要的话 ，所有先前注册过的 watch ，都会被重新注册 。通常这是完全透明的 。只有在一个特殊情况下 ，watch 可能会丢失：对于一个未创建的 znode的 exist watch ，如果在客户端断开连接期间被创建了 ，并且随后在客户端连接上之前又删除了 ，这种情况下 ，这个 watch 事件可能会被丢失 。
客户端注册 Watcher
（1）调用 getData()/getChildren()/exist()三个 API ，传入 Watcher 对象
（2）标记请求 request ，封装 Watcher 到 WatchRegistration
（3）封装成 Packet 对象 ，发服务端发送 request
（4）收到服务端响应后 ，将 Watcher 注册到 ZKWatcherManager 中进行管理
（5）请求返回 ，完成注册 。
服务端触发 Watcher
（1）服务端接收 Watcher 并存储
接收到客户端请求 ，处理请求判断是否需要注册 Watcher ，需要的话将数据节点的节点路径和 ServerCnxn（ServerCnxn 代表一个客户端和服务端的连接 ，实现了 Watcher 的 process 接口 ，此时可以看成一个 Watcher 对象）存储在WatcherManager 的 WatchTable 和 watch2Paths 中去。 （2）Watcher 触发
以服务端接收到 setData() 事务请求触发 NodeDataChanged 事件为例：2.1 封装 WatchedEvent
将通知状态（SyncConnected） 、事件类型（NodeDataChanged）以及节点路径封装成一个 WatchedEvent 对象2.2 查询 Watcher
从 WatchTable 中根据节点路径查找 Watcher2.3 没找到；说明没有客户端在该数据节点上注册过 Watcher
2.4 找到；提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher（从这里可以看出 Watcher 在服务端是一次性的 ，触发一次就失效了）
（3）调用 process 方法来触发 Watcher
这里 process 主要就是通过 ServerCnxn 对应的 TCP 连接发送 Watcher 事件通知 。zookeeper宕机处理
Zookeeper 本身也是集群 ，推荐配置不少于 3 个服务器 。Zookeeper 自身也要保证当一个节点宕机时 ，其他节点会继续提供服务 。
如果是一个 Follower 宕机 ，还有 2 台服务器提供访问 ，因为 Zookeeper 上的数据是有多个副本的 ，数据并不会丢失；如果是一个 Leader 宕机 ，Zookeeper 会选举出新的 Leader 。
ZK 集群的机制是只要超过半数的节点正常 ，集群就能正常提供服务 。只有在 ZK节点挂得太多 ，只剩一半或不到一半节点能工作 ，集群才失效 。
所以:
3 个节点的 cluster 可以挂掉 1 个节点(leader 可以得到 2 票>1.5)
2 个节点的 cluster 就不能挂掉任何 1 个节点了(leader 可以得到 1 票<=1)
创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！