zookeeper 脑裂现象描述完善

Author: Snailclimb

docs/system-design/distributed-system/zookeeper/zookeeper-intro.md

@@ -1,4 +1,3 @@
-
 <!-- @import "[TOC]" {cmd="toc" depthFrom=1 depthTo=6 orderedList=false} -->
 
 <!-- code_chunk_output -->
@@ -13,7 +12,7 @@
 - [3. ZooKeeper 重要概念解读](#3-zookeeper-重要概念解读)
   - [3.1. Data model（数据模型）](#31-data-model数据模型)
   - [3.2. znode（数据节点）](#32-znode数据节点)
-    - [3.2.1. znode 4种类型](#321-znode-4种类型)
+    - [3.2.1. znode 4 种类型](#321-znode-4种类型)
     - [3.2.2. znode 数据结构](#322-znode-数据结构)
   - [3.3. 版本（version）](#33-版本version)
   - [3.4. ACL（权限控制）](#34-acl权限控制)
@@ -23,15 +22,14 @@
   - [4.1. ZooKeeper 集群角色](#41-zookeeper-集群角色)
   - [4.2. ZooKeeper 集群中的服务器状态](#42-zookeeper-集群中的服务器状态)
   - [4.3. ZooKeeper 集群为啥最好奇数台？](#43-zookeeper-集群为啥最好奇数台)
-- [5. ZAB 协议和Paxos 算法](#5-zab-协议和paxos-算法)
+- [5. ZAB 协议和 Paxos 算法](#5-zab-协议和paxos-算法)
   - [5.1. ZAB 协议介绍](#51-zab-协议介绍)
   - [5.2. ZAB 协议两种基本的模式：崩溃恢复和消息广播](#52-zab-协议两种基本的模式崩溃恢复和消息广播)
 - [6. 总结](#6-总结)
 - [7. 参考](#7-参考)
 
 <!-- /code_chunk_output -->
 
-
 ## 1. 前言
 
 相信大家对 ZooKeeper 应该不算陌生。但是你真的了解 ZooKeeper 到底有啥用不？如果别人/面试官让你给他讲讲对于 ZooKeeper 的认识，你能回答到什么地步呢？
@@ -50,7 +48,7 @@
 
 另外，本文不光会涉及到 ZooKeeper 的一些概念，后面的文章会介绍到 ZooKeeper 常见命令的使用以及使用 Apache Curator 作为 ZooKeeper 的客户端。
 
-*如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！*
+_如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！_
 
 ## 2. ZooKeeper 介绍
 
@@ -117,7 +115,7 @@ ZooKeeper 数据模型采用层次化的多叉树形结构，每个节点上都
 
 介绍了 ZooKeeper 树形数据模型之后，我们知道每个数据节点在 ZooKeeper 中被称为 **znode**，它是 ZooKeeper 中数据的最小单元。你要存放的数据就放在上面，是你使用 ZooKeeper 过程中经常需要接触到的一个概念。
 
-#### 3.2.1. znode 4种类型
+#### 3.2.1. znode 4 种类型
 
 我们通常是将 znode 分为 4 大类：
 
@@ -260,38 +258,43 @@ ZooKeeper 集群中的所有机器通过一个 **Leader 选举过程** 来选定
 ### 4.3. ZooKeeper 集群为啥最好奇数台？
 
 ZooKeeper 集群在宕掉几个 ZooKeeper 服务器之后，如果剩下的 ZooKeeper 服务器个数大于宕掉的个数的话整个 ZooKeeper 才依然可用。假如我们的集群中有 n 台 ZooKeeper 服务器，那么也就是剩下的服务数必须大于 n/2。先说一下结论，2n 和 2n-1 的容忍度是一样的，都是 n-1，大家可以先自己仔细想一想，这应该是一个很简单的数学问题了。
+
 比如假如我们有 3 台，那么最大允许宕掉 1 台 ZooKeeper 服务器，如果我们有 4 台的的时候也同样只允许宕掉 1 台。
 假如我们有 5 台，那么最大允许宕掉 2 台 ZooKeeper 服务器，如果我们有 6 台的的时候也同样只允许宕掉 2 台。
 
 综上，何必增加那一个不必要的 ZooKeeper 呢？
 
 ### 4.4. ZooKeeper 选举的过半机制防止脑裂
 
-集群脑裂：对于一个集群，通常多台机器会部署在不同机房，来提高这个集群的可用性。保证可用性的同时，会发生一种机房间网络线路故障，导致机房间网络不通，而集群被割裂成几个小集群。这时候子集群各自选主导致“脑裂”的情况。
+**何为集群脑裂？**
+
+对于一个集群，通常多台机器会部署在不同机房，来提高这个集群的可用性。保证可用性的同时，会发生一种机房间网络线路故障，导致机房间网络不通，而集群被割裂成几个小集群。这时候子集群各自选主导致“脑裂”的情况。
+
+举例说明：比如现在有一个由 6 台服务器所组成的一个集群，部署在了 2 个机房，每个机房 3 台。正常情况下只有 1 个 leader，但是当两个机房中间网络断开的时候，每个机房的 3 台服务器都会认为另一个机房的 3 台服务器下线，而选出自己的 leader 并对外提供服务。若没有过半机制，当网络恢复的时候会发现有 2 个 leader。仿佛是 1 个大脑（leader）分散成了 2 个大脑，这就发生了脑裂现象。脑裂期间 2 个大脑都可能对外提供了服务，这将会带来数据一致性等问题。
 
-举例说明：比如现在有一个由6台服务器所组成的一个集群，部署在了两个机房，每个机房三台。正常情况下只有一个leader，但是当两个机房中间网络断开的时候，每个机房的三台服务器都会认为另一个机房的三台服务器下线，而选出自己的leader并对外提供服务。若没有过半机制，当网络恢复的时候会发现有两个leader。仿佛是一个大脑（leader）分散成了两个大脑，这就发生了脑裂现象。因为脑裂期间两个大脑都可能对外提供了服务，这将会带来数据一致性等问题。
+**过半机制是如何防止脑裂现象产生的？**
 
-过半机制防止脑裂：ZooKeeper的过半机制导致不可能产生两个leader，因为少于等于一半是不可能产生leader的，这就使得不论机房的机器如何分配都不可能发生脑裂。
+ZooKeeper 的过半机制导致不可能产生 2 个 leader，因为少于等于一半是不可能产生 leader 的，这就使得不论机房的机器如何分配都不可能发生脑裂。
 
-## 5. ZAB 协议和Paxos 算法
+## 5. ZAB 协议和 Paxos 算法
 
-Paxos 算法应该可以说是  ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos算法 ，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在ZooKeeper的官方文档中也指出，ZAB协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为Zookeeper设计的崩溃可恢复的原子消息广播算法。
+Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos 算法 ，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在 ZooKeeper 的官方文档中也指出，ZAB 协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为 Zookeeper 设计的崩溃可恢复的原子消息广播算法。
 
 ### 5.1. ZAB 协议介绍
 
 ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。 在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。
 
 ### 5.2. ZAB 协议两种基本的模式：崩溃恢复和消息广播
 
-ZAB 协议包括两种基本的模式，分别是 
+ZAB 协议包括两种基本的模式，分别是
 
-- **崩溃恢复**  ：当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的Leader服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。其中，**所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致**。
-- **消息广播** ：**当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进入消息广播模式了。** 当一台同样遵守ZAB协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式：找到Leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。
+- **崩溃恢复** ：当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式。其中，**所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致**。
+- **消息广播** ：**当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进入消息广播模式了。** 当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。
 
-关于 **ZAB 协议&Paxos算法** 需要讲和理解的东西太多了，具体可以看下面这两篇文章：
+关于 **ZAB 协议&Paxos 算法** 需要讲和理解的东西太多了，具体可以看下面这两篇文章：
 
--  [图解 Paxos 一致性协议](http://codemacro.com/2014/10/15/explain-poxos/)
--  [Zookeeper ZAB 协议分析](https://dbaplus.cn/news-141-1875-1.html)
+- [图解 Paxos 一致性协议](http://codemacro.com/2014/10/15/explain-poxos/)
+- [Zookeeper ZAB 协议分析](https://dbaplus.cn/news-141-1875-1.html)
 
 ## 6. 总结