zookeeper原理(1)

leader 工作流程

1、恢复数据

2、维持与learner的心跳，接收learner的请求并判断请求类型

3、learner的消息类型分为：ping (心跳)   、 request （follower发送的提议信息，包括写请求和同步请求）、  ack（follower对提议的回复，超过半数follower同意，则          提议被commit）、 revalidate（延长session的有效时间）

 

follower 工作流程

1、向leader发送请求（ping 、request 、ack、revalidate）

2、接收leader的请求并处理。

3、接收client的请求，如果为写请求，发送给leader进行投票

4、返回client结果

leader的消息类型

1、ping 心跳 

2、proposal leader发起的提案，要求follower投票

3、commit 服务器端最新一次的提案信息

4、uptodate 表明同步完成

5、revalidate 根据leader的revalidate的结果，关闭待revalidate的session还是允许其接收消息

6、sync 返回sync结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。

 

zookeeper的应用场景

1、配置管理

zookeeper很容易实现这种集中式的配置管理，比如将APP1的所有配置配置到/APP1 znode下，APP1所有机器一启动就对/APP1这个节点进行监控(zk.exist("/APP1",true)),并且实现回调方法Watcher，那么在zookeeper上/APP1 znode节点下数据发生变化的时候，每个机器都会收到通知，Watcher方法将会被执行，那么应用再取下数据即可(zk.getData("/APP1",false,null));

 2、集群管理

Zookeeper同样很容易实现这个功能，比如我在zookeeper服务器端有一个znode叫/APP1SERVERS,那么集群中每一个机器启动的时候都去这个节点下创建一个EPHEMERAL类型的节点，比如server1创建/APP1SERVERS/SERVER1(可以使用ip,保证不重复)，server2创建/APP1SERVERS/SERVER2，然后SERVER1和SERVER2都watch /APP1SERVERS这个父节点，那么也就是这个父节点下数据或者子节点变化都会通知对该节点进行watch的客户端。因为EPHEMERAL类型节点有一个很重要的特性，就是客户端和服务器端连接断掉或者session过期就会使节点消失，那么在某一个机器挂掉或者断链的时候，其对应的节点就会消失，然后集群中所有对/APP1SERVERS进行watch的客户端都会收到通知，然后取得最新列表即可。

另外有一个应用场景就是集群选master,一旦master挂掉能够马上能从slave中选出一个master,实现步骤和前者一样，只是机器在启动的时候在APP1SERVERS创建的节点类型变为EPHEMERAL_SEQUENTIAL类型，这样每个节点会自动被编号

我们默认规定编号最小的为master,所以当我们对/APP1SERVERS节点做监控的时候，得到服务器列表，只要所有集群机器逻辑认为最小编号节点为master，那么master就被选出，而这个master宕机的时候，相应的znode会消失，然后新的服务器列表就被推送到客户端，然后每个节点逻辑认为最小编号节点为master，这样就做到动态master选举。