搞定人气最高的缓存中间件-Redis

1、Redis的理解

Redis是C语言开发的基于内存的高性能键值对的NoSQL数据库。一般架设于java程序和DB之间用作缓存层，为了防止DB磁盘IO效率过低造成请求阻塞、响应缓慢的问题，用来弥补DB和Java程序之间的性能差距。同时也可以在DB吞吐跟不上系统并发量时，避免请求直接落入数据库，起到保护DB的作用。
Redis除了用作于缓存数据，还有丰富的数据类型，可以实现一些其他功能。例如：计数器，统计用户在线，排行榜，附近的人等等。官网数据显示Redis能达到10W/S的QPS处理，正常项目开发情况时可以达到7W/S左右的QPS和TPS。

2、Redis的数据类型

数据类型	特性	应用场景
String	可以存储任何元素	计数器，分布式锁，字符缓存，token信息，限流
Hash	适合存储对象，可以将对象属性一个个存储，更新时也可以单个更新	对象缓存，购物车
List	双向链表，增删快	栈，队列，消息队列，消息推送，阻塞队列
Set	元素不重复，增删查复杂度都是O(1)，提供求交集，差集，并集的操作	抽奖活动，朋友圈点赞关注
Sort Set	有序集合，元素不重复，基于分数进行排序，分数相同按照key的ascii值排序	排行榜，商品评价标签（好评，中评，差评）
BitMap	在字符串类型上定义的位操作	在线用户统计，用户访问统计等
HyperLogLog	用于基数统计	统计当月用户访问量
Geospatial	存储用户地理位置信息，并对这些信息进行操作	地理位置计算，附近的人

PS：HyperLogLog的优点是输入元素的数量或者体积非常非常的大时，计算基数所需的空间总是固定的，并且很小，只需要花费12KB内存，就能计算接近2^64个不同元素的基数。pfadd命令不会一次性分配12KB内存，会随着基数的增加逐渐增大，pfmerge命令合并后占用的存储空间是12KB，无论合并之前的数量是多大
redis内部是使用RedisObject来表示所有的key和value，如下图：

主要有三个属性：type，encoding，prt。

2.1 RedisObject怎么表示String(编码方式的理解)

字符串的编码方式有三种：int，raw，embStr。
如果字段串String保存的是整数类型的值（也就是int编码方式），那么该数据会直接保存在prt（数据指针）上。
如果字符串String保存的是字符串值，那就是使用一个简单动态字符串SDS来保存，由prt指针指向SDS内存地址。如果数据长度小于39个字节，编码方式会使用embStr；如果数据长度大于39字节，编码方式会使用raw。两者区别在于，raw编码方式，RedisObject和字符串（SDS）是分开分配（即RedisObject的内存地址和SDS的内存地址不是连续的）；embStr编码方式，RedisObject和字符串（SDS）是一起分配内存（即RedisObject的内存地址和SDS的内存地址是连续的）。具体如下图：


raw和embStr的区别可以总结如下：
embStr编码方式创建字符串对象分配内存和释放内存的次数为1次，raw是两次。
embStr编码方式分配的内存是连续的，raw不是，所以embStr存取速度快，当然存储的数据大小本身就是不一样。

2.2 RedisObject怎么表示List(编码方式的理解)

3.2版本之前列表对象的编码方式有两种：ZipList和LinkedList，3.2版本之后，采用QuickList。

2.2.1 ZipList

压缩列表的优点是节省内存，但是比其他结构要消耗更多时间，所以redis在数据量少的时候才使用ZipList，即列表长度少于512(list-max-ziplist-entries)，并且所有元素长度都小于64个字节(list-max-ziplist-value)，才会使用ZipList，否则使用LinkedList。
使用ZipList编码的RedisObject的结构如下：

