关于redis:慕课网20210129-Redis6直播笔记-下多线程哈希slot集群

5次阅读

共计 11534 个字符，预计需要花费 29 分钟才能阅读完成。

<p> 以前的 redis 是单线程模型，其实就是多路复用机制，晓得多路复用的来一波 6，咱们在架构师课程中讲过，那么 netty 也有，看过老师相干课程的也应该晓得。这里不多说了。</p>

<p>Redis6 开始有了 IO 读写多线程，只不过执行用户的命令和晚期版本也是一样的，都是单线程执行，所以线程平安。</p>

<p> 咱们先来看一下老版本的单线程：

</p>

<p> 首先读取客户端的命令，读取后执行命令，而后回写给客户端，这个就是一组命令的执行，因为单线程平安，他们会一组一组的去进行执行。</p>

<p> 他们的读写命令以及执行命令都是在一个线程中执行的，这个线程在 redis6 中称之为主线程。</p>

<p> 在这里咱们能够回顾一下 netty 的 reactor 的线程模型，也就是多路复用。

你能够把这个单线程了解为是一个人，他是酒吧会所的接待员，在门口接待了当前，而后还要领到外面去一个一个的款待他们。</p>

<p> 咱们能够关上 redis.conf 配置文件，看一下：

默认状况下，是依照老版本的样子，如果要应用多线程，那么开启即可，这里的 io-threads 就是设置多线程的数量，开启多线程后，整体的性能要比单线程要更高。</p>

<p>io-threads设置的数量最大不倡议超过 8，晋升的空间不大。另外线程数和服务器的硬件配置也是有关系的。比方 4 核 8g，那么倡议设置 2 或者 3，如果 8 核倡议设置 6 或者 7，因为肯定要预留，万事兜底万事保底，这一点和 nginx 的配置也是同样的情理。</p>

<p> 假如当初 io-threads 设置为 4，那么他的模型就如下：

</p>

<p> 那么在这里，读用户的命令以及执行命令都是在一个线程中执行的，而后写操作是多线程执行。在这里如果比作是一个银行的话，那么 读操作 相当于是门口的保安，给你测个体温，执行 就是店里的大堂经理，会带你去取号，多个 写操作 就是窗口的办事人员。</p>

<p> 能够参考一下图：

刚刚咱们举例是只有一个人在接待和款待，这个时候接待只有一个人，他只在门口把客人带进外面，外面会有专门的多个招待员来解决这些客人的申请。</p>

<h3 style=”font-family: "PT Sans Narrow", sans-serif; font-weight: 700; line-height: 1.1em; color: rgb(133, 153, 0); font-size: 1.4em;”> 读操作能不能设置多线程呢？</h3>

<p>

如果想要读操作也变成多线程读的话，那么 io-threads-do-reads 能够开启，设置为 yes 就行。这个时候他的模型就是上面这张图：

</p>

<p> 只不过官网阐明，这个多线程读开启的意义不大，不会帮忙很多的。

这个时候，还是引入刚刚的例子，客人多了，生意好了，门口的接待员减少了，那么两边接待和款待都是多个员工在解决客人了。</p>

<p> 那么在这里阐明一点，多线程只针对数据的读写以及协定的解析。真正用户端的命令执行还是单线程，所以是线程平安的。</p>

<h3 style=”font-family: "PT Sans Narrow", sans-serif; font-weight: 700; line-height: 1.1em; color: rgb(133, 153, 0); font-size: 1.4em;”>Redis 集群原理 </h3>

<p></p>

<p> 其实只有波及到中间件，那么必定会有集群的概念，一方面为了高可用，一方面为了达到程度扩容，那么这次来讲一下 redis 的集群。</p>

<p> 其实在很早以前，晚期的 redis 版本是没有集群这个概念的，你须要实现集群得依附一些中间件，比方 codis，还有 twemproxy。redis 集群概念是在 3.0 开始引入的，它是自带的分布式存储计划，是一个去中心化的集群，叫做 Redis Cluster，是由多个主从节点独特存在的一个模式，个别以 3 主 3 从为比拟经典的模式，当然多主多从也能够。其中 master 负责读写申请以及整个集群信息的保护，slave 只做他所对应的主节点数据和状态信息的复制。</p>

<h3 style=”font-family: "PT Sans Narrow", sans-serif; font-weight: 700; line-height: 1.1em; color: rgb(133, 153, 0); font-size: 1.4em;”>Redis Cluster</h3>

<p> 对于集群，有两点须要留神 </p>

