zookeeper 脑裂现象描述完善

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

-
 <!-- @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,7 +22,7 @@
   - [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-总结)
@@ -31,7 +30,6 @@
 
 <!-- /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,6 +258,7 @@ 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 台。
 
@@ -267,15 +266,19 @@ ZooKeeper 集群在宕掉几个 ZooKeeper 服务器之后，如果剩下的 ZooK
 
 ### 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 协议介绍
 
@@ -283,15 +286,15 @@ ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服
 
 ### 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. 总结