（一）
负载均衡（Load Balance）是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。常见互联网分布式架构如上，分为客户端层、反向代理nginx层、站点层、服务层、数据层。
现在使用最多的基于软件的负载均衡是Nginx和ZooKeeper：
Nginx是著名的反向代理服务器，也被广泛的作为负载均衡服务器
ZooKeeper是分布式协调服务框架，有时也被用来做负载均衡
那么它们有什么区别？我们还怎么选择
Nginx
Nginx的负载均衡配置
（1）把多个web server配置到nginx中，用户访问Nginx时，就会自动被分配到某个web server。
（2）当网站规模变大，通常会进行服务拆分，各个服务独立部署，通过远程调用方式协同工作。
（3）为了保证稳定性，每个服务不会只使用一台服务器，也会作为一个集群存在，那么子集群也可以使用Nginx负载均衡。
ZooKeeper
ZooKeeper的负载均衡模式
（1）ZooKeeper作为一个服务的注册中心，每个服务在其注册中心登记，每台服务器知道自己是属于哪个服务，在服务器启动时，自己向所属服务进行登记
（2）服务的调用者到注册中心里面查找：能提供所需服务的服务器列表，然后自己根据负载均衡算法，从中选取一台服务器进行连接。
（3）调用者取到服务器列表后，就可以缓存到自己内部，省得下次再取，当服务器列表发生变化，例如某台服务器宕机下线，或者新加了服务器，ZooKeeper会自动通知调用者重新获取服务器列表
使用场景
使用Nginx，随着整个系统的演进， 服务 的数量会 增加 、每个服务集群中的 服务器 数量会 增加
这时就会有一些小麻烦，例如
（1）配置维护的成本变高，因为节点太多
（2）单点故障的风险增加了，因为热点服务的访问量很高，如果这个服务集群内的负载均衡服务出现问题，这个服务将失效
第一个问题，可以通过自己开发程序解决，但只是降低复杂度，并没有实际解决
第二个问题，可以通过双机高可用部署方案，使用另一台nginx负载均衡服务器随时待命，只是成本较高
而ZooKeeper作为服务的注册和变更通知中心，解决了Nginx负载均衡方案带来的问题。
但是ZooKeeper并没有内置负载均衡策略，需要调用者自己实现，这个方案只是利用了ZooKeeper的树形数据结构、watcher机制等特性。
（二）
zookeeper本身是不提供负载均衡的策略,需要自己来实现，所以这里确切的说，是在负载均衡中应用到了zookeeper做集群的协调。
对于HTTP请求的负载均衡，成熟的解决方案是Nginx（或Haproxy） +keepalived。其中Niginx负责代理HTTP请求，通过某种均衡策略访问集群中的服务器，keepalived负责检测集群中的服务器运行情况（有故障的机器移除，机器恢复工作后重新加入）
而对于TCP层的负载均衡，比如用Apache Mina做的网络通信应用，上面那种方案明显不适合，因为网络通信客户端和服务端要保持长连接
所以要针对这种长连接做负载均衡，一般都是基于连接数这种均衡策略，也就是在第一次连接时，分配服务器IP时，取当前连接数最少的那台
集群中有几台服务器处于运行状态，每一台服务器当前连接的客户数量，最大连接数量，等等这些信息需要记录起来，然后每次做负载均衡时根据这些信息来做分配，一般首先想到的是把这些信息存放在数据库里
简单的做法就是服务器启动时，把数据库里相应的状态改为运行，有客户连接或断开时，把连接数做加数或减数运算。
当服务器关闭时，问题就来了：
1、服务器关闭，可能数据源也已经被关闭，没法操作数据库，该机器在数据库里一直处于运行状态
2、服务器宕机，这种问题就很致命，这是连关闭的程序都没有执行，更不用说能操作数据库了
解决的方式就是用zookeeper保存服务器的连接信息
1、当服务器启动时，往zookeeper的节点里写入数据（节点类型是临时节点）
2、当服务器关闭时，从zookeeper移除相应的节点数据
3、当服务器宕机，zookeeper因为没有检测到心跳，自动把该节点移除，并通知其他服务器，其他服务器得知该机器已宕机，在分配连接时，不会分配到这台机器上，这点也是标题说的在负载均衡中用到zookeeper的原因。
对比了一下保存在数据库那种方式，zookeeper其实就是一个具有通知功能的数据库，也就是它底下节点数据有变化时，会通知它的所有客户端（这里的客户端指的连接到zookeeper的服务器）。
