| zookeeper | nginx |
| 不存在单点问题，zab机制保证单点故障可重新选举一个leader | 存在单点问题，单点负载高数据量大 |
| 只负责服务的注册与发现，不负责转发，减少一次数据交换（消费方与服务方直接通信） | 每次负载，都充当一次中间人转发角色，增加网络负载量（消费方与服务方间接通信） |
| 需要自己实现相应的负载均衡算法 | 自带负载均衡算法 |
Nginx是著名的反向代理服务器，也被广泛的作为负载均衡服务器 ZooKeeper是分布式协调服务框架，有时也被用来做负载均衡 那么他们的区别是什么？如何选择呢？ 下面从实际场景看下他们的关系 Nginx的负载均衡配置非常简单，把多个web server配置到nginx中，用户访问Nginx时，就会自动被分配到某个web server upstream backend { server 192.168.1.10; server 192.168.1.11; }
当网站规模变大，通常会进行服务拆分，各个服务独立部署，通过远程调用方式协同工作
为了保证稳定性，每个服务不会只使用一台服务器，也会作为一个集群存在，那么这个子集群同样需要一个负载均衡器，可以使用Nginx
到这里还是没有感觉有使用ZooKeeper的必要，因为使用Nginx完全没问题 但随着整个系统的演进，服务的数量会增加、每个服务集群中的服务器数量会增加
这时就会有一些小麻烦，例如 （1）配置维护的成本变高，因为节点太多 （2）单点故障的风险增加了，因为热点服务的访问量很高，如果这个服务集群内的负载均衡服务出现问题，这个服务将失效 第一个问题，可以通过自己开发程序解决，但只是降低复杂度，并没有实际解决 第二个问题，可以通过双机高可用部署方案，使用另一台nginx负载均衡服务器随时待命，只是成本较高 为了解决这些问题，就有人提出了使用ZooKeeper负载均衡的方案，之前就看到淘宝介绍过此类方案
ZooKeeper负载均衡的实现思路
把ZooKeeper作为一个服务的注册中心，在其中登记每个服务，每台服务器知道自己是属于哪个服务，在服务器启动时，自己向所属服务进行登记，这样，一个树形的服务结构就呈现出来了
服务的调用者到注册中心里面查找：能提供所需服务的服务器列表，然后自己根据负载均衡算法，从中选取一台服务器进行连接 调用者取到服务器列表后，就可以缓存到自己内部，省得下次再取，当服务器列表发生变化，例如某台服务器宕机下线，或者新加了服务器，ZooKeeper会自动通知调用者重新获取服务器列表 由于ZooKeeper并没有内置负载均衡策略，需要调用者自己实现，这个方案只是利用了ZooKeeper的树形数据结构、watcher机制等特性，把ZooKeeper作为服务的注册和变更通知中心，解决了Nginx负载均衡方案带来的问题