zookeeper

目录

 

zk的介绍

zookeeper的特性

说说你对zookeeper 的三个主要角色的理解?

zookeeper是如何进行高可用协调的?

---

zk的介绍

zookeeper是一个分布式的服务协调框架，主要用于协调辅助其他的框架正常的运行，主要是为了解决应用系统当中的一致性问题
zk的本质上是一个分布式的小文件存储系统，每个文件内容最好不要超过1M
分布式就是每台机器看到的数据都是一样的

zookeeper的特性

1. 全局的数据一致性：保证每台机器看到的数据都是一模一样的
2. 可靠性：如果数据被一台服务器接收，最终会被所有服务器接收
3. 顺序性：所有的机器处理请求的顺序都是一致的
4. 数据更新的原子性：数据更新处理要么成功，要么失败，不存在一半成功一半失败的情况
5. 实时性：数据的更新在一段时间内最终都会被所有的机器接收成功

说说你对zookeeper 的三个主要角色的理解?

三个主要角色分别是领导者（leader）、跟随者（follower）和观察者（observer），其中跟随者和观察者都是学习者（learner）。

1. 领导者负责进行投票的发起和决议，更新系统状态（数据同步）从而保证事务处理（写操作）的顺序性，发送心跳（客户端能够通过心跳检测与服务器保持有效的会话）
2. 跟随者用于接受客户端请求、向客户端返回结果，在选主过程中参与投票
3. 观察者可以像跟随者一样处理客户端的读写请求。但是观察者不参加投票过程，只同步领导者的状态。观察者的目的是为了扩展系统，提高读取速度。

zookeeper的主备架构（不包括观察者）：

zookeeper启动后，或领导者失效后，跟随者开始投票，选举新的领导者。新的领导者带着跟随者同步数据，把数据都同步成一致后就可以对外接受请求。

zookeeper的主从架构（观察者和跟随者统称学习者）：

客户端向集群发出写请求，学习者把写请求转发给领导者，领导者接收后向所有学习者发起提案，让它们执行写操作再把操作结果发回领导者，当多数学习者返回提案结果后，领导者会通知其他学习者同步信息，学习者再把请求结果返回给客户端。

客户端向学习者发出读请求，学习者可以直接把请求结果返回给客户端。

zookeeper是如何进行高可用协调的?

以HDFS的HA（高可用HighAvailability）为例，这是使用zk来感知namenode的变化，利用的是zk的临时节点加watch机制。

ZooKeeper中的节点有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定，并且不能改变。

① 临时节点：在客户端用create -e创建，该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束，临时节点将被自动删除，当然可以也可以手动删除。虽然每个临时的Znode都会绑定到一个客户端会话，但他们对所有的客户端还是可见的。另外，ZooKeeper的临时节点不允许拥有子节点。

② 永久节点：在客户端用create 创建，该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。

客户端可以给节点设置watch(观察)。当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操作。当watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知。

1) 客户端1在zookeeper上创建临时节点/app
2) 客户端2,3也想创建/app节点,但己经被客户端1创建了，只能对/app节点设置观察
3) 当客户端1把/app节点删了，zookeeper会通知设置观察的客户端2,3，客户端2,3接到通知后，进行后续动作，抢占创建/app节点。创建/app节点相当于拿到了锁，删除/app节点相当于释放锁，这个临时节点就是锁节点。

在HDFS的高可用机制中

1. 两个namenode机器都有zkfc(ZooKeeper FailoverController, ZK故障排除控制)服务，zkfc作为一个ZK集群的客户端，用来监控NN（namenode）的状态信息，并定时向ZK集群发送来自NN的心跳报告。每个运行NN的节点必须要运行一个zkfc。
2. 当启动服务时，假设nn1启动变成active(活动)状态，会在ZK集群上创建锁节点，并将当前active状态的机器名称nn1写入该节点。
3. nn2启动后,看这个锁节点是否存在。如果存在，nn2机器上的zkfc服务就变成了standby (备用)状态，并到ZK集群上对该临时节点设置观察。
4. 假设在某个时间节点，nn1机器上的zkfc服务挂掉或者假死（nn1的负载过高或者正在进行full GC，导致zkfc的心跳不能正常发出），那么ZK集群就收不到该zkfc服务发送的心跳。这时ZK集群会关闭与nn1的会话，把锁节点删掉，删掉的同时会发通知给nn2。
5. nn2机器收到通知后，由standby状态转换成active状态，继续运行，同时也在ZK集群上创建锁节点，并将当前active状态的机器名称nn2写入该节点。在该过程中，nn2会先把nn1转换成备用状态，实在不行就把nn1的namenode进程kill掉，最后再把自己转换成活动状态，从而防止脑裂(在一个高可用的HDFS集群中,要始终保持只有一个活动的NN,否则就会出现"脑裂"问题，"脑裂"会导致数据不一致,部分数据丢失)。

除了HDFS中Active NameNode的选举以外，YARN中Active ResourceManager的选举和HBase中Active HMaster的选举等也是同样的原理，只是不需要zkfc守护进程以保证数据同步。