这篇博客作者基于实际使用经验，指出Zookeeper作为服务化框架注册中心存在的问题，包括写效率低、数据日志量大、节点设计依赖业务查询逻辑、事务支持不完善、读写性能瓶颈、存储容量限制、网络闪断影响、客户端与服务端一致性差异以及集群扩展不便等。作者强调，Zookeeper在某些场景下并不适用，选择技术栈时需谨慎。
公司做了一版服务化框架，使用zookeeper作为注册中心，用来存储服务信息。
在使用的过程中，发现zookeeper有一些天生的缺陷。特此写一篇博客，记录踩过的坑，以警示后来者也。
以下内容基于zookeeper.4.8版本，在公司搭建的环境，数据不一定准确，但有一定的参考意义。
1.zookeeper的写效率非常低,在我点机器上测到稳定写tps为1000左右。zooKeeper基于分布式系统的ZAB协议，某一时刻集群只有一个主节点，写操作都由主机点进行处理，然后在集群节点进行同步。所以zookeeper注定不适合写操作频繁的场景。
2.zookeeper的数据日志是直接加的方式，在进行写操作的时候会有相应的数据日志产生，而且日志量非常大，大日志量会对运维，磁盘效率造成影响，也从一个方面说明了zookeeper不适合写操作频繁的场景。
3.zookeeper的节点设计结构严重依赖于业务查询逻辑。zookeeper可以看作一个数据库，但不同于常用的mysql,oracle结构性数据库，它更像一个文件结构数据库。查询逻辑也类似于找一个文件要知道它的目录，同理，找到zookeeper的一个节点要知道它在哪个父节点下面。如果业务逻辑改了，比如要添加一个新的查询逻辑，往往要修改原来的节点结构或者增加冗余节点，冗余信息。增加冗
最低0.47元/天 解锁文章
扫一扫
1514
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
