Zookeeper框架结构
ZooKeeper框架结构
Zookeeper是一个分布式协调服务的开源框架。主要用来解决分布式集群中应用系统的一致性问题。
Zookeeper本质上是一个分布式的小文件系统。
Zookeeper提供给客户端监控存储在zk内部数据的功能。
提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档
文章目录
- ZooKeeper框架结构
- 一、Zookeeper的架构组成
-
- Leader
- Follower
- Observer
- 二、Zookeeper数据结构与监听机制
-
- 1.zookeeper数据模型Znode
- 2.Watcher机制
- 三.Zookeeper内部原理
-
- 1.Leader选举
- 2.ZAB一致性协议 (Zookeeper原⼦消息⼴播协议)
- 3.Leader崩溃问题
- 四. HDFS-HA工作机制
一、Zookeeper的架构组成
Leader
Zookeeper集群工作的核心角色
集群内部各个服务器的调度者
事务请求（写操作）的唯一调度和处理者，保证集群处理的顺序性
Follower
处理客户端非事务（读操作）请求
转发事务请求给Leader
参与集群Leader选举投票2n-1台可以做集群投票
Observer
观察者角色，观察ZooKeeper集群的最新状态变化并将这些状态同步过来，其对于⾮事务请求可以进⾏ᇿ⽴处理，对于事务请求，则会转发给 Leader服务器进⾏处理。
不会参与任何形式的投票只提供⾮事务服务，通常⽤于在不影响集群事务处理能⼒的前提下提升集群的⾮事务处理能⼒。增加了集群增加并发的读请求
二、Zookeeper数据结构与监听机制
1.zookeeper数据模型Znode
ZNode 是Zookeeper 中最⼩数据单位，在 ZNode 下⾯⼜可以再挂 ZNode，这样⼀层层下去就形成了⼀个层次化命名空间 ZNode 树，我们称为 ZNode Tree，它采⽤了类似⽂件系统的层级树状结构进⾏管理。
Zookeeper 节点类型可以分为三⼤类：持久性节点（Persistent）临时性节点（Ephemeral）顺序性节点（Sequential）
持久节点：是Zookeeper中最常⻅的⼀种节点类型，所谓持久节点，就是指节点被创建后会⼀直存在服务器，直到删除操作主动清除
持久顺序节点：就是有顺序的持久节点，节点特性和持久节点是⼀样的，只是额外特性表现在顺序上。顺序特性实质是在创建节点的时候，会在节点名后⾯加上⼀个数字后缀，来表示其顺序。
临时节点：就是会被⾃动清理掉的节点，它的⽣命周期和客户端会话绑在⼀起，客户端会话结束，节点会被删除掉。与持久性节点不同的是，临时节点不能创建⼦节点。
临时顺序节点：就是有顺序的临时节点，和持久顺序节点相同，在其创建的时候会在名字后⾯加上数字后缀。
2.Watcher机制
Zookeeper使⽤Watcher机制实现分布式数据的发布/订阅功能。
Zookeeper的Watcher机制主要包括客户端线程，客户端WatcherManager,Zookeeper服务器三部分。
具体流程为：
客户端在向Zookeeper服务器注册的同时，会将Watcher对象存储在客户端的WatcherManager当中
当Zookeeper服务器触发Watcher事件后，会向客户端发送通知
客户端线程从WatcherManager中取出对应的Watcher对象来执行回调逻辑。
三.Zookeeper内部原理
1.Leader选举
半数机制：集群中半数以上机器存活，集群可⽤。所以Zookeeper适合安装奇数台服务器。
Zookeeper虽然在配置⽂件中并没有指定Master和Slave。但是，Zookeeper⼯作时，是有⼀个节点为Leader，其它为Follower，Leader是通过内部的选举机制产⽣的。
Zookeeper的选举机制
首次启动
（1）服务器1启动，此时只有它⼀台服务器启动了，它发出去的报⽂没有任何响应，所以它的选举状态⼀直是LOOKING状态。
（2）服务器2启动，它与最开始启动的服务器1进⾏通信，互相交换⾃⼰的选举结果，由于两者都没有历史数据，所以id值较⼤的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例⼦中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。
（3）服务器3启动，根据前⾯的理论分析，服务器3成为服务器1、2、3中的⽼⼤，⽽与上⾯不同的是，此时有三台服务器选举了它，所以它成为了这次选举的Leader。
（4）服务器4启动，根据前⾯的分析，理论上服务器4应该是服务器1、2、3、4中最⼤的，但是由于前⾯已经有半数以上的服务器选举了服务器3，所以它只能接收当⼩弟的命了。
（5）服务器5启动，同4⼀样称为follower。
集群⾮⾸次启动
(1)每个节点在选举时都会参考⾃身节点的zxid值（事务ID）；优先选择zxid值⼤的节点称为Leader!!
2.ZAB一致性协议 (Zookeeper原⼦消息⼴播协议)
ZAB 协议的消息⼴播过程类似于⼆阶段提交过程。对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成⼀个事务 Proposal(提议)，将其发送给所有 Follwer ，如果收到超过半数反馈ACK，则执⾏ Commit 操作（先提交⾃⼰，再发送 Commit 给所有 Follwer）。不能正常反馈Follower恢复正常后会进⼊数据同步阶段最终与Leader保持⼀致！
3.Leader崩溃问题
Leader宕机后，ZK集群⽆法正常⼯作，ZAB协议提供了⼀个⾼效且可靠的leader选举算法。
（1）Leader宕机后，被选举的新Leader需要解决的问题ZAB 协议确保那些已经在 Leader 提交
的事务最终会被所有服务器提交。
（2）ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。
基于上⾯的⽬的，ZAB协议设计了⼀个选举算法：能够确保已经被Leader提交的事务被集群接受，丢弃还没有提交的事务。这个选举算法的关键点：保证选举出的新Leader拥有集群中所有节点最⼤编号(ZXID)的事务!!
四. HDFS-HA工作机制
⾃动故障转移为HDFS部署增加了两个新组件：ZooKeeper和ZKFailoverController（ZKFC）进程，ZooKeeper是维护少量协调数据，通知客户端这些数据的改变和监视客户端故障的⾼可⽤服务。
1.HA的⾃动故障转移依赖于ZooKeeper的以下功能：
（1）故障检测
集群中的每个NameNode在ZooKeeper中维护了⼀个临时会话，如果机器崩溃，ZooKeeper中的会话将终⽌，ZooKeeper通知另⼀个NameNode需要触发故障转移。
（2）现役NameNode选择
ZooKeeper提供了⼀个简单的机制⽤于唯⼀的选择⼀个节点为active状态。如果⽬前现役NameNode崩溃，另⼀个节点可能从ZooKeeper获得特殊的排外锁以表明它应该成为现役NameNode。
2.ZKFC是⾃动故障转移中的另⼀个新组件，是ZooKeeper的客户端，也监视和管理NameNode的状态。每个运⾏NameNode的主机也运⾏了⼀个ZKFC进程，ZKFC负责：
（1）健康监测
ZKFC使⽤⼀个健康检查命令定期地ping与之在相同主机的NameNode，只要该NameNode及时地回复健康状态，ZKFC认为该节点是健康的。如果该节点崩溃，冻结或进⼊不健康状态，健康监测器标识该节点为⾮健康的。
（2）ZooKeeper会话管理
当本地NameNode是健康的，ZKFC保持⼀个在ZooKeeper中打开的会话。如果本地NameNode处于active状态，ZKFC也保持⼀个特殊的znode锁，该锁使⽤了ZooKeeper对短暂节点的⽀持，如果会话终⽌，锁节点将⾃动删除。
（3）基于ZooKeeper的选择
如果本地NameNode是健康的，且ZKFC发现没有其它的节点当前持有znode锁，它将为⾃⼰获取该锁。如果成功，则它已经赢得了选择，并负责运⾏故障转移进程以使它的本地NameNode为Active。故障转移进程与前⾯描述的⼿动故障转移相似，⾸先如果必要保护之前的现役NameNode，然后本地NameNode转换为Active状态。