<ul>
<li> 之前咱们聊过主从模式，能够做读写拆散，redis 集群尽管是 3 主 3 从，也有主从的概念，然而咱们并不会做读写拆散，读写都是交给 master 去解决，数据会同步给 slave，如果集群做读写拆散一方面没有意义一方面 slave 就没有容错机制了，这一点是须要留神。</li>
<li> 此外还有一点，单节点的 redis 默认有 16 个 db，然而在集群模式下，这些 db 都交融了，没有 db 库的概念，他是一片汪洋大海。</li>
</ul>

<p> 依照单节点，主从，哨兵来说的话，redis 始终都能够说是单库，数据存储量是有下限的，你的服务器节点内存有多大，那么这个就是存储下限。一旦达到存储下限，redis 就会进行缓存 key 的自我淘汰机制。很显著，这种形式面对海量数据的时候并不太好，哪怕你买 1 个 t 内存的，也总有一天会达到存储瓶颈，所以任何分布式系统咱们都要思考一个程度扩容机制，这个 redis 集群就能够做到。扩容的同时也满足高可用机制。</p>

<p> 同时，应用集群之后，数据其实进行了分片，多个 master 节点都可能提供读写服务，这样整体集群的响应能力就要比原先单节点来的更好。并且，在集群模式下，任意节点产生故障时，集群还是能够持续对外提供服务，主节点有故障转移的性能。</p>

<h3 style=”font-family: "PT Sans Narrow", sans-serif; font-weight: 700; line-height: 1.1em; color: rgb(133, 153, 0); font-size: 1.4em;”> 传统的程度扩容 </h3>

<p> 传统晚期的 redis 扩容计划其实是基于业务层的，在业务层进行 redis 的宰割，能够扩容，能够集群隔离。

咱们之前讲过 redis 主从，以这个为例，当然用哨兵也能够，咱们能够手动来实现 redis 的扩容，先看下图：

</p>

<p> 上图中的 3 主 3 从其实是由 3 个主从 redis 形成的，用户在进行 set 或者 get 的时候，首先须要对 key 做哈希，哈希后的值对节点数求模，取模的值就是数据路由到某个主从库里，就针对这个主从库去做 set 和 get 的操作，这个哈希原理其实和 nginx 的 ip_hash 情理是一样的，数据库分库也是这个情理。目标就是依据 key 哈希后的后果去寻址找到最终他的存储地位去存值或取值。这个其实就是 哈希取模。</p>

<p> 那么哈希以及寻址的这个过程须要本人在业务层去封装实现，然而实质目标就曾经达到了横向扩容，假如每个主从容量是 8g，那么目前总容量就是 24g，想怎么扩容间接加机器就行。

</p>

<p> 这这样的状况之下，那么扩容会带来一个弊病，这个弊病也就是哈希取模带来的，一旦有节点宕机或者减少节点，那么就须要从新哈希和求模运算，这么一来会影响所有的缓存数据，这个时候所有数据会从新路由，影响会很大，怎么解决呢？能够应用一致性哈希算法，就是小局部数据受影响，这个咱们在架构班里有提到过的吧。</p>

<h3 style=”font-family: "PT Sans Narrow", sans-serif; font-weight: 700; line-height: 1.1em; color: rgb(133, 153, 0); font-size: 1.4em;”> 一致性哈希 </h3>

<p>

首先他会有一个域，这个域很长，有 2 的 32 次方减 1，哈希不仅针对 key，也会针对服务器节点，咱们这里是 redis，如果是服务器集群那么情理也是一样。

</p>

<h3 style=”font-family: "PT Sans Narrow", sans-serif; font-weight: 700; line-height: 1.1em; color: rgb(133, 153, 0); font-size: 1.4em;”>Redis 集群 – hash slot 算法 </h3>

<p> 下面的传统形式是很古老的，我已经也见识过一次，咱们理解一下就行了。当初都应用 redis cluster，这种模式下，redis 能够有多个 master 节点，每个 master 节点下又能够对应 1~n 个 slave 节点，这样会造成一个多主多从的集群模式，这种模式下不再须要向下面讲过的那样须要在业务层去解决，redis 本身帮咱们做好了存取的过程，咱们能够不必过多关注业务过程就能够间接应用和利用了。他本身是基于 hash slot 的算法来存值的，不论是哪种算法，其实实质为了解决的就是数据分布的问题。</p>

