过半机制如何避免Zookeeper集群脑裂
布式系统里, 脑裂是个会让人头疼的难题。集群当中, 节点因网络故障彼此失联, 可又各自觉得自己是“老大”啦, 这时数据一致性就会被完全破坏掉。Zookeeper作为分布式协调服务的基础, 其过半机制正是对抗脑裂的关键武器呢按通俗讲, 过半机制要求任何决策都得获得超过半数节点同意, 这个看似简单的规则, 背后藏着巧妙的容错逻辑呀。
过半机制如何切断脑裂风险
本质是“少数服从多数”的过半机制, 其精妙之处在于, 它能天然地阻止分裂的集群同时出现合法领导者。在Zookeeper里, 选举Leader时, 一个节点要成为Leader, 必须获得超过半数的投票。这表明, 要是集群有5个节点，一个节点起码得有3票才能胜出。当网络分区出现时, 像2个节点在一个子网, 3个节点在另一个子网这种情况, 只有拥有3个节点的子网才可满足过半条件, 进而选举出唯一的Leader。仅有2个节点构成的子网, 始终都没办法达成3票, 进而也就没办法产生Leader。这样的设计直接就杜绝了“两个子网分别各自选出一个Leader”的那种脑裂场景。
在实际进行运维过程当中, 有不少工程师会将一个细节给忽略掉, 那就是过半机制有这样的要求, 即集群的总节点数量一定得是奇数才行。要是使用偶数个节点, 就像有4个节点这种情况下, 其中一个子网会有2个节点, 而另一个子网同样也会有2个节点, 两边各自都没办法获取到3票, 如此一来整个集群就会陷入到“无Leader”的那种僵局状态, 进而致使服务完全没办法正常使用。所以说, 常见的Zookeeper集群规模是3、5、7这类奇数, 这样既能确保容错性, 又能够避免出现脑裂现象。
过半机制失效时该如何处理
虽说过半机制设计得颇为精巧, 然而在极端情形之下, 依旧有可能遭遇挑战。举例而言, 网络分区持续存在, 致使拥有多数节点的子网长时间运行, 而少数节点遭到隔离。在这个时候, 少数节点尽管无法当选为Leader, 却依旧在运行旧的数据副本, 要是分区恢复之后这些节点被重新加入到集群当中, 它们的数据或许已然过时了。解决这个问题, Zookeeper借助ZAB协议的日志同步机制, 先把最新的事务日志由Leader广播给所有Follower, 只有在过半Follower确认写入之后, 事务才被当作提交。这一点确保了即便少数节点恢复过来, 它们能主动从Leader拉取缺失的日志, 而非自行宣称成为Leader。