<div style="margin: 0px auto; color: rgb(85, 85, 85); max-width: 23cm; padding: 1em;"><div style="margin: 0px; padding: 0px;">
<div style="padding:8px;"><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;">io多线程</h3>
<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>
<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集群中的数据呀，它是不会产生更改的，只是外壳换了一家商铺而已。</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的集群。
其实在很早以前，晚期的redis版本是没有集群这个概念的，你须要实现集群得依附一些中间件，比方codis，还有twemproxy。redis集群概念是在3.0开始引入的，它是自带的分布式存储计划，是一个去中心化的集群，叫做Redis Cluster，是由多个主从节点独特存在的一个模式，个别以3主3从为比拟经典的模式，当然多主多从也能够。其中master负责读写申请以及整个集群信息的保护，slave只做他所对应的主节点数据和状态信息的复制。
Redis Cluster
对于集群，有两点须要留神
- 之前咱们聊过主从模式，能够做读写拆散，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集群 - hash slot 算法
下面的传统形式是很古老的，我已经也见识过一次，咱们理解一下就行了。当初都应用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集群中的数据呀，它是不会产生更改的，只是外壳换了一家商铺而已。
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原理。
Redis集群数据迁徙
已有数据的单节点的redis如何扩大为集群
搭建集群的时候，包革除节点中现有的aof以及rdb文件，那么如果当初原本就是单节点，那么如何扩大为集群呢？并且要保证数据不失落。其实原理就是把rdb或者aof文件保留当前，再导入，而后通过slot来调配。具体步骤如下：
如上图，其原理就是slot迁徙。整个过程阻塞，网站服务不对外提供服务。如果应用自建集群，那么运维老本很高，个别采纳云redis的话会更好。哪怕阿里云，也会在配置变更的时候呈现网络中断的状况。