关于zookeeper的自我解惑

最新推荐文章于 2022-06-08 19:17:19 发布

Torreson

最新推荐文章于 2022-06-08 19:17:19 发布

阅读量1.9k

点赞数

分类专栏： Zookeeper 文章标签： zookeeper

本文链接：https://blog.csdn.net/Kingson_Wu/article/details/40188821

版权

Zookeeper 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

分布式服务框架 Zookeeper -- 管理分布式环境中的数据： http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/

Zookeeper工作原理： http://blog.csdn.net/kingson_wu/article/details/25734005

ZOOKEEPER解惑： http://www.cnblogs.com/gpcuster/archive/2010/12/29/1921213.html

1.zookeeper集群中每个server中都有zoo.cfg配置，里面有配置存储数据的目录，不同的server存储数据的目录不一样。假如有三个server组成zookeeper集群，server1保存在目录data1，server2保存在目录data2， server3保存在目录data3。但这三个server组成一个集群整体，即zookeeper对客户端（外部的服务器——非zookeeper集群中的服务器）来说只是一个整体的服务器。客户端通过

  
   zooKeeper  = new ZooKeeper("localhost:2181,localhost:2182,localhost:2183", SESSION_TIMEOUT, watcher);

来访问zookeeper，至于最终客户端访问的是具体哪个服务器或者说是哪个服务器对应的数据，由zookeeper内部决定。

如上所述，server通过各自的zoo.cfg识别保存数据的目录data，而当客户端（同上）访问zookeeper中的data时，通过目录data1,data2,data3各自的myid识别所访问的数据来自哪一台zookeeper集群中的服务器（zookeeper访问负载均衡，分流）。也就是说zoo.cfg在写数据是发挥作用，myid在读数据时发挥作用。

2.zookeeper集群中的服务器（server）有leader和follower（还有observer）之分，而访问zookeeper的集群服务器（client）（即上述所说的客户端）则通过zookeeper实现master和slave之分。zookeeper集群通过leader Selection推举一个leader，集群是为了若leader宕机时保证zookeeper的可用性。而客户端的集群则是通过访问zookeeper来实现（每个客户端的具体实现都要访问zookeeper），保证客户端集群有master保证客户端的可用性。

其他延伸： http://blog.csdn.net/shenlan211314/article/details/6187040

Leader选举

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 的操作。