<p>redis 集群其实是把数据分片了，因为他有多个 master 独特形成，他会分数据，他有一个 hash slot 算法，也能够称之为哈希槽，每个槽上寄存了一些数据，slot 的范畴是 0~16384，redis 对 key 的存取会有一个 CRC16 的算法，失去的值，在对 16384 做取模，最终判断该 key 应该在哪个 slot 中进行存取，实质和服务器节点数取模是一样的，只不过 redis cluster 的 slot 算法更精妙，老本更低廉。</p>

<p> 以三主三从为例，这个时候的 slot 总数会均匀等份，使得每个 master 节点中都会有 slot，目前 3 个的话那就是{0..5461}{5462..10922}{10923..16383}，这个取值区间在搭建好集群之后是能够看到的。</p>

<p> 如果这个时候，集群环境减少或者缩小节点，slot 能够从新迁徙或者合并，那么 slot 中的缓存 key 其实还是存在的，如此一来，节点宕机或者新增就不会造成缓存失落了。这就相当于家里房子拆迁，我到新家里当前，会把我的私人物品家具啊电器啊一起携带过来，货色跟着人走，货色就是缓存 key，人就 slot，服务器节点是 redis 实例，比拟灵便。并不是说你房子没了，家里的货色就没了。

发问：搬家的过程，新家能住人吗？

当然，你搬家并不是马上就能实现的，搬家须要耗时，须要期待，所以期待期间你的家具啊电器啊不可用。redis slot 也是这样，宕机的时候，那局部须要迁徙的 slot 是不可用，会有一个短暂的迁徙的过程，期待迁徙实现之后，能力为用户提供读写服务。</p>

<p>hash slot 图示：

</p>

<p> 如下图：两头的 master 宕机了，slot 会迁徙到 slave

</p>

<p> 如果，新增 master 节点，重新分配，那么会把一些 slot 迁徙过来，缓存数据不变，跟着 slot 走，尽管 slot 会变动到其余的 master 节点，然而数据 key 哈希的时候，还是会到跟着固定的 slot。</p>

<p> 如果还不能了解，那就再举个栗子，格子铺，每个格子归属一个卖家，这个卖家把各自托管给某些商铺，由他们代经营，如果商铺开张，格子还是存在的，他能够把各自带着走，各自里的商品就是 redis 集群中的数据呀，它是不会产生更改的，只是外壳换了一家商铺而已。</p>

<h3 style=”font-family: "PT Sans Narrow", sans-serif; font-weight: 700; line-height: 1.1em; color: rgb(133, 153, 0); font-size: 1.4em;”>Redis 集群搭建 </h3>

<p> 工夫关系，咱们在这里就只讲原理了，操作局部，咱们提供了慕课网的手记文档，很简略，大家能够去看一下就行。

链接地址：https://www.imooc.com/article…</p>

<p> 只不过在集群中有一些留神点，咱们大抵总结了如下：</p>

<ol>
<li><p> 读写都是在 master，slave 退出集群，会进行数据同步，连贯集群中的任意主或从节点去读写数据，都会依据 key 哈希取模后路由到某个 master 节点去解决。slave 不提供读写服务，只会同步数据。</p></li>
<li><p> 敞开任意一主，会导致局部写操作失败，是因为从节点不能执行写操作，在 Slave 降级为 Master 期间可能会有大量的失败。</p></li>
<li><p> 敞开从节点对于整个集群没有影响 </p></li>
<li><p> 某个主节点和他麾下的所有从节点全副挂掉，咱们集群就进入 faill 状态，不可用。因为 slot 不残缺。</p></li>
<li><p> 如果集群超过半数以上 master 挂掉，无论他们是否有对应 slave，集群进入 fail 状态，因为无奈选举。</p></li>
<li><p> 如果集群中的任意 master 宕机，且此 master 没有 slave。集群不可用。（同 3）</p></li>
<li><p> 投票选举过程是集群中所有 master 参加，如果半数以上 master 节点与 master 节点通信超时(cluster-node-timeout)，认为以后 master 节点挂掉。</p></li>
<li><p> 选举只会针对某个 master 下的所有 slave 选举，而不是对所有全量的 slave 选举。</p></li>
<li><p> 原先的 master 从新复原连贯后，他会成为新 master 的从服务器。因为主从同步，客户端的写入命令，有可能会失落。redis 并非强一致性，因为主从个性，所以最初一部分数据会失落。这也合乎 CAP 实践。</p></li>
<li><p> 集群只实现了主节点的故障转移；从节点故障时只会被下线，不会进行故障转移。因而，应用集群时，个别不会应用读写拆散技术，因为从节点故障会导致读服务不可用，可用性变差了。所以不要在集群里做读写拆散。</p></li>
</ol>