ZipList节省内存的原理：
数据能够支持随机访问的原因是内存的存储是连续的，想保证内存连续，就需要数组的每个元素都是一样大小的，如果不是一样大小，就需要以最大的那个元素的内存存放，那就会造成内存的浪费。
ZipList的设计，就是每个节点按照实际大小存储，给每个节点增加一个length属性，length会记录value的大小，这样就知道每个节点占用内存的大小，就能计算出下一个节点的位置，这样的结构就是压缩列表，如下图：

2.2.2 LinkedList

当列表长度少于512，并且所有元素长度都小于64个字节用ZipList，反之用LinkedList。数据结构如下：

2.2.3 QuickList
QuickList其实就是ZipList + LinkedList，结构如下图：

三种结构对比：
LinkedList ：普通链表，可以从双端访问，内存占用较高，内存碎片较多
ZipList ：压缩列表，可以从双端访问，内存占用低，存储上限低
QuickList：LinkedList + ZipList，可以从双端访问，内存占用较低，包含多个ZipList，存储上限高

2.3 RedisObject怎么表示Hash

Hash的编码方式有两种：ZipList和HashTable

2.3.1 ZipList

当哈希对象保存的键值对数量少于512，且所有键值对的长度都少于64字节时，使用压缩列表保存。结构如下：

2.3.2 HashTable

当ZipList中的元素数量超过了hash-max-ziplist-entries（默认512）或者ZipList中的任意entry大小超过了hash-max-ziplist-value（默认64字节），会转化成HashTable，结构如下：

2.4 RedisObject怎么表示Set

Set的编码方式：IntSet和HashTable当 集合的长度少于 512 （set-max-intset-entries）时，并且所有元素都是整数，使用 intset存储，节省内存。当集合长度超出512，或者添加的元素非整数时，会转化成HashTable。结构如下：

2.5 RedisObject怎么表示ZSet

ZSet的编码方式：ZipList和SkipList

2.5.1 ZipList

当zset的长度少于128（zset-max-ziplist-entries），并且所有元素的长度都少于64字节（zset-max-ziplist-value）时，用ziplist存储。结构如下：

2.5.2 SkipList

SkipList是由字典dict和跳表组成，dict 用于记录 字符串对象和分数，即查询 字符串对象对应 分数；跳表则用来，根据 分数查询对应字符串。为什么使用这种组合的方式，就是因为字典查询分值的时间复杂度是O(1)（但是无序），跳表是有序的（时间复杂度是O(logn)），集合的元素成员和分值是共享的，两种结构都通过指针指向同一地址，也不会存在内存浪费。
跳表是对链表加多级索引的结构，对每个节点随机生成一个层数（level）,而且新插入一个节点不会影响其它节点的层数，插入操作只需要修改插入节点前后的指针，而不需要对很多节点都进行调整

3、Redis访问快的原因

1. Redis完全基于内存。
2. Redis整个数据结构类似HashMap，查找和操作的复杂度都是O(1)，不需要和DB一样产生随机的磁盘IO或者全表。
3. Redis对于客户端的处理是单线程，采用单线程处理所有客户端请求，避免多线程的上下文切换和资源竞争。
4. Redis底层是使用select/epoll多路复用的高效阻塞IO模型。

4、Redis缓存一致性问题

可以采用先删后改+过期或者延时双删的方案。本身采用缓存时需要接受一定的数据延迟和短暂的不一致，只能采取合适的策略降低缓存和数据库的不一致性的概率，无法保证两者间的强一致性。合适策略包括合适的更新策略，合适的缓存淘汰策略，已经更新数据库后及时更新缓存、缓存失败时的重试机制。

5、Redis缓存穿透

缓存穿透是因为请求参数不合理造成的，导致请求查询缓存时未命中，转而向DB查询，但是DB也无此数据，导致大量Redis不存在数据的请求落入到DB，从而导致DB出现瓶颈或者宕机，整个系统瘫痪。
解决方案：

