Zookeeper已经分布式环境中的假死脑裂

原创 2015年11月18日 17:33:01

Zookeeper简介


在上班之前都不知道有这样一个东西,在开始说假死脑裂之前先说说Zookeeper吧。

Zookeeper
zookeeper是一个分布式应用程序的协调服务。它是一个为分布式应用提供一致性服务的软件,提供的性能包括:配置维护、名字服务、分布式同步、组服务等。
zookeeper是以Fast Paxos算法为基础,paxos算法存在活锁的问题,即当有多个proposer交错提交时,有可能互相排斥导致没有一个proposer能提交成功,而Fase Paxos作了一些优化,通过选举产生一个leader,只有leader才能提交proposer,具体的可以看一下Fast Paxos算法。

Zookeeper的基本运转流程:

  1. 选举leader;
  2. 同步数据;
  3. 选举leader过程中算法有很多,但要达到的选举标准是一致的;
  4. leader要有更高的zxid;
  5. 集群中大多数的机器得到响应并follow选出的leader。

小说了一下Zookeeper,接下来讨论一下脑裂,假死等等问题以及解决方法吧。


假死脑裂
在一个大的集群中往往会有一个master的存在,在长期运行过程中不可避免会出现宕机等等的问题导致master不可用,在出现这样的情况以后往往会对系统产生很大的影响,所以一般的分布式集群中的master都采用了高可用的解决方案来避免这样的情况发生。
master-slaver方式,存在一个master的节点,平时对外服务,同时有一个slaver节点来监控master,监控的同时有某种方式来进行数据同步。假如现在master挂掉了,slaver能很快获知并且迅速切换为新的master。但是在这种方式中,监控切换是一个很大的难题,但是现在Zookeeper的watch和分布式锁机制能比较好的解决这个问题。虽然Zookeeper很好的解决了这个问题,但是它的使用也存在其他的问题,比如脑裂。
导致脑裂的一个根源问题就是假死。


什么叫假死呢?
有一个很重要的问题,就是到底是根据一个什么样的情况来判断一个节点死亡down掉了。
在分布式系统中这些都是有监控者来判断的,但是监控者也很难判定其他的节点的状态,唯一一个可靠的途径就是心跳,包括Zookeeper也是使用心跳来判断客户端是否仍然活着。
使用ZooKeeper来做master HA基本都是同样的方式,每个节点都尝试注册一个象征master的临时节点其他没有注册成功的则成为slaver,并且通过watch机制监控着master所创建的临时节点,Zookeeper通过内部心跳机制来确定master的状态,一旦master出现意外Zookeeper能很快获悉并且通知其他的slaver,其他slaver在之后作出相关反应。这样就完成了一个切换。这种模式也是比较通用的模式,基本大部分都是这样实现的,但是这里面有个很严重的问题,如果注意不到会导致短暂的时间内系统出现脑裂,因为心跳出现超时可能是master挂了,但是也可能是master,zookeeper之间网络出现了问题,也同样可能导致。这种情况就是假死,master并未死掉,但是与ZooKeeper之间的网络出现问题导致Zookeeper认为其挂掉了然后通知其他节点进行切换,这样slaver中就有一个成为了master,但是原本的master并未死掉,这时候client也获得master切换的消息,但是仍然会有一些延时,zookeeper需要通讯需要一个一个通知,这时候整个系统就很混乱可能有一部分client已经通知到了连接到新的master上去了,有的client仍然连接在老的master上如果同时有两个client需要对master的同一个数据更新并且刚好这两个client此刻分别连接在新老的master上,就会出现很严重问题。

是什么原因导致这样情况的出现呢?
主要原因是Zookeeper集群和Zookeeper client判断超时并不能做到完全同步,也就是说可能一前一后,如果是集群先于client发现那就会出现上面的情况。同时,在发现并切换后通知各个客户端也有先后快慢。一般出现这种情况的几率很小,需要master与Zookeeper集群网络断开但是与其他集群角色之间的网络没有问题,还要满足上面那些情况,但是一旦出现就会引起很严重的后果,数据不一致。

