运维必备：Zookeeper集群“脑裂”问题处理大全( 三 ) 本文重点分享Zookeeper脑裂问题

仲裁机制方式；

启动磁盘锁定方式。

要想避免Zookeeper"脑裂"情况其实也很简单，在follower节点切换的时候不在检查到老的Leader节点出现问题后马上切换，而是在休眠一段足够的时间，确保老的leader已经获知变更并且做了相关的shutdown清理工作了，然后再注册成为master就能避免这类问题了。
这个休眠时间一般定义为与Zookeeper定义的超时时间就够了，但是这段时间内系统可能是不可用的，但是相对于数据不一致的后果来说还是值得的。
1）ZooKeeper默认采用了Quorums这种方式来防止"脑裂"现象
即只有集群中超过半数节点投票才能选举出Leader 。
这样的方式可以确保Leader的唯一性,要么选出唯一的一个Leader ，要么选举失败。在zookeeper中Quorums作用如下：

集群中最少的节点数用来选举Leader保证集群可用；
通知客户端数据已经安全保存前集群中最少数量的节点数已经保存了该数据。一旦这些节点保存了该数据，客户端将被通知已经安全保存了，可以继续其他任务。而集群中剩余的节点将会最终也保存了该数据。

假设某个Leader假死，其余的followers选举出了一个新的Leader 。这时，旧的Leader复活并且仍然认为自己是Leader ，这个时候它向其他followers发出写请求也是会被拒绝的。
因为每当新Leader产生时，会生成一个epoch标号(标识当前属于那个Leader的统治时期) ，这个epoch是递增的， followers如果确认了新的Leader存在，知道其epoch ，就会拒绝epoch小于现任Leader epoch的所有请求。
那有没有follower不知道新的Leader存在呢？有可能，但肯定不是大多数，否则新Leader无法产生。 Zookeeper的写也遵循quorum机制，因此，得不到大多数支持的写是无效的，旧Leader即使各种认为自己是leader ，依然没有什么作用。
Zookeeper除了可以采用上面默认的Quorums方式来避免出现"脑裂" ，还可以可采用下面的预防措施：
2）添加冗余的心跳线，例如双线条线，尽量减少“裂脑”发生机会
3）启用磁盘锁
正在服务一方锁住共享磁盘， "裂脑"发生时，让对方完全"抢不走"共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动"解锁" ，另一方就永远得不到共享磁盘。
现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了"智能"锁。即正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。
4）设置仲裁机制
例如设置参考IP（如网关IP），当心跳线完全断开时， 2个节点都各自ping一下参考IP ，不通则表明断点就出在本端，不仅"心跳"、还兼对外"服务"的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。
更保险一些， ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。
作者丨散尽浮华
来源丨
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
2020 DAMS中国数据智能管理峰会即将于10月30日在上海举办，部分精彩议题先睹为快：

腾讯《腾讯游戏大数据资产管理实战：元数据管理与数据治理》
京东《京东EB级全域大数据平台建设和治理之路》
阿里《大规模容器云基础设施环境架构、管理与运维》
工商银行《DevOps转型的探索与实践》
【运维必备：Zookeeper集群“脑裂”问题处理大全】中国银联《从自研演进看分布式数据库》
民生银行《开源数据库MySQL在民生银行的应用实践》
平安银行《“传统+互联网”混合CMDB及运营中台实践》
中国联通《大数据资产管理平台的设计、研发、运营实践》
AWS《基于数据湖构建云上的数据分析架构》
今日头条《字节跳动数据治理实践》
苏宁《苏宁大规模智能告警收敛与告警根因的实践》
滴滴《万亿级消息队列Kafka在滴滴的实践》

文章插图