1. 做IP限流与黑名单，避免同一IP的高频率访问。
2. 对于请求做非法校验，对于携带非法参数的直接过滤掉。
3. 对于DB查询不到的数据写入Redis中null并设置短暂的过期时间，下次请求直接被拦截在Redis，不会落入DB。

6、Redis缓存雪崩

缓存雪崩是因为我们在做缓存时为了保证内存利用率，一般在写入数据时会设置一个过期时间，过期时间的设置可能导致大量热点数据在同一时间内全部失效，此时大量请求访问这些热点数据，而Redis中却没有这些数据，导致大量请求落入DB查询，造成DB瓶颈或宕机。
解决方案：
对于数据量小且不会修改的的热点数据，可以设置永不过期，避免热点数据失效导致请求落入DB。
错开过期时间的设置，根据业务以及线上情况合理设置失效时间。
缓存查询不到，去查询DB时，使用分布式锁或MQ队列使请求串行化，从而避免同一时间大量请求落入DB，不过性能会受到很大影响。

7、Redis缓存击穿

缓存击穿类似与缓存雪崩，缓存雪崩是大量缓存失效，缓存击穿属于部分热点数据失效，也是由于缓存失效后导致请求热点数据时，大量数据落入DB。解决方案类型缓存雪崩。

8、Redis的淘汰策略

当内存不足时，就会执行相应的淘汰策略：
Volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰，没有设置过期时间的数据不会被淘汰。
Volatile-ttl：从已设置过期时间的数据集中挑选即将过期的数据淘汰，ttl值越小，越先被淘汰。
Volatile-random：从已设置过期时间的数据集中任意选择数据淘汰。
Volatile-lfu：从已设置过期时间的数据集中挑选使用频率最低的数据淘汰。
Allkeys-lru：从所有数据集中挑选最近最少使用的数据淘汰。
AllKeys-lfu：从所有数据集中挑选使用频率最低的数据淘汰。
Allkeys-random：从所有数据集中任意选择数据淘汰。
No-enviction：禁止淘汰数据，新写入的数据会报错。
在Redis中，一部分数据访问频率高，其余部分访问频率低，或者无法预测使用频率时，可以使用allkeys-lru。
如果所有数据访问频率差不多，可以使用allkeys-random。
相关配置参数：maxmemory-policy（淘汰策略）maxmemory（限制内存大小）

9、Redis的删除策略

定时删除：在设置键的过期时间的同时，设置一个定时器，当键过期了，定时器马上删除该键。定时删除对内存时友好的，能及时清理过期键，但是对CPU不友好，如果过期键太多，会消耗太多资源
惰性删除：key过期后仍然保留在内存中，当有请求操作这个key时，检查这个key是否过期了，如果过期了就删除。惰性删除对CPU友好，对内存不友好。
定期删除：Redis会每隔100ms，随机抽取一些设置过期时间的key进行检查，过期了则删除。
Redis默认采用的时定期删除+惰性删除

10、Redis持久化机制-RDB持久化

