ZooKeeper是何方神圣
zookeeper（简称zk），顾名思义，为动物园管理员的意思，在Hadoop生态体系这个动物园里，他确实管理着诸如Hadoop（大象），HBase（鲸鱼）等动物；甚至很多动物园之外的用户也在依赖他（如Storm，Kafka）。在分布式场景中，zk的应用非常广泛，如：数据发布/订阅、命名服务、配置中心、分布式锁、集群管理、选主与服务发现等等。下面通过一个故事来说明zookeeper到底是怎么发迹起来以及如何管理其他”动物“的
zookeeper是何方神圣
zookeeper（简称zk），顾名思义，为动物园管理员的意思，在Hadoop生态体系这个动物园里，他确实管理着诸如Hadoop（大象），HBase（鲸鱼）等动物；甚至很多动物园之外的用户也在依赖他（如Storm，Kafka）。在分布式场景中，zk的应用非常广泛，如：数据发布/订阅、命名服务、配置中心、分布式锁、集群管理、选主与服务发现等等。下面通过一个故事来说明zookeeper到底是怎么发迹起来以及如何管理其他”动物“的
zookeeper的封神之路
在大数据大陆的元年，一切都是全新的存在，在上一纪的巨型国家如Oracle，Mysql以及postgresql都对疯狂生长的资源DATA无能为力的时候，大家只能寄希望于大数据大陆能有好的表现来处理和利用这些生物。在这种情况下，大数据大陆的居民们共同努力，组成了各种联邦，如Hadoop联邦，HBase联邦等。这些联邦都是一个一个小的城池（worker）在统一的国王（master）的领导下共同协作，来处理和利用DATA这种资源。
另外，大数据联邦之所以能比之前的巨型国家能更好的应对DATA的原因就是随着DATA的不断增长，是因为大数据联邦可以通过合并城池来扩展自己”抵抗“DATA的能力，完美！
但是仔细想想，好像有什么BUG啊，事情没这么简单，正常情况下肯定一帆风顺，但是天有不测风云，人有旦夕祸福，更何况如何复杂的体系面对如此巨量的DATA，不出问题才奇怪呢。
统领大家的国王万一有一天身体有恙无法出战（假死或者网络隔离了）或者去世了（机器爆炸了或者被偷了），那怎么办？总不能大家散伙吧，唯一的办法就是选取新国王，但是怎么选呢？
国王负责决策且下达命令，但是所有的命令都有国王下达给所有的领主，那么国王大概率会被累死，而且由于道路不通（网络隔离）或者领主没睡醒（GC或者假死），那这个命令就没办法下达到领主那里了，总不能大家各自为战吧？还有如果本联邦以及其他联邦的领主来买DATA（查询数据）或者处理DATA（处理数据），都找国王，那国王同样也得累死，怎么破？
上述的这些问题困扰着大数据大陆的各个成员，但这些事情又非常的重要，需要解决，否则大数据各个联邦就没办法愉快的”对付“DATA了，在这种情况下议会（zookeeper）出现了。议会一出道就是巅峰，直接闪瞎了所有大数据联邦国王和领主们的眼睛，因为他能完美的解决这些问题。然后议会受到了前所未有的欢迎，几乎所有面临上面问题的联邦都让议会帮他们解决这些问题，接下来议会就开始了封神之路，让议会如何开始他们的表演吧。
那么议会是怎么解决上面的两个个问题的呢，下面就说明一下：
选国王（master的failover）
国王不在了，要选举新的国王？小case，国王的上任只要经过议会的认证和授权就行了。方法如下：
议会有一把象征国王身份的权杖（zookeeper的临时锁），谁拿到了这个权杖，谁就是国王，然后国王领导大家”对付“DATA。
但是俗话说得好，不想当将军的士兵不是好士兵，领主们在跟着国王”对付“DATA的同时，也一直盯着议会是否会出现新的权杖（watch临时锁是否可以获取）。而在国王带领大家打仗的同时，议会也一直通过书信（heartbeat）和国王定时联系，”关心“（监视）国王的身体健康。
这时如果国王因为各种原因挂了，议会由于没有收到定时的书信会很快知道，然后就会进入选新国王的流程。之前的权杖就失效了，议会会出现一把新的权杖，还是之前的规则，谁先拿到谁就是新国王，上文说到领主们在盯着议会是否出现新的权杖，发现出现新权杖后，大家就知道老国王挂了，就一拥而上抢新的权杖，有一个幸运儿手最快拿到了权杖，当上了新的国王，继续刚才的过程直到永远。
命令传达（configuration的同步以及管理）
国王是一个联邦的统帅，关系到整个处理DATA的大业，所以不能让国王太累，从而进入半死不活（服务器负载过高）的状态，而诸如传达命令减轻国王负担的任务就交给议会了，议会微微一笑，表示毫无压力，于是给出下面的方案：
国王签署任何命令后直接告诉议会的一把手议长（zookeeper的leader），议长负责在议会中同步国王的命令，同步完毕后就可以向领主们传达命令了。
领主们主动领取命令不需要直接去找国王了，而是直接来找议会，随便找一个议员都可以
这样的处理方式国王的压力突然少了很多，可以专心干好自己的事情；领主们也不怕得不到命令了，找一群议员总比找一个国王更容易更安全
另外针对资源DATA的操作直接和议会进行沟通即可，但是针对某些高级操作需要国王参与，如创建存储DATA的仓库（NOSQL的表）还是需要国王参与，但是国王处理完还是会将命令放在议会供领主们使用
议会就这样完美的解决了各个大数据联邦的痛点，而在大数据早期大家的重心都在处理DATA上，而只有议会能帮他们解决这些共有的问题，于是毫无疑问大家都选择了议会，基本上成为那个时代的标配，从此走上了封神之路。
故事暂时告一段落，总结一波记笔记了，此处划重点：
master election and failover
zookeeper解决了大数据组件选主以及主节点的failover的问题，实现方式如下：zookeeper在内部维护了一把独占锁（临时节点），master的候选人谁先获取到这把锁谁就会变成真正的master，其他的候选人也会不断的尝试获取这把锁以成为master；
master在被选出后就和周期性的和zookeeper通信，上报心跳，如果master的心跳zookeeper未获取到且超时，则zookeeper认为当前master已经死掉，并发起master的failover，释放掉那个独占锁，其余的候选人谁先获取到这把锁，就会成为新的master，其他候选人继续之前不断获取锁的过程。
configuration的同步以及管理
zookeeper同样也可以作为大数据集群的配置中心，组件可以根据需求将配置放在zookeeper中供使用
当client或者slave server需要获取配置的时候可以直接访问zookeeper而不需要访问master获取，这也提高了系统的健壮性，HBase既是这样的实现逻辑。数据的增删改查不需要经过master直接访问zookeeper即可，所以HBase的master挂掉不会影响数据的读取和操作
还有一点就是，client在连接zookeeper时采用的是roundrobin算法（轮询算法），通过随机的顺序访问zookeeper列表，有一个能访问到即连接成功，这样做即可以增加连接成功率进而增加系统的健壮性，又能在一定程度上做到压力负载均衡。
zookeeper为什么能这么牛
这个问题比较大，也比较宽泛，不是本文介绍的重点，这里我就不多说了，稍微提一下，感兴趣的可以去自己学习下，如果不明白可以留言交流。
zookeeper使用的一致性算法是ZAB算法（zookeeper automatic broadcast）算法，这个是zookeeper绝大部分功能的基础，ZAB师承Leslie Lamport的paxos算法，在paxos的基础上做了定制化。和我上一篇博文写的raft算法的功能是一样的，只是raft算法更容易理解和实现。
zookeeper又是怎样跌下神坛的
接着上面的故事，日子一天天的过去了，如果一切顺利，可能这就是故事的结局了。但是精彩的故事总是有反转，这篇故事也是一样的。大家是不是突然间很期待呢？大家想象下可能会怎么样反转呢？
故事接着发展，慢慢的，议会在解决了之前的问题后又出现了很多新的问题，而且大数据大陆上新崛起的联邦开始抛弃议会；而之前和一会相处愉快的老牌联邦也慢慢开始嫌弃议会的“年老色衰”了，纷纷开始疏远和想办法替代议会了，曾经那个YYDS到底怎么了？议会一脸懵逼，大家陷入沉思....
下面是我能想到的，欢迎补充。我分直接原因和间接原因来说明：
直接原因
随着DATA的不断增加，国王需要发布的命令越来越多，领主的任务也越来越多，需要快速拿到命令进行处理。而议会则是强制达成一致后才能对外提供命令，如果达成一致的时间大于命令产生的时间，则命令就没办法按时发布，那就会产生积压的命令，处理DATA的速度就会变慢，而议会就成为了其中的瓶颈
国王和领主对于独立自主的渴望越来越强烈。国王和领主在私底下想，我们要干的事情自己也可以干，为什么非要拉上议会呢？既浪费资源又不能处理DATA，搞点什么创新以及提升还要看议会的脸色，看议会能不能搞得定，真是太不爽了
间接原因
议会已经不再是选举国王的唯一方法了，新出来了一个叫RAFT的小弟，这个小弟能叫国王以及领主们如何能在任何情况下自己选出国王且能保持国王发布的命令不丢失，既能达到之前选国王的目标还能自己搞定不依赖他人，爽死了！
现在又出现了一种新的联邦组成方式，没有国王一说或者说大家都是国王，在这种大家都平等的环境下一起处理DATA，其实也挺香的
把上面的话翻译一下：
直接原因
由于zookeeper是强一致性的数据模型，所以数据的同步需要时间；另外zookeeper适用于读多写少的场景，所以在数据处理压力增大，尤其是频繁读写的场景下，zookeeper的性能很差，已经成为数据处理的瓶颈，而这种瓶颈确实各个组件无法解决的
zookeeper作为单独的集群需要占用一部分资源，而且很多时候组件想优化性能以及处理流程还需要考虑zookeeper是够支持，是否能够达到性能要求，这对于各个组件来说是一种不可控的因素
间接原因
raft的出现改变了之前共识算法的格局，zookeeper不再是唯一的选择，更何况raft具有易理解和易实现的特点，raft出现后众多raft-like算法的实现如雨后春笋般的出现就是很好的例证，如elasticsearch，tidb，2.8以后的kafka等
去中心化的大数据产品开始慢慢的出现，如Cassandra，他使用gossip协议进行数据同步，不需要公式算法，同样有不俗的效果，进一步稀释了zookeeper的市场
总结
zookeeper作为一款优秀的协调服务，在数据量不是特别大且读多写少的场景下，还是很好用的。但是随着数据量越来越大，处理压力也越来越大，这种情况下zookeeper也越来越力不从心了。这点从新一代大数据组件很少使用zookeeper，而使用zookeeper的组件正在减少对zookeeper的依赖（HBase）或者尝试摆脱zookeeper（2.8版本以后的kafka，尝试使用raft代替zookeeper）就可以看得出来。
但是这也正是技术的魅力，江山代有人才出，各领风骚数百年。曾经辉煌过就不枉此生了，而作为技术人员的我们也需要不断学习，拥抱新技术，拥抱变化。只有这样才能以不变应万变，在技术发展的潮流中直挂云帆济沧海！