Hadoop的框架里面经常有听到PIG（猪）、HIVE（小密蜂）、Hadoop（大象）......，就像是动物园的小动物，这些小动物的管理者就是ZooKeeper。玩笑讲完了，我们还是回到正题。ZooKeeper的诞生主要是解决是集群的管理节点高可用。接下来，我们来看一看案例。
一、ZooKeeper的诞生历程
1、传统单机的环境，如Java程序调用Mysql数据源的IP、密码一般是写在一个配置文件中。
2、但数据源的IP地址会变化，因此我们将配置文件拿出来，作为一个共享文件进行集中管理。
3、配置节点将配置信息集中管理后，如果配置信息发生了变化，必须及时通知使用该信息的组件。因此增加了监听的功能。
4、配置节点目前为单节点，存在故障隐患。因此将配置节点做成多个，之间保持数据的同步。但主用配置节点（具有写入权限的节点）只有一个，其它从配置节点收到写入命令后必须将命令传送给主用配置。
二、ZooKeeper必须在配置节点和程序节点（组件节点）同时安装
ZooKeeper组件节点可以同时配置多个服务源，当正在使用的服务源故障中断后，可以自动与其它服务源进行连接，以保证ZK配置节点的高可用。
三、ZooKeeper的数据内容较简单，小于1MB
ZooKeeper主要用于保存配置文件，一般是文本文件，因此数据量很小。在ZooKeeper中采用Znode作为数据管理的最小单元，且小于1MB。如下图，方框部分就是一个Znode。
如app1就是一个Znode，Znode中存储了server_ip的很多配置。
四、案例ZooKeeper在Mysql主备用库选择中的应用
常规，我们实现Mysql的主备用库的高可用，一般是采用RoseHA、KeepAlived软件等，实现方法是采用VIP浮动IP的方式。
如果我们用ZooKeeper来实现，原理则会发生变化。
我们在数据库服务器上部署ZooKeeper的agent，该agent实例定时ping mysql实例，当mysql实例故障时，agent将在ZooKeeper配置节点删除该Znode临时节点。当某个Java程序连接数据库源时，将通过ZooKeeper获取当时能使用的mysql数据信息。通过以上方式实现了Mysql主备用库的选择。
看到这里，大家应有所感悟，采用ZooKeeper与RoseHA进行Mysql的主备库切换有很大的区别。而市面上一般采用RoseHA进行主备切库，原因是简单，Java程序基本不需要进行改造，甚至一般是将配置直接固定写进了程序中或本地的INI文件中。而采用ZooKeeper的方式则必须重新编写获取配置的类，必实现ZooKeeper的接口。通过Java编程的方式，不仅是能实现主备切换，甚至能实现主主权重负载均衡。
附Java实现ZooKeeper接口的图例
希望以上文章能帮到您。
更多内容实时更新，请访问公众号。 