RDB持久化是把内存中当前进程的数据生成快照（.rdb）文件保存到硬盘的过程，操作系统会在redis中维护一个虚拟内存表“页表”,页表和物理内存有映射关系,所以redis主进程在持久化的时候,只需要操作虚拟内存中的页表,操作系统会从页表中读取数据,实现磁盘IO。RDB持久化有手动触发和自动触发：
**save：**阻塞当前进程，无法再继续处理任何请求，直到RDB持久化过程完成为止，若内存实例比较大，会造成很长时间的阻塞，线上环境不建议使用。
**bgsave：**主进程执行fork操作创建子进程，由子进程完成持久化，阻塞时间只是fork子进程的时间，时间很短。在执行shutdown关闭Redis服务时或者执行flushall命令时，如果没有开启AOF持久化，自动执行bgsave。异步持久化时不影响主进程对外提供服务，采用的是Copy-On-Write技术：在子进程读的时候,会把内存数据标记成read-only状态,此时主线程只能进行读取,若要进行写操作,就要在内存中拷贝一份数据副本,对数据副本进行写操作,数据副本产生后,主线程页表就会映射数据副本。
Redis实现RDB持久化是子进程在某个时间点将数据写入到临时文件中，持久化结束后，用临时文件替换上次持久化文件，重启后加载这个文件达到数据恢复。
RDB持久化是默认开启，自动触发根据save m n（m秒内有n个写操作）配置触发。
**RDB持久化的优点：**使用单独的子进程进行持久化，主进程不会进行任何IO操作，保证了高性能。而且RDB文件存储是二进制文件，适用于备份、全量复制，可用于灾难备份，同时RDB文件加载速度快（比AOF文件快得多）。
**RDB持久化的缺点：**RDB是间隔一段时间进行持久化，如果持久化之间的时间内出现故障，会出现数据丢失。这种方式更适合数据要求不严谨的时候，因为RDB无法做到实时持久化，而且每次要创建子进程，频繁创建成本高；备份时占用内存，因为需要将数据写入的临时文件中，需要的内存是原本的两倍。在极端情况下,有可能子线程读取很慢,而主进程的写操作很多,就会导致拷贝很多的数据副本,甚至会拷贝全部的数据副本,这样redis内存就翻倍了，所以Redis在进行内存分配时，尽量预留一半内存。

11、Redis持久化机制-AOF持久化

AOF持久化到硬盘的并不是内存的数据快照，而是记录写入命令，AOF的持久化策略有三种：
Appendfsync always：每次发生数据更改都将命令追加到AOF文件，因为每次写入时都记录会产生大量磁盘IO，从而性能会受到影响，但是数据最安全。
Appendfsync everysec：每秒将写入命令追加到AOF文件中，如果刚持久化之后一秒内宕机，会造成1秒的数据丢失。
Appendfsync no：Redis并不调用文件同步，而是交给操作系统处理，操作系统可以根据buffer填充情况以及通道空闲时间等情况选择时机触发同步。性能较好，数据丢失量根据OS配置有关。
AOF持久化优点：根据不同的策略可以保证数据丢失风险降到最低，数据能够保证最新。而且持久化操作时后台线程，也不会影响处理客户端请求。
AOF持久化缺点：持久化文件体积较大，数据恢复时，会重新执行指令，恢复时间比较慢，而且持久化操作的线程占用机器资源，所以高并发情况会有一些影响。

12、Redis持久化机制-AOF机制重写

随着Redis在线上运行的时间越来越久，客户端执行的命令越来越多，AOF的文件也会越来越大，当AOF达到一定程度大小之后再通过AOF文件恢复数据是异常缓慢的，那么对于这种情况Redis在开启AOF持久化机制的时候会存在AOF文件的重写，缺省配置是当AOF文件比上一次重写时的文件大小增长100%并且文件大小不小于64MB时会对整个AOF文件进行重写从而达到“压缩”的目的（这里的100%和64MB可以通过auto-aof-rewrite-percentage 100 与 auto-aof-rewrite-min-size 64mb来调整）。而AOF rewrite操作就是“压缩”AOF文件的过程，当然 Redis 并没有采用“基于原aof文件”来重写的方式，而是采取了类似snapshot的方式：基于copy-on-write，全量遍历内存中数据，然后逐个序列到aof文件中。因此AOF rewrite能够正确反应当前内存数据的状态，这正是我们所需要的；rewrite过程中，对于新的变更操作将仍然被写入到原 AOF文件中，同时这些新的变更操作也会被 Redis 收集起来(buffer，copy-on-write方式下，最极端的可能是所有的key都在此期间被修改，将会耗费2倍内存)，当内存数据被全部写入到新的aof文件之后，收集的新的变更操作也将会一并追加到新的aof文件中，此后将会重命名新的aof文件为appendonly.aof, 此后所有的操作都将被写入新的aof文件。如果在rewrite过程中，出现故障，将不会影响原AOF文件的正常工作，只有当rewrite完成之后才会切换文件，因为rewrite过程是比较可靠的，触发rewrite的时机可以通过配置文件来声明，同时Redis中可以通过bgrewriteaof指令人工干预。

