Redis学习(10)之Redis主从集群(2)

古城微笑少年丶 2024-03-26 12:54 60阅读 0赞

#### 文章目录 ####

*  零 主从集群上篇文章参看
 *  一 CAP理论
 *   *  1.1 CAP概念
     *  1.2 CAP定理
     *  1.3 BASE 理论
     *  1.4 CAP 的应用
 *  二 Raft 算法
 *   *  2.1 Raft算法简介
     *  2.2 角色、任期及角色转变
     *  2.3 leader 选举
     *   *  2.3.1 follower要参加选举
         *  2.3.2 follower被要求投票
         *  2.3.3 Candidate等待响应
         *  2.3.4 选举时机
     *  2.4 数据同步
     *   *  2.4.1 状态机
     *  2.5 处理流程
     *   *  2.5.1 AP 支持
     *  2.6 脑裂情况探究
     *   *  2.6.1 情况一——不确定是否形成脑裂情形
         *  2.6.2 情况二——形成脑裂情形
         *  2.6.3 情况三——不形成脑裂情形
         *  2.6.4 情况四——不形成脑裂情形
         *  2.6.5 情况五——不形成脑裂情形
     *  2.7 Leader 宕机处理
     *   *  2.7.1 请求到达前 Leader 挂掉
         *  2.7.2 未开始同步数据前 Leader 挂掉
         *  2.7.3 同步完部分后 Leader 挂掉
         *  2.7.4 commit 通知发出后 Leader 挂掉
         *  2.7.5 总结
         *  2.7.6 Raft算法动画演示

## 零 主从集群上篇文章参看 ##

*  [Redis学习【10】之Redis主从集群(1)][Redis_10_Redis_1]

## 一 CAP理论 ##

### 1.1 CAP概念 ###

*  CAP 定理指的是在一个分布式系统中，**一致性 Consistency、可用性 Availability、分区容错性 Partition tolerance**，三者不可兼得。
    
     *  \*\*一致性（C）：分布式系统中多个主机之间是否能够保持数据一致的特性。\*\*即当系统数据发生更新操作后，各个主机中的数据仍然处于一致的状态。
     *  **可用性（A）：系统提供的服务必须一直处于可用的状态**。即对于用户的每一个请求，系统总是可以在有限的时间内对用户做出响应。
     *  **分区容错性（P）：分布式系统在遇到任何网络分区故障时，仍能够保证对外提供满足一致性和可用性的服务。**

### 1.2 CAP定理 ###

*  CAP 定理：**对于分布式系统，网络环境相对是不可控的，出现网络分区是不可避免的，因此系统必须具备分区容错性。但系统不能同时保证一致性与可用性。即要么 CP，要么 AP。**

### 1.3 BASE 理论 ###

*  **BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写**。
    
     *  **基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。**
     *  **软状态：指允许系统数据存在的中间状态，并认为该中间状态的存在不会影响系统的整体可用性。** 即允许系统主机间进行数据同步的过程存在一定延时。软状态，其实就是一种灰度状态，过渡状态。
     *  **最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。** 因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要保证系统数据的**实时一致性**
     *  **实时一致性：要求数据内容一旦发生更新，客户端立刻可以访问到最新的数据。** 所以，在集群环境下该特性是无法实现的，只存在于单机环境中。
     *  **最终一致性：数据内容发生更新后，经过一小段时间后，客户端可以访问到最新的数据。** 实时一致性与最终一致性两个概念是从客户端访问到一致性内容的时间角度来说的，**单从客户端访问到的内容角度来说（不说时间问题），还有两个概念：**
        
         *  **强一致性（严格一致性）：要求客户端访问到的一定是更新过的新数据**
         *  **弱一致性：允许客户端从集群不同节点访问到的数据是不一致的**

>  *  BASE 是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于 CAP 定理逐步演化而来的。

*  **BASE 理论的核心思想：即使无法做到强一致性，但每个系统都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。**

### 1.4 CAP 的应用 ###

