ZooKeeper相关要点

转载自：http://blog.youkuaiyun.com/kobejayandy/article/details/11836177

       客户端对ServerList的轮询机制是随机的。
       客户端在初始化的过程中，将所有Server保存在一个List中，然后随机打散，形成一个环。之后从0号位开始一个一个使用。
       两个注意点：1. Server地址能够重复配置，这样能够弥补客户端无法设置Server权重的缺陷，但是也会加大风险。（比如: 192.168.1.1:2181,192.168.1.1:2181,192.168.1.2:2181). 2. 如果客户端在进行Server切换过程中耗时过长，那么将会收到SESSION_EXPIRED. 这也是上面第1点中的加大风险之处。


       在ZooKeeper中，服务器和客户端之间维持的是一个长连接，在SESSION_TIMEOUT时间内，服务器会确定客户端是否正常连接(客户端会定时向服务器发送heart_beat),服务器重置下次SESSION_TIMEOUT时间。因此，在正常情况下，Session一直有效，并且zk集群所有机器上都保存这个Session信息。
       在出现问题情况下，客户端与服务器之间连接断了（客户端所连接的那台zk机器挂了，或是其它原因的网络中断），这个时候客户端会主动在地址列表（初始化的时候传入构造方法的那个参数connectString）中选择新的地址进行连接。
       在这个过程中，用户可能会看到两类异常CONNECTIONLOSS(连接断开) 和SESSIONEXPIRED(Session过期)。
       CONNECTIONLOSS发生在客户端与服务器之间连接断开的情况，客户端在进行操作A时，发生了CONNECTIONLOSS，此时不需要会话是否可用，所要做的就是等待客户端帮自动连接上新的zk机器，一旦成功连接上新的zk机器后，确认刚刚的操作A是否执行成功了。发生CONNECTIONLOSS之后，只要在session_timeout之内再次连接上（即不发生SESSIONEXPIRED），那么这个连接注册的watches依然在。
       SESSIONEXPIRED发生的情况通常是zk客户端与服务器的连接断了，试图连接上新的zk机器，这个过程如果耗时过长，超过SESSION_TIMEOUT后还没有成功连接上服务器，那么服务器认为这个session已经结束了（服务器无法确认是因为其它异常原因还是客户端主动结束会话），开始清除和这个会话有关的信息，包括这个会话创建的临时节点和注册的Watcher。在这之后，客户端重新连接上了服务器在，服务器会告诉客户端SESSIONEXPIRED。此时客户端要做的事情就看应用的复杂情况了。总之，要重新实例zookeeper对象，重新操作所有临时数据（包括临时节点和注册Watcher）。


       同一个zk客户端对某一个节点注册相同的watch，只会收到一次通知。
如果节点数据的更新频率很高的话，并不保证能收到节点每次变化的通知。原因在于：当一次数据修改，通知客户端，客户端再次注册watch，在这个过程中，可能数据已经发生了许多次数据修改。


       事务日志存储设备性能：ZooKeeper会同步事务到存储设备，如果存储设备不是专用的，而是和其他I/O密集型应用共享同一磁盘，会导致ZooKeeper的效率。因为客户端请求ZNode数据变更而发生的事务，ZooKeeper会在响应之前将事务日志写入存储设备，如果存储设备是专用的，那么整个服务以至外部应用都会获得极大地性能提升。


       ZooKeeper的设计初衷是，每个ZNode只存放少量的同步数据，如果存储了大量数据，导致ZooKeeper每次节点发生变更时需要将事务写入存储设备，同时还要在集群内部复制传播，这将导致不可避免的延迟和性能问题。
所以，如果需要与大量的数据相关，可以将大量数据存储在其他设备中，而只是在ZooKeeper中存储一个简单的映射，如指针、引用等等。