13、Redis持久化机制-混合型持久化

当然在Redis4.x之后推出了混合型持久化机制，因为RDB虽然加载快但是存在数据丢失，AOF数据安全但是加载缓慢，Redis为了解决这个问题，带来了一个新的持久化选项——混合持久化。将RDB文件的内容和增量的AOF日志文件存在一起。这里的AOF日志不再是全量 的日志，而是自持久化开始到持久化结束的这段时间发生的增量AOF日志，通常这部分AOF日志很小。Redis重启的时候，可以先加载RDB的内容，然后再重放增量AOF日志，就可以完全替代之前的AOF全量文件重放，恢复效率因此大幅得到提升（混合型持久化最终生成的文件后缀是.aof，可以通过redis.conf文件中aof-use-rdb-preamble yes配置开启，Redis 5.0 默认是开启的）。
混合型持久化优点：结合了RDB和AOF的优点，使得数据恢复的效率大幅提升。
混合型持久化缺点：兼容性不好，Redis-4.x新增，虽然最终的文件也是.aof格式的文件，但在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差。

14、Redis的事务机制

Redis的事务机制是弱事务，相对来说比较鸡肋，官方给出如下几个指令来进行Redis的事务控制：
• MULTI：标记一个事务块的开始
• DISCARD：取消事务，放弃执行事务块内的所有命令
• EXEC：执行所有事务块内的命令
• UNWATCH：取消WATCH命令对所有key的监视
• WATCH key [key …]：监视一个(或多个)key，如果在事务执行之前这个(或这些)key被其他命令所改动，那么事务将被打断

15、Redis主从复制

先讲三个概念，Redis也是根据这三个概念进行主从复制。
Replication Id：数据集的标记，master与slave节点都有replid,但是id不一样, 只有在建立连接的时候,slave节点才会继承master分支的replid,所以在进行主从连接的时候, 可以通过id是否一致来判断是需要进行全量同步。
offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。
repl_baklog：在master节点执行持久化的时候,会记录所有持久化期间的命令到repl_baklog, 用来计算offset偏移量。这个文件是一个固定大小的数组，只不过数组是环形。角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。repl_baklog中会记录Redis处理过的命令日志及，包括master当前的offset值，和slave已经拷贝到的offset值。
因此slave做数据同步，必须告知master自己的replication id 和offset，master才可以判断需要同步哪些数据。
Redis主从复制-全量复制
执行时机:
在主从服务器第一次连接或者从服务器长时间未同步的时候会执行全量同步,会将master节点上的所有数据同步到slave节点上

Redis主从复制-部分复制

主从复制的优缺点：

1. 全量数据同步时如果数据量比较大，在同步完成之前会导致线上短暂性的卡顿。
2. 一旦主节点宕机，从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
3. 写入的QPS性能受到主节点限制，虽然主从复制能够通过读写分离来提升整体性能，但是只有从节点能够做到线性扩容升吞吐，写入的性能还是受到主节点限制。
4. 木桶效应，整个Redis节点群能够存储的数据容量受到所有节点中内存最小的那台限制，比如一主两从架构：master=32GB、slave1=32GB、slave2=16GB，那么整个Redis节点群能够存储的最大容量为16GB。
5. 在持久化的基础上能够将数据同步到其他机器，在极端情况下做到灾备的效果。
6. 能够通过主写从读的形式实现读写分离提升Redis整体吞吐，并且读的性能可以通过对从节点进行线性扩容无限提升。
   主从同步可以保证主从数据的一致性，非常重要。可以从以下几个方面来优化Redis主从就集群：

• 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
• Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
• 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
• 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

16、Redis哨兵机制

redis主从集群可以实现高并发读的功能,配合哨兵框架可实现高可用。

