`
flylynne
  • 浏览: 373721 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

ZooKeeper的脑裂的出现和解决方案

 
阅读更多

出现:

       在搭建hadoop的HA集群环境后,由于两个namenode的状态不一,当active的namenode由于网络等原因出现假死状态,standby接收不到active的心跳,因此判断active的namenode宕机,但实际上active并没有死亡。此时standby的namenode就会切换成active的状态,保证服务能够正常使用。若原来的namenode复活,此时在整个集群中就出现2个active状态的namenode,该状态成为脑裂。脑裂现象可能导致这2个namenode争抢资源,从节点不知道该连接哪一台namenode,导致节点的数据不统一,这在企业生产中是不可以容忍的。

 

在使用zookeeper的过程中,我们经常会看到这样一些说法:

1.zookeeper cluster的节点数目必须是奇数。

2.zookeeper 集群中必须超过半数节点(Majority)可用,整个集群才能对外可用。

这个说法在大多数情况下是正确的。

实际上ZooKeeper提供了几种方式来认定整个集群是否可用,Majority只是其中的一种。

(http://zookeeper.apache.org/doc/r3.3.5/zookeeperInternals.html)

1. Majority Quorums

2. Weight

3. Hierarchy of groups

所谓整个集群是否可用,隐含的一个意思就是整个集群还能够选举出一个”Leader”。

ZooKeeper默认设置的是采用Majority Qunroms的方式来支持Leader选举。在ZooKeeper中Quorums有2个作用:

1. 集群中最少的节点数用来选举Leader保证集群可用

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

采用Quoroms投票的方式来选举Leader主要是为了解决“Split-Brain”问题( http://linux-ha.org/wiki/Split_Brain)。

Split-Brain问题说的是1个集群如果发生了网络故障,很可能出现1个集群分成了两部分,而这两个部分都不知道对方是否存活,不知道到底是网络问题还是直接机器down了,所以这两部分都要选举1个Leader,而一旦两部分都选出了Leader, 并且网络又恢复了,那么就会出现两个Brain的情况,整个集群的行为不一致了。

所以集群要防止出现Split-Brain的问题出现,Quoroms是一种方式,即只有集群中超过半数节点投票才能选举出Leader。

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

ZooKeeper默认采用了这种方式。更广义地解决Split-Brain的问题,一般有3种方式:

 

解决方案:

      1、添加心跳线。

            原来两个namenode之间只有一条心跳线路,此时若断开,则接收不到心跳报告,判断对方已经死亡。此时若有2条心跳线路,一条断开,另一条仍然能够接收心跳报告,能保证集群服务正常运行。2条心跳线路同时断开的可能性比1条心跳线路断开的小得多。再有,心跳线路之间也可以HA(高可用),这两条心跳线路之间也可以互相检测,若一条断开,则另一条马上起作用。正常情况下,则不起作用,节约资源。

      2、启用磁盘锁。

            由于两个active会争抢资源,导致从节点不知道该连接哪一台namenode,可以使用磁盘锁的形式,保证集群中只能有一台namenode获取磁盘锁,对外提供服务,避免数据错乱的情况发生。但是,也会存在一个问题,若该namenode节点宕机,则不能主动释放锁,那么其他的namenode就永远获取不了共享资源。因此,在HA上使用"智能锁"就成为了必要措施。"智能锁"是指active的namenode检测到了心跳线全部断开时才启动磁盘锁,正常情况下不上锁。保证了假死状态下,仍然只有一台namenode的节点提供服务。

 

 3、设置仲裁机制

            脑裂导致的后果最主要的原因就是从节点不知道该连接哪一台namenode,此时如果有一方来决定谁留下,谁放弃就最好了。因此出现了仲裁机制,比如提供一个参考的IP地址,当出现脑裂现象时,双方接收不到对方的心跳机制,但是能同时ping参考IP,如果有一方ping不通,那么表示该节点网络已经出现问题,则该节点需要自行退出争抢资源的行列,或者更好的方法是直接强制重启,这样能更好的释放曾经占有的共享资源,将服务的提供功能让给功能更全面的namenode节点。

分享到:
评论

相关推荐

    分布式协调服务-zookeeper1

    作为一个分布式数据一致性解决方案,Zookeeper提供了一系列功能,如数据发布/订阅(配置中心,如Disconf)、负载均衡(Dubbo利用Zookeeper实现)、命名服务、主节点选举(例如在Kafka、Hadoop、HBase中)、分布式...

    从PAXOS到ZOOKEEPER分布式一致性原理与实践

    为了更好地理解和应用ZooKeeper,你可以阅读《zookeeper电子参考书》,这本书详细介绍了ZooKeeper的原理、设计、使用方法以及常见问题的解决方案。通过学习,你不仅可以掌握分布式一致性理论,还能具备实际操作和...

    一文理解Kafka重复消费的原因和解决方案.docx

    ### Kafka重复消费的原因及其解决方案 #### 一、Kafka消费者相关配置解析 为了更好地理解Kafka中的重复消费问题,我们首先需要了解与消费者相关的几个重要配置参数。 1. **enable.auto.commit**: 这个参数控制着...

    patrnoi祥解

    标题:“patrnoi祥解”和“PostgreSQL高可用性解决方案Patroni与Zookeeper/Etcd的实践” 描述:本文件详细介绍了Patroni结合Zookeeper或Etcd来实现PostgreSQL数据库高可用性(HA)的方案,且该实现无需root用户权限...

    分布式集群之后台商品管理.doc

    在文档中提到的Dubbox是基于Dubbo的分布式服务框架,它提供了高性能的RPC(远程过程调用)解决方案和服务治理。Dubbox适合在分布式环境中使用,以实现服务间的通信和管理。 综上所述,此项目利用SpringBoot搭建了一...

    大数据面试宝典2023整理

    ZooKeeper 章节涵盖了 ZooKeeper 的选举机制、脑裂问题解决方案、客户端对服务器集群的轮训机制等方面的知识点。 大数据面试宝典2023整理涵盖了大数据领域的多个方面的知识点,是一本非常实用的面试指南。

    1000道 互联网大厂面试题.pdf

    27. **ZAB和Paxos算法**:ZAB算法和Paxos算法都是用来解决分布式一致性问题的,但两者在算法设计和实现上有所差异。 28. **应用场景**:ZooKeeper广泛应用于分布式锁、配置管理、集群管理等。 ### Dubbo面试知识点...

    2022最新大数据面试宝典.pdf

    可以通过使用 ZooKeeper 来解决脑裂问题,ZooKeeper 会选出一个活动的 NameNode 节点。 8.小文件过多会有什么危害,如何避免: 小文件过多会导致 NameNode 节点的压力增加,影响 HDFS 的性能。可以通过使用文件...

    配hadoopHA最怕就是配置文件错了

    在Hadoop分布式计算环境中,高可用性...博客链接中的内容可能更具体地介绍了配置过程中的问题和解决方案,访问链接可以获取更多实际操作经验。在实践过程中,务必耐心细致,遵循最佳实践,以确保Hadoop HA的顺利实施。

    服务端各类面试题合集.pdf

    Dubbo和SpringCloud都是针对分布式系统的解决方案,但它们的诞生背景和关注点有所不同。Dubbo起源于SOA(Service-Oriented Architecture,面向服务架构)时代,主要聚焦于服务的调用、流量分发、监控和熔断等核心...

    主转

    除此之外,Java的并发和网络编程库如Netty和Akka也可以用于构建自定义的主从切换解决方案。开发者需要了解线程安全、网络通信以及分布式一致性算法,如Paxos或Raft,以确保在主节点故障时能够平滑过渡到新的主节点。...

Global site tag (gtag.js) - Google Analytics