<p> 须要留神，为了保障集群的完整性，只有当 16384 个槽 slot 齐全的全副调配结束，集群才能够上线。而且，如果主节点产生故障转移，并且处于故障转移过程中还未实现时，原主节点的槽 slot 不会在任何节点中，集群会处于下线状态，客户端无奈调用。CAP 原理。</p>

<h3 style=”font-family: "PT Sans Narrow", sans-serif; font-weight: 700; line-height: 1.1em; color: rgb(133, 153, 0); font-size: 1.4em;”>Redis 集群数据迁徙 </h3>

<h3 style=”font-family: "PT Sans Narrow", sans-serif; font-weight: 700; line-height: 1.1em; color: rgb(133, 153, 0); font-size: 1.4em;”> 已有数据的单节点的 redis 如何扩大为集群 </h3>

<p> 搭建集群的时候，包革除节点中现有的 aof 以及 rdb 文件，那么如果当初原本就是单节点，那么如何扩大为集群呢？并且要保证数据不失落。其实原理就是把 rdb 或者 aof 文件保留当前，再导入，而后通过 slot 来调配。具体步骤如下：

如上图，其原理就是 slot 迁徙。整个过程阻塞，网站服务不对外提供服务。如果应用自建集群，那么运维老本很高，个别采纳云 redis 的话会更好。哪怕阿里云，也会在配置变更的时候呈现网络中断的状况。

</p>
</div>
</div>

</div>### io 多线程

以前的 redis 是单线程模型，其实就是多路复用机制，晓得多路复用的来一波 6，咱们在架构师课程中讲过，那么 netty 也有，看过老师相干课程的也应该晓得。这里不多说了。

Redis6 开始有了 IO 读写多线程，只不过执行用户的命令和晚期版本也是一样的，都是单线程执行，所以线程平安。

咱们先来看一下老版本的单线程：

首先读取客户端的命令，读取后执行命令，而后回写给客户端，这个就是一组命令的执行，因为单线程平安，他们会一组一组的去进行执行。

他们的读写命令以及执行命令都是在一个线程中执行的，这个线程在 redis6 中称之为主线程。

在这里咱们能够回顾一下 netty 的 reactor 的线程模型，也就是多路复用。

你能够把这个单线程了解为是一个人，他是酒吧会所的接待员，在门口接待了当前，而后还要领到外面去一个一个的款待他们。

咱们能够关上 redis.conf 配置文件，看一下：

默认状况下，是依照老版本的样子，如果要应用多线程，那么开启即可，这里的 io-threads 就是设置多线程的数量，开启多线程后，整体的性能要比单线程要更高。

io-threads设置的数量最大不倡议超过 8，晋升的空间不大。另外线程数和服务器的硬件配置也是有关系的。比方 4 核 8g，那么倡议设置 2 或者 3，如果 8 核倡议设置 6 或者 7，因为肯定要预留，万事兜底万事保底，这一点和 nginx 的配置也是同样的情理。

假如当初 io-threads 设置为 4，那么他的模型就如下：

那么在这里，读用户的命令以及执行命令都是在一个线程中执行的，而后写操作是多线程执行。在这里如果比作是一个银行的话，那么 读操作 相当于是门口的保安，给你测个体温，执行 就是店里的大堂经理，会带你去取号，多个 写操作 就是窗口的办事人员。

能够参考一下图：

刚刚咱们举例是只有一个人在接待和款待，这个时候接待只有一个人，他只在门口把客人带进外面，外面会有专门的多个招待员来解决这些客人的申请。

如果想要读操作也变成多线程读的话，那么 io-threads-do-reads 能够开启，设置为 yes 就行。这个时候他的模型就是上面这张图：

只不过官网阐明，这个多线程读开启的意义不大，不会帮忙很多的。

这个时候，还是引入刚刚的例子，客人多了，生意好了，门口的接待员减少了，那么两边接待和款待都是多个员工在解决客人了。

那么在这里阐明一点，多线程只针对数据的读写以及协定的解析。真正用户端的命令执行还是单线程，所以是线程平安的。

其实只有波及到中间件，那么必定会有集群的概念，一方面为了高可用，一方面为了达到程度扩容，那么这次来讲一下 redis 的集群。