<table> 
 <thead> 
  <tr> 
   <th>CAP的应用</th> 
   <th>特点</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Zookeeper</td> 
   <td>Zookeeper 遵循的是 CP 模式，即保证一致性，但牺牲可用性。</td> 
  </tr> 
  <tr> 
   <td>Consul</td> 
   <td>Consul 遵循的是 CP 模式，即保证了一致性，但牺牲了可用性。</td> 
  </tr> 
  <tr> 
   <td>Redis</td> 
   <td>Redis 遵循的是 AP 模式，即保证了可用性，但牺牲了一致性。</td> 
  </tr> 
  <tr> 
   <td>Eureka</td> 
   <td>Eureka 遵循的是 AP 模式，即保证了可用性，但牺牲了一致性。</td> 
  </tr> 
  <tr> 
   <td>Nacos 与 CAP</td> 
   <td>Nacos 在做注册中心时，默认是 AP 的。但其也支持 CP 模式，但需要用户提交请求进行转换。</td> 
  </tr> 
 </tbody> 
</table>

*  以Zookeeper的CP模式进行简单解说
    
     *  当 Leader 节点中的数据发生了变化后，在 Follower 还没有同步完成之前，整个 Zookeeper集群是不对外提供服务的。如果此时有客户端来访问数据，则客户端会因访问超时而发生重试。由于 Leader 的选举非常快，所以这种重试对于用户来说几乎是感知不到的。所以说，Zookeeper 保证了一致性，但牺牲了可用性。

## 二 Raft 算法 ##

### 2.1 Raft算法简介 ###

*  **Raft 算法是一种通过对日志复制管理来达到集群节点一致性的算法。** 日志复制管理发生在集群节点中的 Leader 与 Followers 之间，Raft 通过选举出的 Leader 节点负责管理日志复制过程，以实现各个节点间数据的一致性。

### 2.2 角色、任期及角色转变 ###

![在这里插入图片描述][7da269e156224c0183fa9d7eb0b10b4c.png]

*  在 Raft 中，节点有三种角色：
    
     *  **Leader：唯一负责处理客户端写请求的节点；也可以处理客户端读请求；同时负责日志复制工作**
     *  **Candidate：Leader 选举的候选人，其可能会成为 Leader。是一个选举中的过程角色**
     *  **Follower：可以处理客户端读请求；负责同步来自于 Leader 的日志；当接收到其它Cadidate 的投票请求后可以进行投票；当发现 Leader 挂了，其会转变为 Candidate 发起Leader 选举**

### 2.3 leader 选举 ###

#### 2.3.1 follower要参加选举 ####

*  若 follower 在心跳超时范围内没有接收到来自于 leader 的心跳，则认为 leader 挂了。此时其首先会使其本地 term 增一。然后 follower 会完成以下步骤：
    
     *  此时若接收到了其它 candidate 的投票请求，则会将选票投给这个 candidate
     *  由 follower 转变为 candidate
     *  若之前尚未投票，则向自己投一票
     *  向其它节点发出投票请求，然后等待响应

#### 2.3.2 follower被要求投票 ####

*  follower 在接收到投票请求后，其会根据以下情况来判断是否投票：
    
     *  发来投票请求的 candidate 的 term 不能小于我的 term
     *  在我当前 term 内，我的选票还没有投出去
     *  若接收到多个 candidate 的请求，我将采取 first-come-first-served 方式投票

#### 2.3.3 Candidate等待响应 ####

*  当一个 Candidate 发出投票请求后会等待其它节点的响应结果。这个响应结果可能有三种情况：
    
     *  收到过半选票，成为新的 leader。然后会将消息广播给所有其它节点，本服务器是新的 Leader
     *  接收到别的 candidate 发来的新 leader 通知，比较发现新 leader 的 term 并不比自己的 term小，则转变为 follower
     *  经过一段时间后，没有收到过半选票，也没有收到新 leader 通知，则重新发出选举

#### 2.3.4 选举时机 ####

*  在很多时候，当 Leader 真的挂了，Follower 几乎同时会感知到，所以它们几乎同时会变为 candidate 发起新的选举。此时就可能会出现较多 candidate 票数相同的情况，即无法选举出 Leader。
 *  为了防止这种情况的发生，Raft 算法其采用了 `randomized election timeouts` 策略来解决这个问题。其会为这些 Follower 随机分配一个选举发起时间 `election timeout`，这个 `timeout`在 `150-300ms` 范围内。只有到达了 election timeout 时间的 Follower 才能转变为 candidate，否则等待。那么 election timeout 较小的 Follower 则会转变为 candidate 然后先发起选举，一般情况下其会优先获取到过半选票成为新的 leader。

### 2.4 数据同步 ###

*  在 Leader 选举出来的情况下，通过日志复制管理实现集群中各节点数据的同步。

#### 2.4.1 状态机 ####

![在这里插入图片描述][cfd866f5d31f4c08974e6b1a42a51344.png]