如何避免?
在slaver切换的时候不在检查到老的master出现问题后马上切换,而是在休眠一段足够的时间,确保老的master已经获知变更并且做了相关的shutdown清理工作了然后再注册成为master就能避免这类问题了,这个休眠时间一般定义为与Zookeeper定义的超时时间就够了,但是这段时间内系统不可用了。

高可用方案之脑裂问题探讨

关于脑裂我们先来看看红帽的文档是如何解释的What does “split-brain” mean?“Split brain” is a condition whereby two or more c...
  • zhengzhihust
  • zhengzhihust
  • 2016年12月03日 15:15
  • 1679

zookeeper难以理解易混淆的几点

zookeeper难以理解易混淆的几点:           (一)zk自身主备策略 zk的选举值2n+1多数投票通过才选举为主(自身软件,信号量最大为主,和锁的获得算法无关,zk自身的...
  • y666666y
  • y666666y
  • 2017年04月17日 16:10
  • 1175

知识库--ZooKeeper+Quorums+脑裂+为什么机器数为奇数(59)

ZooKeeper Quorums In quorum mode, ZooKeeper replicates its data tree across all servers in the ense...
  • qfzhangwei
  • qfzhangwei
  • 2016年12月24日 23:30
  • 1091

zookeeper入门系列-概述

zookeeper可谓是目前使用最广泛的分布式组件了。其功能和职责单一但却非常重要。 在现今这个年代,介绍zookeeper的书和文章可谓多如牛毛,本人不才,在这边试图通过自己的理解来介绍zookee...
  • liweisnake
  • liweisnake
  • 2017年04月01日 10:44
  • 3283

ceph存储 分布式系统设计系列 -- 基本原理及高可用策略

     “分布式系统设计”系列第一篇文章,这篇文章主要介绍一些入门的概念和原理,后面带来一些高可用、数据分布的实践方法!! ==> 分布式系统中的概念 ==> 分布式系统与单节点的...
  • skdkjxy
  • skdkjxy
  • 2016年02月25日 14:04
  • 2171

集群脑裂问题分析

1.什么是集群脑裂集群的脑裂通常是发生在集群中部分节点之间不可达而引起的(或者因为节点请求压力较大,导致其他节点与该节点的心跳检测不可用)。当上述情况发生时,不同分裂的小集群会自主的选择出master...
  • CWeeYii
  • CWeeYii
  • 2017年05月16日 23:19
  • 4423

glusterfs双副本原理解析和脑裂解决方案

1.双副本介绍 1.1 什么是双副本? 1.2 双副本的优越性 1.3 双副本的缺陷   2.Glusterfs双副本在虚拟化中的应用 3.Glusterfs双副本实现过程 3.1 同步写操作 1...
  • lblxyh
  • lblxyh
  • 2014年11月07日 16:18
  • 4401

为什么不应该使用ZooKeeper做服务发现

本文作者通过ZooKeeper与Eureka作为 Service发现服务(注:WebServices 体系中的UDDI就是个发现服务)的优劣对比,分享了Knewton在云计算平台部署服务的经验。本文...
  • jenny8080
  • jenny8080
  • 2016年09月06日 11:29
  • 5361

zookeeper难以理解易混淆的几点

zookeeper难以理解易混淆的几点:           (一)zk自身主备策略 zk的选举值2n+1多数投票通过才选举为主(自身软件,信号量最大为主,和锁的获得算法无关,zk自身的...
  • y666666y
  • y666666y
  • 2017年04月17日 16:10
  • 1175

知识库--ZooKeeper+Quorums+脑裂+为什么机器数为奇数(59)

ZooKeeper Quorums In quorum mode, ZooKeeper replicates its data tree across all servers in the ense...
  • qfzhangwei
  • qfzhangwei
  • 2016年12月24日 23:30
  • 1091
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Zookeeper已经分布式环境中的假死脑裂
举报原因:
原因补充:

(最多只允许输入30个字)