一点点理解 - zookeeper

最新推荐文章于 2025-07-05 10:45:00 发布

原创最新推荐文章于 2025-07-05 10:45:00 发布 · 647 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#分布式

分布式专栏收录该内容

1 篇文章

订阅专栏

本文介绍了ZooKeeper在解决分布式系统中数据共享和一致性问题的应用场景，包括Hadoop集群中的元数据管理和C++应用程序的数据备份方案。讨论了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集群的稳定运行。