*  Raft 算法一致性的实现，是基于日志复制状态机的。状态机的最大特征是，不同 Server中的状态机若当前状态相同，然后接受了相同的输入，则一定会得到相同的输出。

### 2.5 处理流程 ###

![在这里插入图片描述][39ff731956354ed8a00fa2edbb9455c5.png]

#### 2.5.1 AP 支持 ####

![在这里插入图片描述][3a053a237a4f4306b36b4032eda1cf78.png]

*  **Log 由 term index、log index 及 command 构成。为了保证可用性，各个节点中的日志可以不完全相同，但 leader 会不断给 follower 发送 box，以使各个节点的 log 最终达到相同。即 raft 算法不是强一致性的，而是最终一致的。**

### 2.6 脑裂情况探究 ###

*  Raft 集群存在脑裂问题。在多机房部署中，由于网络连接问题，很容易形成多个分区。而多分区的形成，很容易产生脑裂，从而导致数据不一致。
 *  由于三机房部署的容灾能力最强，所以生产环境下，三机房部署是最为常见的。**下面以三机房部署为例进行分析，根据机房断网情况，可以分为五种情况：**

#### 2.6.1 情况一——不确定是否形成脑裂情形 ####

![在这里插入图片描述][5d0f6f323d064cbbb8feb69da428a49d.png]

*  情形一出现脑裂：若新leader出现在B机房，则B与C可以正常对外提供服务。此时，A机房也存在Leader，但不能处理写操作请求，所以形成脑裂。
 *  情形二无脑裂：若新leader出现在C机房，A机房中的leader则会自动下线，所以不会形成脑裂。

--------------------

*  详细探究出现脑裂的情况：
    
     *  这种情况下，B 机房中的主机是感知不到 Leader 的存在的，所以 B 机房中的主机会发起新一轮的 Leader 选举。由于 B 机房与 C 机房是相连的，虽然 C 机房中的 Follower 能够感知到 A 机房中的 Leader，但由于其接收到了更大 term 的投票请求，所以 C 机房的 Follower也就放弃了 A 机房中的 Leader，参与了新 Leader 的选举。
     *  **若新 Leader 出现在 B 机房，A 机房是感知不到新 Leader 的诞生的，其不会自动下线，所以会形成脑裂。但由于 A 机房 Leader 处理的写操作请求无法获取到过半响应，所以无法完成写操作。但 B 机房 Leader 的写操作处理是可以获取到过半响应的，所以可以完成写操作。故A 机房与 B、C 机房中出现脑裂，且形成了数据的不一致。**

#### 2.6.2 情况二——形成脑裂情形 ####

![在这里插入图片描述][94fa471f86684ad0895234d9b9100ed1.png]

*  该情形下，无论新leader出现在B还是C机房，一定形成脑裂。
 *  形成脑裂详解：
    
     *  无论新leader出现在B还是C机房，他们都可以对外正常服务，但此时的A机房也存在Leader，故出现脑裂。A机房只能提供读操作请求服务。

#### 2.6.3 情况三——不形成脑裂情形 ####

![在这里插入图片描述][64e86d3f182640bd9e7a0fca158d09ec.png]

*  A、C 可以正常对外提供服务，但 B 无法选举出新的 Leader。由于 B 中的主机全部变为了选举状态，所以无法提供任何服务，没有形成脑裂

#### 2.6.4 情况四——不形成脑裂情形 ####

![在这里插入图片描述][e0fcc08bface49929d218bb37b96e3a1.png]

*  A、B、C 均可以对外提供服务，不受影响

#### 2.6.5 情况五——不形成脑裂情形 ####

![在这里插入图片描述][bbc418d10bd04e9ca4ec883db4884dc0.png]

*  A 机房无法处理写操作请求，但可以对外提供读服务。
 *  B、C 机房由于失去了 Leader，均会发起选举，但由于均无法获取过半支持，所以均无法选举出新的 Leader。故不会形成脑裂

### 2.7 Leader 宕机处理 ###

#### 2.7.1 请求到达前 Leader 挂掉 ####

*  client 发送写操作请求到达 Leader 之前 Leader 就挂了，因为请求还没有到达集群，所以这个请求对于集群来说就没有存在过，对集群数据的一致性没有任何影响。Leader 挂了之后，会选举产生新的 Leader。
 *  **由于 Stale Leader 并未向 client 发送成功处理响应，所以 client 会重新发送该写操作请求**。

