zookeeper详解

一 前言   

    最近在做公司系统配置中心的迁移过程中，用到zookeeper,学习过程中查阅了很多资料，这里进行了整理和思考，供大家参考学习。

首先应该知道，zookeeper是属于分布式应用协调服务，简单来说，就是分布式应用依赖zookeeper保持一致性，或者依赖zookeeper来实现调用分配（dubbo就是靠zookeeper注册的分布式服务的地址，并依赖zookeeper实现动态分发，这也是我们公司分布式框架用过的，后面会详细介绍）。

二 开篇

   本篇文章，主要是站在应用者的角度来讲解zookeeper， 很多文章分析了zookeeper怎么选举leader，我们不做重复说明了，但是有一点大家要记住，选举leader要保证算法正确性需要满足下面条件： Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1。我们这里着重探讨为什么zookeeper需要leader，其实这也是为了保证一致性的算法所必须的，大家leader可以把leader想象为一个领导，小的们都以他说的为主，他说1就是1，他说2就是2，这样大家不就一致了，当有一个员工有话要说，通过游说领导，让领导通知大家，不就完成了大家的一致性。

  这里想要补充一些知识，看了很多文章一致有个疑惑就是zookeeper是如何保证自己集群的一致性的，只有保证了自己集群的一致性才能保证对外的一致性。 选举leader其实就保证了集群的一致性，因为在leader的选举过程中，首先leader是zxid最大的节点，选举出最大节点之后，所有的follwer都需要把id打包发给leader，leader会根据他们的id值判断foolwer是否需要同步，半数以上的follwer完成了同步leader选举才真正的接受，才可以接受来自client的请求。

三  实例

  废话不多说了，直接看看zookeeper常见的场景下配置管理，我们是如何应用的：

 程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。好吧，现在把这些配置全部放到zookeeper上去，保存在 Zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中就好。

这里要申明一下，我们框架中用了spring,可以实现实现一个自己的注解，在程序启动的时候，根据注解，下载配置文件，并把配置文件里的属性读入到内存中，在zookeeper中配置文件发生变化的时候，我们再watch方法中重新下载配置文件，并用反射的机制重写对象中的属性文件值。

 

后序：zookeeper还有一个常见场景就是集群管理，阿里巴巴开源框架dubbo就是使用zookeeper进行分布式服务目录管理，后面将有一篇详细介绍dubbo的文章进行说明。