其实在很早以前，晚期的 redis 版本是没有集群这个概念的，你须要实现集群得依附一些中间件，比方 codis，还有 twemproxy。redis 集群概念是在 3.0 开始引入的，它是自带的分布式存储计划，是一个去中心化的集群，叫做 Redis Cluster，是由多个主从节点独特存在的一个模式，个别以 3 主 3 从为比拟经典的模式，当然多主多从也能够。其中 master 负责读写申请以及整个集群信息的保护，slave 只做他所对应的主节点数据和状态信息的复制。

对于集群，有两点须要留神

之前咱们聊过主从模式，能够做读写拆散，redis 集群尽管是 3 主 3 从，也有主从的概念，然而咱们并不会做读写拆散，读写都是交给 master 去解决，数据会同步给 slave，如果集群做读写拆散一方面没有意义一方面 slave 就没有容错机制了，这一点是须要留神。
此外还有一点，单节点的 redis 默认有 16 个 db，然而在集群模式下，这些 db 都交融了，没有 db 库的概念，他是一片汪洋大海。

依照单节点，主从，哨兵来说的话，redis 始终都能够说是单库，数据存储量是有下限的，你的服务器节点内存有多大，那么这个就是存储下限。一旦达到存储下限，redis 就会进行缓存 key 的自我淘汰机制。很显著，这种形式面对海量数据的时候并不太好，哪怕你买 1 个 t 内存的，也总有一天会达到存储瓶颈，所以任何分布式系统咱们都要思考一个程度扩容机制，这个 redis 集群就能够做到。扩容的同时也满足高可用机制。

同时，应用集群之后，数据其实进行了分片，多个 master 节点都可能提供读写服务，这样整体集群的响应能力就要比原先单节点来的更好。并且，在集群模式下，任意节点产生故障时，集群还是能够持续对外提供服务，主节点有故障转移的性能。

传统晚期的 redis 扩容计划其实是基于业务层的，在业务层进行 redis 的宰割，能够扩容，能够集群隔离。
咱们之前讲过 redis 主从，以这个为例，当然用哨兵也能够，咱们能够手动来实现 redis 的扩容，先看下图：

上图中的 3 主 3 从其实是由 3 个主从 redis 形成的，用户在进行 set 或者 get 的时候，首先须要对 key 做哈希，哈希后的值对节点数求模，取模的值就是数据路由到某个主从库里，就针对这个主从库去做 set 和 get 的操作，这个哈希原理其实和 nginx 的 ip_hash 情理是一样的，数据库分库也是这个情理。目标就是依据 key 哈希后的后果去寻址找到最终他的存储地位去存值或取值。这个其实就是 哈希取模。

那么哈希以及寻址的这个过程须要本人在业务层去封装实现，然而实质目标就曾经达到了横向扩容，假如每个主从容量是 8g，那么目前总容量就是 24g，想怎么扩容间接加机器就行。

这这样的状况之下，那么扩容会带来一个弊病，这个弊病也就是哈希取模带来的，一旦有节点宕机或者减少节点，那么就须要从新哈希和求模运算，这么一来会影响所有的缓存数据，这个时候所有数据会从新路由，影响会很大，怎么解决呢？能够应用一致性哈希算法，就是小局部数据受影响，这个咱们在架构班里有提到过的吧。

首先他会有一个域，这个域很长，有 2 的 32 次方减 1，哈希不仅针对 key，也会针对服务器节点，咱们这里是 redis，如果是服务器集群那么情理也是一样。

下面的传统形式是很古老的，我已经也见识过一次，咱们理解一下就行了。当初都应用 redis cluster，这种模式下，redis 能够有多个 master 节点，每个 master 节点下又能够对应 1~n 个 slave 节点，这样会造成一个多主多从的集群模式，这种模式下不再须要向下面讲过的那样须要在业务层去解决，redis 本身帮咱们做好了存取的过程，咱们能够不必过多关注业务过程就能够间接应用和利用了。他本身是基于 hash slot 的算法来存值的，不论是哪种算法，其实实质为了解决的就是数据分布的问题。

redis 集群其实是把数据分片了，因为他有多个 master 独特形成，他会分数据，他有一个 hash slot 算法，也能够称之为哈希槽，每个槽上寄存了一些数据，slot 的范畴是 0~16384，redis 对 key 的存取会有一个 CRC16 的算法，失去的值，在对 16384 做取模，最终判断该 key 应该在哪个 slot 中进行存取，实质和服务器节点数取模是一样的，只不过 redis cluster 的 slot 算法更精妙，老本更低廉。

