1. 为什么选择奇数台机器部署zookeeper集群:
关于ZooKeeper,需要明确一个很重要的特性:集群中只要有过半的机器是正常工作的,那么整个集群对外就是可用的,即过半存活即可用。
部署奇数台机器可以充分利用集群中的每个节点提供容灾能力。
如果想搭建一个能够允许F台机器down掉的集群,那么就要部署一个由2xF+1 台机器构成的ZK集群。
通常都建议尝试跨机房部署。
2. Server的自检恢复
ZK运行过程中,如果出现一些无法处理的异常,会直接退出进程,也就是所谓的快速失败(fail fast)模式。
由于zookeeper具有过半存活即可用的特性,使得集群中少数机器down掉后,整个集群还是可以对外正常提供服务的。另外,这些down掉的机器重启之后,能够自动加入到集群中,并且自动和集群中其它机器进行状态同步(主要就是从Leader那里同步最新的数据),从而达到自我恢复的目的。
因此,我们很容易就可以想到,是否可以借助一些工具来自动完成机器的状态检测与重启工作。回答是肯定的,这里推荐两个工具: Daemontools(http://cr.yp.to/daemontools.html) 和 SMF(http://en.wikipedia.org/wiki/Service_Management_Facility),能够帮助你监控ZK进程,一旦进程退出后,能够自动重启进程,从而使down掉的机器能够重新加入到集群中去。
3. syncLimit参数设定了允许一个跟随者与领导者进行同步的时间。
如果在设定的时间段内,一个跟随者未能完成同步,它将会自己重启。所有关联到这个跟随者的客户端将连接到另外一个跟随者。
4. initLimit参数设定了允许所有跟随者与领导者进行连接并同步的时间。
如果在设定的时间段内,半数以上的跟随者未能完成同步,领导者便会宣布放弃领导地位,然后进行另外一次领导者选举。
如果这种情况经常发生(可以通过日志中的记录发现这种情况),则表明设定的值太小。
5. 设置Java heap 大小
避免内存与磁盘空间的交换,能够大大提升ZK的性能,设置合理的heap大小则能有效避免此类空间交换的触发。
通常在一个物理内存为4G的机器上,最多设置-Xmx为3G。