#### 2.7.2 未开始同步数据前 Leader 挂掉 ####

*  client 发送写操作请求给 Leader，请求到达 Leader 后，Leader 还没有开始向 Followers发出数据 Leader 就挂了。这时集群会选举产生新的 Leader。Stale Leader 重启后会作为Follower 重新加入集群，并同步新 Leader 中的数据以保证数据一致性。**之前接收到 client 的数据被丢弃。**
 *  **由于 Stale Leader 并未向 client 发送成功处理响应，所以 client 会重新发送该写操作请求。**

#### 2.7.3 同步完部分后 Leader 挂掉 ####

*  client 发送写操作请求给 Leader，Leader 接收完数据后向所有 Follower 发送数据。在部分 Follower 接收到数据后 Leader 挂了。由于 Leader 挂了，就会发起新的 Leader 选举。
    
     *  若 Leader 产生于已完成数据接收的 Follower，其会继续将前面接收到的写操作请求转换为日志，并写入到本地状态机，并向所有 Flollower 发出询问。**在获取过半同意响应后会向所有 Followers 发送 commit 指令，同时向 client 进行响应。**
     *  若 Leader 产生于尚未完成数据接收的 Follower，那么原来已完成接收的 Follower 则会放弃曾接收到的数据。**由于 client 没有接收到响应，所以 client 会重新发送该写操作请求。**

#### 2.7.4 commit 通知发出后 Leader 挂掉 ####

*  client 发送写操作请求给 Leader，Leader 也成功向所有 Followers 发出的 commit 指令，并向 client 发出响应后，Leader 挂了。
 *  由于 Stale Leader 已经向 client 发送成功接收响应，且 commit 通知已经发出，说明这个写操作请求已经被 server 成功处理。

--------------------

#### 2.7.5 总结 ####

<table> 
 <thead> 
  <tr> 
   <th>情形</th> 
   <th>影响</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>请求到达前 Leader 挂掉</td> 
   <td>请求未被接收到，重新提交请求</td> 
  </tr> 
  <tr> 
   <td>未开始同步数据前 Leader 挂掉</td> 
   <td>请求被丢弃，重新提交请求</td> 
  </tr> 
  <tr> 
   <td>同步完部分后 Leader 挂掉</td> 
   <td>两种结果：一种写操作成功，一切正常运行。另一种写操作失败，重新提交请求</td> 
  </tr> 
  <tr> 
   <td>commit 通知发出后 Leader 挂掉</td> 
   <td>操作已被成功执行，无影响</td> 
  </tr> 
 </tbody> 
</table>

#### 2.7.6 Raft算法动画演示 ####

*  Raft 算法的动画，其非常清晰全面地演示了 Raft 算法的工作原理。
 *  该动画的地址为[Raft算法中文动画演示][Raft]
 *  [github源码源码下载地址][github]
 *  [csdn下载传送][csdn]

--------------------

*  提示：同志们一定要动手！！！很有益于理解Raft算法的各个过程！！！

[Redis_10_Redis_1]: https://blog.csdn.net/yang2330648064/article/details/129137290?spm=1001.2014.3001.5501
[7da269e156224c0183fa9d7eb0b10b4c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/79b20e01920d42bdbf0176a1ff191658.png
[cfd866f5d31f4c08974e6b1a42a51344.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/2fbb4d234a3443abb1f3b78f0d1eb417.png
[39ff731956354ed8a00fa2edbb9455c5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/c9aba63c23ef41f8b90620c1eebfc102.png
[3a053a237a4f4306b36b4032eda1cf78.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/d684d0217cb54bc9895991128112af80.png
[5d0f6f323d064cbbb8feb69da428a49d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/9f0834ead9d743deb552b7d03c4d5dbd.png
[94fa471f86684ad0895234d9b9100ed1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/6f97fc5c23244129b8d46bf08f0c2c21.png
[64e86d3f182640bd9e7a0fca158d09ec.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/f1bdda63aaf249d2b5414b37d41bcff5.png
[e0fcc08bface49929d218bb37b96e3a1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/11bd9da19cbf4defa15736b01c120d49.png
[bbc418d10bd04e9ca4ec883db4884dc0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/9450a9d92adb40caa94d3c143feaaf5e.png
[Raft]: http://www.kailing.pub/raft/index.html
[github]: https://github.com/klboke/raft-animation
[csdn]: https://download.csdn.net/download/yang2330648064/87484901