zookeeper脑裂解决方案总结

zookeeper脑裂解决方案:

避免这种情况其实也很简单,在slaver切换的时候不在检查到老的master出现问题后马上切换,而是在休眠一段足够的时间,确保老的master已经获知变更并且做了相关的shutdown清理工作了然后再注册成为master就能避免这类问题了,这个休眠时间一般定义为与zookeeper定义的超时时间就够了,但是这段时间内系统可能是不可用的,但是相对于数据不一致的后果我想还是值得的。
当然最彻底的解决这类问题的方案是将master HA集群做成peer2peer的,屏蔽掉外部Zookeeper的依赖。每个节点都是对等的没有主次,这样就不会存在脑裂的问题,但是这种ha解决方案需要使用两阶段,paxos这类数据一致性保证协议来实现,不可避免的会降低系统数据变更的系统,如果系统中主要是对master的读取操作很少更新就很适合了。


为了避免出现脑裂,可采用下面的预防措施: 

添加冗余的心跳线,例如双线条线。尽量减少“裂脑”发生机会。 
启用磁盘锁。正在服务一方锁住共享磁盘,“裂脑”发生时,让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题,如果占用共享盘的一方不主动“解锁”,另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃,就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即,正在服务的一方只在发现心跳线全部断开(察觉不到对端)时才启用磁盘锁。平时就不上锁了。 


设置仲裁机制。例如设置参考IP(如网关IP),当心跳线完全断开时,2个节点都各自ping一下 参考IP,不通则表明断点就出在本端,不仅“心跳”、还兼对外“服务”的本端网络链路断了,即使启动(或继续)应用服务也没有用了,那就主动放弃竞争,让能够ping通参考IP的一端去起服务。更保险一些,ping不通参考IP的一方干脆就自我重启,以彻底释放有可能还占用着的那些共享资源。




你可能感兴趣的:(zookeeper)