上图所示是目前企业中常用的Redis架构，一主两从三哨兵架构，Redis Sentinel（哨兵）主要功能包括主节点存活检测、主从运行情况检测、自动故障转移、主从切换。Redis Sentinel最小配置是一主一从。Redis的Sentinel系统可以用来管理多个Redis节点，该系统可以执行以下四个任务：

• 监控：不断检查主服务器和从服务器是否正常运行
• 通知：当被监控的某个Redis服务器出现问题，Sentinel通过API脚本向管理员或者其他应用程序发出通知
• 自动故障转移：当主节点不能正常工作时，Sentinel会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点，这样就不需要人工干预进行主从切换
  集群监控的原理：
  Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令；
  主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
  客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。
  自动故障恢复原理：
  一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：首先过滤掉主观下线的节点(判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点)，然后判断slave节点的slave-priority值(默认都为1)，越小优先级越高，如果是0则永不参与选举,如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高最后是判断slave节点的运行id大小，越小优先级越高。
  选举成功后， sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master。sentinel给所有其它slave发送slaveof IP + Port 命令，让这些slave成为新master的从节点，开始从新的master上同步数据。最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点。
  每个哨兵节点每10秒会向主节点和从节点发送info命令获取最级联结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到
  
  每个哨兵节点每隔2秒会向Redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的
  
  隔1秒每个哨兵根据自己info获取的级联结构信息，会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

17、Redis分片集群

redis读写分离配合哨兵模式可以实现高可用,高并发读的要求,但不满足海量数据存储,高并发写的要求,所以就要使用redis分片集群。

分片集群特征：

• 集群中有多个master，每个master保存不同数据
• 每个master都可以有多个slave节点
• master之间拥有心跳检测机制,通过ping监测彼此健康状态
• 分片集群中存在散列插槽机制,所以客户端请求可以访问集群任意节点，最终都会被转发到正确节点
  散列插槽(hash插槽):
  Redis会把每一个master节点映射到16384个插槽（hash slot）上(0-16383)。
  数据中的key不是与master节点进行绑定的,而是与插槽进行绑定的,所以不用指定访问哪个节点,redis会根据key的插槽值找到key所在的位置,而插槽值是根据key的有效部分计算的, 盘点有效部分有两种情况：
• key中包含"{}"，且“{}”中至少包含1个字符，“{}”中的部分是有效部分 例如：key: {a}id 会根据a计算插槽值
• key中不包含“{}”，整个key都是有效部分 例如：key:id会根据id计算插槽值
  计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。
  如何将一类数据分配到统一节点上:
  根据上述规则,分片集群中的每个节点都是映射16384个插槽的一部分,数据进行存储的时候是计算key的slot值进行存储, 那同一类数据对的key值可能会计算出不同的slot值,就会被分配到不同的节点上,如果要实现对一类数据的群组化,我们就可以利用slot值计算的有效部分,在同一类数据key加上{type},这样计算出的slot值就会一样了。
  集群伸缩
  添加分片：redis-cli --cluster add-node new_host:new port existing_host:existing_port
  new_host参数:新节点的ip地址
  new_port参数:新节点的端口号
  existing_host参数:任意一个已经存在的节点的ip
  existing_port参数:任意一个已经存在的节点的端口
  existing_host参数和existing_port参数用于推送新节点上线信息给集群中的其他节点
  转移插槽:
  在新节点上线后,是没有插槽映射的,所以需要我们手动分配插槽
  redis-cli --cluster reshard 后面设置一些配置参数，可以上机尝试
  故障转移
  自动故障转移:
  分片集群支持自动故障转移,当一台master故障后, 集群内的心跳机制就会发现,当超过一般的节点认为该节点下线后,就会自动选举一个salve当做新的master,而当故障节点重启后,会以salve的角色进行运行
  手动故障转移:
  利用cluster failover命令可以手动让集群中的某个master宕机，切换到执行cluster failover命令的这个slave节点，实现无感知的数据迁移。