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的服务器）。
