博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
ZooKeeper 03 - ZooKeeper集群的脑裂问题 (Split Brain问题)
阅读量:5370 次
发布时间:2019-06-15

本文共 2172 字,大约阅读时间需要 7 分钟。

目录

1 ZooKeeper的主从机制

Leader == Master, Follower == Slaver.

集群中的各个节点都会尝试注册为leader节点, 其他没有注册成功的则成为follower(随从)节点.

这些follower节点通过watcher(观察者)监控着leader节点:

—— ZooKeeper内部通过心跳机制来确定leader的状态, 一旦leader节点出现问题, : 就能很快获悉并迅速通知其他follower节点, 这些follower节点得知消息之后将及时采取相关操作.

2 什么是ZooKeeper的脑裂

2.1 脑裂现象的表现

ZooKeeper集群中, 各个节点间的网络通信不良时, 容易出现脑裂(split-brain)现象:

集群中的节点监听不到leader节点的心跳, 就会认为leader节点出了问题, 此时集群将分裂为不同的小集群, 这些小集群会各自选举出自己的leader节点, 导致原有的集群中出现多个leader节点.

—— 这就是脑裂现象.

2.2 为什么会出现脑裂

设想这样一种情况:

① 集群中网络通信不好, 导致心跳监测超时 —— follower认为leader节点由于某种原因挂掉了, 可其实leader节点并未真正挂掉 —— 这就是假死现象.

② leader节点假死后, ZooKeeper通知所有follower节点进行选举 ==> 某个follower节点升级为新的leader. —— 此时集群中存在2个leader节点.
③ 此时ZooKeeper需要将新leader节点的信息通知给所有的follower节点, 还要通知到所有的client(比如通过: 搭建的Solr集群中的Solr实例就是一个client), 而这个过程由于网络等环境的影响, 消息到达就会存在快慢之分.
④ 如果部分client获得了新leader节点的信息, 而部分没有获得, 而此时client向ZooKeeper发起读写请求, ZooKeeper内部的不一致就会导致: 部分client连接到了新的leader节点上, 而部分client连接到了旧的leader节点上 —— 服务中出现了2个leader, client不知道听谁的好, 就像1个大脑被分裂成2个, 很形象吧O(∩_∩)O

3 ZooKeeper如何解决"脑裂"

3.1 3种可行的思路

(1) Quorums(ˈkwɔrəm, 法定人数)法:

通过设置法定人数, 进而确定集群的容忍度, 当集群中存活的节点少于法定人数, 集群将不可用. 比如:

3个节点的集群中, Quorums = 2 —— 集群可以容忍 (3 - 2 = 1) 个节点失败, 这时候还能选举出leader, 集群仍然可用;

4个节点的集群中, Quorums = 3 —— 集群同样可以容忍 1 个节点失败, 如果2个节点失败, 那整个集群就不可用了.

(2) Redundant communications(冗余通信):

集群中采用多种通信方式, 防止一种通信方式失效导致集群中的节点无法通信.

(3) Fencing(共享资源):

通过共享资源的方式, 将所有共享资源添加到集群中, 能对共享资源进行写操作(即加锁)的节点就是leader节点.

3.2 ZooKeeper采用的方法

ZooKeeper默认采用了Quorums(法定人数)的方式: 只有获得超过半数节点的投票, 才能选举出leader.

这种方式可以确保要么选出唯一的leader, 要么选举失败.

ZooKeeper中Quorums的作用:

① 指定集群中选举leader所需的最少节点数, 保证集群可用;

② client的数据被安全保存到集群中所需的最少节点数, 一旦这些节点保存了数据, 客户端将被通知数据已经安全保存, 可以继续其他任务 —— 基于最终一致性, 集群中剩余的节点最终也会保存相关的数据.

ZooKeeper的写也遵循quorum机制, 因此得不到大多数支持的写是无效的.

3.3 ZooKeeper的具体解决思路

假设: leader发生了假死, followers选举出了一个新的leader.

当旧的leader复活并认为自己仍然是leader, 它向其他followers发出写请求时, 会被拒绝.

—— 因为ZooKeeper维护了一个叫epoch的变量, 每当新leader产生时, epoch都会递增, followers如果确认了新的leader存在, 同时也会知道其epoch的值 —— 它们会拒绝epoch小于现任leader的epoch的所有旧leader的任何请求.

注意: 仍然会存在有部分followers不知道新leader的存在, 但肯定不是大多数, 否则新leader将无法产生.

参考资料

版权声明

作者:

出处: 博客园

您的支持是对博主的极大鼓励, 感谢您的阅读.

本文版权归博主所有, 欢迎转载, 但请保留此段声明, 并在文章页面明显位置给出原文链接, 否则博主保留追究相关人员法律责任的权利.

转载于:https://www.cnblogs.com/shoufeng/p/10591526.html

你可能感兴趣的文章
HDU - 4284 Travel(floyd+状压dp)
查看>>
1027 制作表格
查看>>
面向对象的介绍与特性
查看>>
typing-python用于类型注解的库
查看>>
20189215 2018-2019-2 《密码与安全新技术专题》第13周作业
查看>>
第四周作业
查看>>
一、HTML基础
查看>>
蓝牙进阶之路 (002) - HC-05与HC-06的AT指令的区别(转)
查看>>
mysql的limit经典用法及优化
查看>>
C#后台程序与HTML页面中JS方法互调
查看>>
mysql 同一个表中 字段a 的值赋值到字段b
查看>>
antiSMASH数据库:微生物次生代谢物合成基因组簇查询和预测
查看>>
UNICODE与ANSI的区别
查看>>
nginx 配置实例
查看>>
Flutter - 创建底部导航栏
查看>>
ASP.NET MVC 教程-MVC简介
查看>>
SQL Server索引 - 聚集索引、非聚集索引、非聚集唯一索引 <第八篇>
查看>>
转载:详解SAP TPM解决方案在快速消费品行业中的应用
查看>>
Android OpenGL ES 开发(N): OpenGL ES 2.0 机型兼容问题整理
查看>>
项目中用到的技术及工具汇总(持续更新)
查看>>