一点点理解 - zookeeper

• zookeeper产生的背景伴随着分布式系统的出现，因为单机的处理性能再高，也高不过一堆服务器的性能。

• 当软件系统由单机转向分布式系统的时候，如何处理分布式系统之间的数据共享和数据一致性等问题呢？zk就是来解决这个的。

• 举个例子，在Hadoop集群中，由于MetaData数据放在Namenode里面，单机瓶颈，为了保障集群高可用，我们做了Namenode2 用于Backup， 主从之间采用zk进行数据交流，确保彼此之间知道，Backup机器发现Master挂掉的时候，可以及时启动接管服务，保障集群正常运行。

• 再举个例子。 在过去的工作中，我们曾经有个项目叫做tomongo，该项目主要是把数据从kafka里面读取出来，然后写入mongodb， 因为就是一个C++ APP，所以也有单点分享， 这个时候老大就要求程序员利用ZK的特性部署两台，改装tomongo程序，一个运行，一个backup，使其避免单点。

• zk的角色。 从总体上，按照工作职责，主要分为 Leader， Follower、Observe。 L负责数据的修改， F和O负责对外Client服务， F和O的却别在于选出集群Leader的时候，O没有投票权，主要用于扩展zk集群的对外服务能力。

• zk的监听端口。面向Client，zk开放了2181端口，zk集群内选择Leader使用端口3888，L F O之间内部数据通信采用2888端口（谁是L谁监听该端口）。

• zk的部署。由于是分布式系统，由于分布式系统依赖网络，所以zk内部通信和外部通信严格依赖网络的性能，如果netstat -s | grep timeout发现计数器有增加，需要密切关注； 由于管理数据需要落盘，所以对于磁盘的性能也要求较高，否则会耽误zk内部数据同步，导致对Client响应不及时。

• zk集群内部的机器数量。为了防止脑裂，机器数量必须是单数，3 5 等，当然也可以单机作为测试部署，不可以是双数。 只要有半数的机器存活就可以保障zk集群的稳定运行。