zookeeper的“江湖之路”

时事前沿：FaceBook放弃zookeeper，转而使用自主研发的配置管理系统，位置感知分发
系统（Location-AwareDistribution，LAD），满足其部署其数百万台的服务器的需求。
那么当事人zookeeper怎么想的呢？？？

——“呵呵，后生可畏啊！ 2008年，我的创造者Yahoo在武林大会上将我公之于众，从那时到
现在，老夫的江湖地位一直都是有目共睹的。十年了，江山代有才人出嘛，老夫始终相信：
最好的技术永远在路上”

好的，听完前辈的这番话，我这位“江湖说书人”不禁起了这样一些疑惑：

1、zookeeper到底有什么本事，以至于火了这么久
2、这位叫LAD的洋小子到底有多大的本事，能受到“非死不可”的青睐

一、回顾zookeeper
zookeeper，中文名 动物园管理员（相传是因为名字贱好养活，爸妈给的），相传Google
家族的有一位绝世高手Chubby被软禁在家族中，不让外出。Yahoo倾慕高人久矣，平生仅
一面之缘。后来，yahoo仿照Chubby造出zookeeper，并于2008被yahoo推上IT江湖圈。
从此圈内混的风生水起，那么他的庞大功能到底是什么呢？
1、 配置管理（村口大喇叭）
一个项目中，除代码外还有很多配置信息。对于这些配置信息，我们的处理方式有两种
（1）、直接用配置文件的方式来统一存放。这类情况通常适用于配置少，服务器少，且不
经常修改的情况下。
而一旦实际情况不像上诉情况的话，就会采用zookeeper
（2）、zookeeper适用于服务器多、配置文件多，且配置信息会经常变更的情况。
集群可以保证配置的可靠性；zookeeper是一种保证大型集群环境下配置一致的服务。
实际应用：
①HBase中，客户端连接一个zookeeper,获得HBase配置信息
②开源消息队列Kafka，会使用zookeeper来维护broker的信息
③Dubbo使用zookeeper来管理配置实现服务治理
2、命名服务（鹊桥）
引：
http://mail.163.com/index.html（URL，统一资源定位符）
超文本传输协议.网站名.根目录.根目录下默认网页为
163.com为域名
168.103.123.465 为IP
计算机不能直接识别域名
正文：
IP——zookeeper——域名（zookeeper为IP和域名的桥梁，映射）
IP对人是不友好的，而域名更容易被接受。zookeeper解决了DNS在本地保存地址不方便
的问题，直接给消费者提供一个访问的API，这种统一的接口也利于维护
3、分布式锁（部落首长选举）
为 分布式系统提供协调服务。一件事情不可能在集群中的每一台服务器上进行，否则会带
来相互协调的问题。而如果仅仅由一台服务器执行的话，那么整个集群命悬一线，一旦该服
务器发生宕机，整个集群就挂掉了这就是单点问题。
其实可以看作一个部落里，选举出一位能力强大的人当首领，来带领大家完成部落内部的工
作。而部落首领也可能随时遭遇意外，一旦挂掉，部落不肯能一日无首领，这时就会有一位
德高望重的长老，主持挑选一位新的部落首领。
这位长老就是zookeeper！这就是 Leader election 选举。
redis也可解决该问题（缓存方法）
4、集群管理（火眼金睛）
一个集群会出现各种故障和信息变化，这时服务器本身很难快速感知变化做出响应。ZK可
以动态感知到集群目前的状态。服务方将每个节点的信息都注册到ZK上，消费者通过ZK获
取相应节点的信息，如URL
Dubbo+zookeeper 服务发现。便于消费者快速发现相应服务的节点
Kafka+zookeeper 上下线管理
以上是官方给出的 zookeeper 四大本领。 简而言之 ： 分发 配置 更新
那zookeeper这位江湖大佬难道360°C全方位无死角吗？ 非也！
①严格的排序保证——“老古板”
写操作总是被一个线程按顺序处理，读操作有不能中断，于是zookeeper企图俩者兼顾。所
以一旦子节点更新，则会促发大量监控，因而读操作增加，写操作就面临堵塞的问题。
②巨大的集群问题——“心里承受能力差”
人一多，集群超负荷，zookeeper就会出现“紧张，焦虑，甚至厌食，最终罢工“，见不到
大场面，zookeeper也很苦恼，也因此丢掉了和阿里巴巴、非死不可这类企业的合作。
③大型更新会使得NICs饱和——”不够大度“
NIC-网络信息中心，一般配置文件最大为5 MB。
随着更新量增多，更新速度变慢，效率大大降低
以上问题，LAD尽然都不存在。真可谓后生可畏。
然而 zookeeper江湖地位稳坐数十年，LAD岂能轻易完全取代得了！
。。。预知后事如何，请关注本人——IT圈内的 “江湖说书人”