以三主三从为例，这个时候的 slot 总数会均匀等份，使得每个 master 节点中都会有 slot，目前 3 个的话那就是{0..5461}{5462..10922}{10923..16383}，这个取值区间在搭建好集群之后是能够看到的。

如果这个时候，集群环境减少或者缩小节点，slot 能够从新迁徙或者合并，那么 slot 中的缓存 key 其实还是存在的，如此一来，节点宕机或者新增就不会造成缓存失落了。这就相当于家里房子拆迁，我到新家里当前，会把我的私人物品家具啊电器啊一起携带过来，货色跟着人走，货色就是缓存 key，人就 slot，服务器节点是 redis 实例，比拟灵便。并不是说你房子没了，家里的货色就没了。

发问：搬家的过程，新家能住人吗？
当然，你搬家并不是马上就能实现的，搬家须要耗时，须要期待，所以期待期间你的家具啊电器啊不可用。redis slot 也是这样，宕机的时候，那局部须要迁徙的 slot 是不可用，会有一个短暂的迁徙的过程，期待迁徙实现之后，能力为用户提供读写服务。

hash slot 图示：

如下图：两头的 master 宕机了，slot 会迁徙到 slave

如果，新增 master 节点，重新分配，那么会把一些 slot 迁徙过来，缓存数据不变，跟着 slot 走，尽管 slot 会变动到其余的 master 节点，然而数据 key 哈希的时候，还是会到跟着固定的 slot。

如果还不能了解，那就再举个栗子，格子铺，每个格子归属一个卖家，这个卖家把各自托管给某些商铺，由他们代经营，如果商铺开张，格子还是存在的，他能够把各自带着走，各自里的商品就是 redis 集群中的数据呀，它是不会产生更改的，只是外壳换了一家商铺而已。

工夫关系，咱们在这里就只讲原理了，操作局部，咱们提供了慕课网的手记文档，很简略，大家能够去看一下就行。
链接地址：https://www.imooc.com/article/313301

只不过在集群中有一些留神点，咱们大抵总结了如下：

读写都是在 master，slave 退出集群，会进行数据同步，连贯集群中的任意主或从节点去读写数据，都会依据 key 哈希取模后路由到某个 master 节点去解决。slave 不提供读写服务，只会同步数据。
敞开任意一主，会导致局部写操作失败，是因为从节点不能执行写操作，在 Slave 降级为 Master 期间可能会有大量的失败。
敞开从节点对于整个集群没有影响
某个主节点和他麾下的所有从节点全副挂掉，咱们集群就进入 faill 状态，不可用。因为 slot 不残缺。
如果集群超过半数以上 master 挂掉，无论他们是否有对应 slave，集群进入 fail 状态，因为无奈选举。
如果集群中的任意 master 宕机，且此 master 没有 slave。集群不可用。（同 3）
投票选举过程是集群中所有 master 参加，如果半数以上 master 节点与 master 节点通信超时(cluster-node-timeout)，认为以后 master 节点挂掉。
选举只会针对某个 master 下的所有 slave 选举，而不是对所有全量的 slave 选举。
原先的 master 从新复原连贯后，他会成为新 master 的从服务器。因为主从同步，客户端的写入命令，有可能会失落。redis 并非强一致性，因为主从个性，所以最初一部分数据会失落。这也合乎 CAP 实践。
集群只实现了主节点的故障转移；从节点故障时只会被下线，不会进行故障转移。因而，应用集群时，个别不会应用读写拆散技术，因为从节点故障会导致读服务不可用，可用性变差了。所以不要在集群里做读写拆散。

须要留神，为了保障集群的完整性，只有当 16384 个槽 slot 齐全的全副调配结束，集群才能够上线。而且，如果主节点产生故障转移，并且处于故障转移过程中还未实现时，原主节点的槽 slot 不会在任何节点中，集群会处于下线状态，客户端无奈调用。CAP 原理。

搭建集群的时候，包革除节点中现有的 aof 以及 rdb 文件，那么如果当初原本就是单节点，那么如何扩大为集群呢？并且要保证数据不失落。其实原理就是把 rdb 或者 aof 文件保留当前，再导入，而后通过 slot 来调配。具体步骤如下：

如上图，其原理就是 slot 迁徙。整个过程阻塞，网站服务不对外提供服务。如果应用自建集群，那么运维老本很高，个别采纳云 redis 的话会更好。哪怕阿里云，也会在配置变更的时候呈现网络中断的状况。

正文完