脑裂

文章目录 1.ZooKeeper的主从机制 2 什么是ZooKeeper的脑裂 2.1 脑裂现象的表现 2.2 为什么会出现脑裂 3 ZooKeeper如何解决"脑裂" 3.1 3种可行的思路 3.2 ZooKeeper采用的方法 3.3 ZooKeeper的具体解决思路 参考资料 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

一 集群环境下的一些特殊问题 1.1 并发控制 在集群环境中， 关键数据通常是共享存放的，比如放在共享磁盘上。 而各个节点的对数据有相同的访问权限， 这时就必须有某种机制能够控制节点对数据的访问。 Oracle RAC 是利用DLM(Distribute Lock Management) 机制来进行多个实例间的并发控制。 1.2 健忘症(Amnesia) 集群环境配置文件不是集中存放的，而是每个节点都有一个本地副本，在集群正常运行时，用户可以在任何节点更改集群的配置，并且这种更改会自动同步到其他节点。 有一种特殊情况： 节点A 正常关闭， 在节点B上修改配置， 关闭结点B，启动结点A。 这种情况下，修改的配置文件是丢失的， 就是所谓的健忘症。 1.3 脑裂(Split Brain) 在集群中，节点间通过某种机制(心跳)了解彼此的健康状态，以确保各节点协调工作。 假设只有"心跳"出现问题， 各个节点还在正常运行， 这时，每个节点都认为其他的节点宕机了， 自己是整个集群环境中的"唯一建在者"，自己应该获得整个集群的"控制权"。 在集群环境中，存储设备都是共享的， 这就意味着数据灾难， 这种情况就是"脑裂" 解决这个问题的通常办法是使用投票算法(Quorum Algorithm). 它的算法机理如下： 集群中各个节点需要心跳机制来通报彼此的"健康状态"，假设每收到一个节点的"通报

关于集群中的"脑裂"问题，之前已经 在这里 详细介绍过，下面重点说下Zookeeper脑裂问题的处理办法。脑裂通常会出现在集群环境中，比如ElasticSearch、Zookeeper集群，而这些集群环境有一个统一的特点，就是它们有一个大脑，比如ElasticSearch集群中有Master节点，Zookeeper集群中有Leader节点。 一、zookeeper 集群的节点为什么要部署成奇数 zookeeper容错指的是：当宕掉几个zookeeper节点服务器之后，剩下的个数必须大于宕掉的个数，也就是剩下的节点服务数必须大于n/2，这样zookeeper集群才可以继续使用，无论奇偶数都可以选举leader。例如5台zookeeper节点机器最多宕掉2台，还可以继续使用，因为剩下3台大于5/2。 那么为什么最好为奇数个节点呢？ 是在以最大容错服务器个数的条件下，会节省资源 。比如，最大容错为2的情况下，对应的zookeeper服务数，奇数为5，而偶数为6，也就是6个zookeeper服务的情况下最多能宕掉2个服务，所以从节约资源的角度看，没必要部署6（偶数）个zookeeper服务节点。 zookeeper集群有这样一个特性： 集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。 也就是说如果有2个zookeeper节点，那么只要有1个zookeeper节点死了

历史优质文章： 可能是最漂亮的Spring事务管理详解 面试中关于Java虚拟机（jvm）的问题看这篇就够了 Java NIO 概览 分布式系统设计理念 分布式系统架构的第一原则是不要分布！这句话看似矛盾实则揭露了分布式系统的很多特征。 分布式系统的目标与要素 分布式系统的目标是提升系统的整体性能和吞吐量另外还要尽量保证分布式系统的容错性（假如增加10台服务器才达到单机运行效果2倍左右的性能，那么这个分布式系统就根本没有存在的意义）。 即使采用了分布式系统，我们也要尽力运用并发编程、高性能网络框架等等手段提升单机上的程序性能。 分布式系统设计两大思路：中心化和去中心化 1）中心化设计： 两个角色： 中心化的设计思想很简单，分布式集群中的节点机器按照角色分工，大体上分为两种角色： “领导” 和 “干活的” 角色职责： “领导”通常负责分发任务并监督“干活的”，发现谁太闲了，就想发设法地给其安排新任务，确保没有一个“干活的”能够偷懒，如果“领导”发现某个“干活的”因为劳累过度而病倒了，则是不会考虑先尝试“医治”他的，而是一脚踢出去，然后把他的任务分给其他人。其中微服务架构 Kubernetes 就恰好采用了这一设计思路。 中心化设计的问题 ： 中心化的设计存在的最大问题是“领导”的安危问题，如果“领导”出了问题，则群龙无首，整个集群就奔溃了。但我们难以同时安排两个“领导”以避免单点问题