Zookeeper的局限性

Zookeeper框架的局限性有以下几个方面：

存储容量

　　局限性： Zookeeper将所有数据都放在内存里，这意味着服务器的物理内存大小决定了ZNode节点所能够存储的数据量的上限；
　　对实际影响：配置数据总量不能太大，否则会造成启动太慢，甚至OOM；

伸缩性

　　局限性： 增加机器可以提升ZK集群的读性能，但是写性能不会提高，甚至可能下降。原因是写操作需要集群中过半的机器投票决定，机器数量的增加导致投票时间增加，从而写性能下降。官网原话如下：

　　 Although ZooKeeper performs very well by having clients connect directly to voting members of the ensemble, this architecture makes it hard to scale out to huge numbers of clients. The problem is that as we add more voting members, the write performance drops. This is due to the fact that a write operation requires the agreement of (in general) at least half the nodes in an ensemble and therefore the cost of a vote can increase significantly as more voters are added.

官网实验测试数据如下：
　　　　　　　　
　　对实际影响：客户端的数量不能过于庞大，因为没办法通过增加机器来分担压力；

Zookeeper原生API存在如下局限性：

同机房优先

　　为了达到容灾需求，ZK集群中的机器通常会分开部署在多个机房中，这就会导致网络延时问题（应用连接到了其它机房的ZK机器），如下图所示。通的解决放哪就是“同机房优先策略”，但是HostProvider只是随机选取一台机器，并没有提供“同机房优先”的策略。
　　　　　　

服务器地址列表动态变更

　　HostProvider中的服务器地址在客户端启动后就变成固定的了，没法跟着ZK集群的变更而变化。这就导致当ZK集群迁移或者变更时，所有依赖ZK集群的客户端都有需要进行变更。