zookeeper3.3学习笔记4：zookeeper的三种角色

zookeeper的每一个节点能够有以下三种角色：

1.leader和follower

 

      ZooKeeper须要在全部的服务（能够理解为服务器）中选举出一个Leader，而后让这个Leader来负责管理集群。此时，集群中的其它服务器则成为此Leader的Follower。而且，当Leader故障的时候，须要ZooKeeper可以快速地在Follower中选举出下一个Leader。这就是ZooKeeper的Leader机制，下面咱们将简单介绍在ZooKeeper中，Leader选举（Leader Election）是如何实现的。

此操做实现的核心思想是：首先建立一个EPHEMERAL目录节点，例如“/election”。而后。每个ZooKeeper服务器在此目录下建立一个SEQUENCE|EPHEMERAL类型的节点，例如“/election/n_”。在SEQUENCE标志下，ZooKeeper将自动地为每个ZooKeeper服务器分配一个比前一个分配的序号要大的序号。此时建立节点的ZooKeeper服务器中拥有最小序号编号的服务器将成为Leader。

在实际的操做中，还须要保障：当Leader服务器发生故障的时候，系统可以快速地选出下一个ZooKeeper服务器做为Leader。一个简单的解决方案是，让全部的follower监视leader所对应的节点。当Leader发生故障时，Leader所对应的临时节点将会自动地被删除，此操做将会触发全部监视Leader的服务器的watch。这样这些服务器将会收到Leader故障的消息，并进而进行下一次的Leader选举操做。可是，这种操做将会致使“从众效应”的发生，尤为当集群中服务器众多而且带宽延迟比较大的时候，此种状况更为明显。

在Zookeeper中，为了不从众效应的发生，它是这样来实现的：每个follower对follower集群中对应的比本身节点序号小一号的节点（也就是全部序号比本身小的节点中的序号最大的节点）设置一个watch。只有当follower所设置的watch被触发的时候，它才进行Leader选举操做，通常状况下它将成为集群中的下一个Leader。很明显，此Leader选举操做的速度是很快的。由于，每一次Leader选举几乎只涉及单个follower的操做。

 

 

2.Observer

      observer的行为在大多数状况下与follower彻底一致, 可是他们不参加选举和投票, 而仅仅接受(observing)选举和投票的结果.

 

参考：

http://labs.chinamobile.com/mblog/225_35225

 

http://hi.baidu.com/airyoung/blog/item/c8ab53d628ac4a3506088b6b.html

 

http://www.blogjava.net/ivanwan/archive/2011/05/05/349582.html

 

http://zookeeper.apache.org/doc/r3.3.2/zookeeperObservers.html