redis常见的三种模式【主从、哨兵、集群】介绍以及部署

Redis安装以及使用：

下载地址：http://download.redis.io/releases/

系统参数优化

echo   'vm.overcommit_memory = 1'  >>  /etc/sysctl.conf
echo 'net.core.somaxconn = 1024'  >> /etc/sysctl.conf
sysctl -p

vi /etc/rc.local
echo never > /sys/kernel/mm/transparent_hugepage/enabled
chmod +x /etc/rc.d/rc.local
reboot重启系统

apt方式安装redis

apt-cache madison redis #查看redis版本
apt install -y redis #安装redis
systemctl  start redis && systemctl  enable redis #启动服务并设置开机自启动

编译安装redis

cd /usr/local/src
wget http://download.redis.io/releases/redis-7.0.4.tar.gz
tar xvf redis-7.0.4.tar.gz
cd redis-7.0.4
make PREFIX=/apps/redis MALLOC=libc  install #指定redis安装目录
mkdir  /apps/redis/{config,logs,data,run} #创建配置文件、日志、数据、运行进程目录
cp redis.conf /apps/redis/config/ #复制文件到config目录

FAQ:
Question:
make[3]: cc: Command not found
Makefile:257: recipe for target 'alloc.o' failed
make[3]: *** [alloc.o] Error 127
make[3]: Leaving directory '/usr/local/src/redis-7.0.4/deps/hiredis'
Makefile:52: recipe for target 'hiredis' failed
Resolve:
apt install gcc
apt-get install pkg-config

Question:
zmalloc.h:50:10: fatal error: jemalloc/jemalloc.h: No such file or directory
Resolve:
sudo make MALLOC=libc

前台启动redis

/apps/redis/bin/redis-server /apps/redis/config/redis.conf 

编辑redis服务启动脚本

vim /etc/systemd/system/redis.service

[Unit]
Description=Redis persistent key-value database
After=network.target
After=network-online.target
Wants=network-online.target 

[Service]
ExecStart=/apps/redis/bin/redis-server /apps/redis/config/redis.conf  --supervised systemd 
ExecReload=/bin/kill -s HUP $MAINPID 
ExecStop=/bin/kill -s QUIT $MAINPID
Type=notify
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755 

[Install]
WantedBy=multi-user.target

创建redis用户以及授权redis目录

groupadd  -g 1000 redis && useradd   -u 1000 -g 1000 redis -s /sbin/nologin
chown  redis.redis /apps/redis/ -R

启动服务

systemctl daemon-reload
systemctl start redis
systemctl enable redis

使用客户端连接redis

/apps/redis/bin/redis-cli -h ip -p port -a passwd

创建软连接

ln -sv /apps/redis/bin/redis-* /usr/bin/

redis配置文件

bind  0.0.0.0 #监听地址，可以用空格隔开后多个监听IP
protected-mode yes  #在没有设置bind IP和密码的时候,redis只允许访问127.0.0.1:6379，远程访问将提示警告信息并拒绝远程访问
port 6379 #监听端口
tcp-backlog 511 #三次握手的时候server端收到client ack确认号之后的队列值。
timeout 0 #客户端和Redis服务端的连接超时时间，默认是0，表示永不超时。tcp-keepalive 300 #tcp 会话保持时间
daemonize no #认情况下 redis 不是作为守护进程运行的，如果你想让它在后台运行，你就把它改成 yes,当redis作为守护进程运行的时候，它会写一个 pid 到 /var/run/redis.pid 文件里面
pidfile /var/run/redis_6379.pid #pid文件路径
loglevel notice #日志级别
logfile "" #日志路径
databases 16  #设置db 库数量，默认16个库
always-show-logo yes #在启动redis 时是否显示log
save 3600 1 #在3600秒内有一个键内容发生更改就出就快照机制
save 300 10
save 60 10000
stop-writes-on-bgsave-error  no  #快照出错时是否禁止redis 写入操作
rdbcompression yes #持久化到RDB文件时，是否压缩，"yes"为压缩，"no"则反之
rdbchecksum yes  #是否开启RC64校验，默认是开启
dbfilename dump.rdb #快照文件名
dir ./ #快照文件保存路径
replica-serve-stale-data yes  #当从库同主库失去连接或者复制正在进行，从机库有两种运行方式：
1、如果replica-serve-stale-data设置为yes(默认设置)，从库会继续响应客户端的读请求。
2、如果replica-serve-stale-data设置为no，除去指定的命令之外的任何请求都会返回一个错误"SYNC with master in progress"。
replica-read-only yes  #是否设置从库只读
repl-diskless-sync  no  #是否使用socket方式复制数据(无盘同步)，新slave连接连接时候需要做数据的全量同步，redis server就要从内存dump出新的RDB文件，然后从master传到slave，有两种方式把RDB文件传输给客户端：
1、基于硬盘（disk-backed）：master创建一个新进程dump RDB，RDB完成之后由父进程（即主进程）传给slaves。
2、基于socket（diskless）：master创建一个新进程直接dump RDB到slave的socket，不经过主进程，不经过硬盘。
基于硬盘的话，RDB文件创建后，一旦创建完毕，可以同时服务更多的slave，但是基于socket的话， 新slave连接到master之后得逐个同步数据。
在较慢并且网络较快的时候，可以用diskless(yes),否则使用磁盘(no)
repl-diskless-sync-delay 30  #diskless**复制的延迟时间**，设置0为关闭，在延迟时间内连接的新客户端，会一起通过disk方式同步数据，但是一旦复制开始还没有结束之前，master节点不会再接收新slave的复制请求，直到下一次同步开始。
repl-ping-slave-period 10 #slave根据master指定的时间进行周期性的PING 监测
repl-timeout 60 #复制连接的超时时间，需要大于repl-ping-slave-period，否则会经常报超时
repl-disable-tcp-nodelay no  #在socket模式下是否在slave套接字发送SYNC之后禁用 TCP_NODELAY，如果选择“yesRedis将使用更少的TCP包和带宽来向slaves发送数据，但是这将使数据传输到slave上有延迟，Linux内核的默认配置会达到40毫秒，如果你选择了 "no"** 数据传输到salve**的延迟将会减少但要使用更多的带宽。
repl-backlog-size 512mb #复制缓冲区内存大小，只有在slave连接之后才分配内存。 
repl-backlog-ttl 3600 #多长时间master没有slave连接，就清空backlog缓冲区。
replica-priority 100 #当master不可用，Sentinel会根据slave的优先级选举一个master，最低的优先级的slave，当选master，而配置成0，永远不会被选举。
requirepass foobared #设置redis 连接密码
rename-command #重命名一些高危命令
maxclients 10000  #Redis最大连接客户端
maxmemory #最大内存，单位为bytes字节，8G内存的计算方式8(G)1024(MB)1024(KB)*1024(Kbyte)，需要注意的是slave的输出缓冲区是不计算在maxmemory内。
appendonly no #是否开启AOF日志记录，默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dumpd数据的间隔时间)，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。
appendfilename "appendonly.aof" #AOF文件名
appendfsync everysec  #aof持久化策略的配置,no表示不执行fsync，由操作系统保证数据同步到磁盘,always表示每次写入都执行fsync，以保证数据同步到磁盘,everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。
no-appendfsync-on-rewrite no在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘IO开支和请求阻塞时间。默认为no,表示"不暂缓",新的aof记录仍然会被立即同步，Linux的默认fsync策略是30秒，如果为yes 可能丢失30秒数据，但由于yes性能较好而且会避免出现阻塞因此比较推荐。
auto-aof-rewrite-percentage  100 # 当Aof log增长超过指定百分比例时，重写AOF文件， 设置为0表示不自动重写Aof 日志，重写是为了使aof体积保持最小，但是还可以确保保存最完整的数据。
auto-aof-rewrite-min-size  64mb #触发aof rewrite的最小文件大小
aof-load-truncated yes #是否加载由于其他原因导致的末尾异常的AOF文件(主进程被kill/断电等)
aof-use-rdb-preamble no #redis4.0新增RDB-AOF混合持久化格式，在开启了这个功能之后，AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容，其中RDB格式的内容用于记录已有的数据，而AOF格式的内存则用于记录最近发生了变化的数据，这样Redis就可以同时兼有RDB持久化和AOF持久化的优点（既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据）。
lua-time-limit 5000  #lua脚本的最大执行时间，单位为毫秒
cluster-enabled yes #是否开启集群模式，默认是单机模式
cluster-config-file nodes-6379.conf #由node节点自动生成的集群配置文件
cluster-node-timeout 15000 #集群中node节点连接超时时间
cluster-replica-validity-factor 10 #在执行故障转移的时候可能有些节点和master断开一段时间数据比较旧，这些节点就不适用于选举为master，超过这个时间的就不会被进行故障转移
cluster-migration-barrier 1  #集群迁移屏障，一个主节点拥有的至少正常工作的从节点，即如果主节点的slave节点故障后会将多余的从节点分配到当前主节点成为其新的从节点。
cluster-require-full-coverage no  #集群请求槽位全部覆盖，如果一个主库宕机且没有备库就会出现集群槽位不全，那么yes情况下redis集群槽位验证不全就不再对外提供服务，而no则可以继续使用但是会出现查询数据查不到的情况(因为有数据丢失)。
#Slow log 是 Redis 用来记录查询执行时间的日志系统，slow log 保存在内存里面，读写速度非常快，因此你可以放心地使用它，不必担心因为开启 slow log 而损害 Redis 的速度。
slowlog-log-slower-than 10000 #以微秒为单位的慢日志记录，为负数会禁用慢日志，为0会记录每个命令操作。
slowlog-max-len 128 #记录多少条慢日志保存在队列，超出后会删除最早的，以此滚动删除

常用命令

127.0.0.1:6379> CONFIG set maxmemory 8589934592 #更改最大内存
127.0.0.1:6379> CONFIG SET requirepass 123456 #设置密码
127.0.0.1:6379> select 1 #切换数据库
127.0.0.1:6379> keys * #查看当前库下所有key
127.0.0.1:6379> bgsave #手动在后台执行RDB持久化操作
127.0.0.1:6379> dbsize #手动在后台执行RDB持久化操作
127.0.0.1:6379> flushdb #强制清空当前库中的所有key
127.0.0.1:6379> flushall #强制清空当前redis服务器所有数据库中的所有key，即删除所有数据

redis主从模式

主备模式，可以实现Redis数据的跨主机备份。
程序端连接到高可用负载的VIP，然后连接到负载服务器设置的Redis后端real server，此模式不需要在程序里面配置Redis服务器的真实IP地址。

slave主要配置

Redis Slave 也要开启持久化并设置和master同样的连接密码，因为后期slave会有提升为master的可能,Slave端切换master同步后会丢失之前的所有数据。
注意：一旦某个Slave成为一个master的slave，Redis Slave服务会清空当前redis服务器上的所有数据并将master的数据导入到自己的内存，但是断开同步关系后不会删除当前已经同步过的数据。

命令行配置

当前状态为master，需要转换为slave角色并指向master服务器的IP+PORT+Password

192.168.2.132:6379> REPLICAOF 192.168.2.131 6379  #masterip和port
OK  
192.168.2.132:6379> CONFIG SET masterauth 123456 #master密码
OK 
192.168.2.132:6379> info  replication #查看状态

redis集群

主从架构无法实现master和slave角色的自动切换，即当master出现redis服务异常、主机断电、磁盘损坏等问题导致master无法使用，而redis高可用无法实现自故障转移(将slave提升为master)，需要手动改环境配置才能切换到slave redis服务器，另外也无法横向扩展Redis服务的并行写入性能，当单台Redis服务器性能无法满足业务写入需求的时候就必须需要一种方式解决以上的两个核心问题：
1.master和slave角色的无缝切换，让业务无感知从而不影响业务使用
2.可以横向动态扩展Redis服务器，从而实现多台服务器并行写入以实现更高并发的目的。

Sentinel(哨兵)模式：

Sentinel 进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本。哨兵(Sentinel) 是一个分布式系统，可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossip protocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，主观是每个成员都具有的独自的而且可能相同也可能不同的意识，英文名称：Subjective Down，简称SDOWN。有主观宕机，肯定就有客观宕机。当“哨兵群”中的多数Sentinel进程在对Master主服务器做出 SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，这种方式就是“客观宕机”，客观是不依赖于某种意识而已经实际存在的一切事物，英文名称是：Objectively Down， 简称 ODOWN。通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移（failover）。
Sentinel 机制可以解决master和slave角色的切换问题。

手动配置master

需要手动先指定某一台Redis服务器为master，然后将其他slave服务器使用命令配置为master服务器的slave,哨兵的前提是已经手动实现了一个redis master-slave的运行环境。
首先配置1个一主两从的高可用redis架构

slave1的配置

192.168.2.132:6379> REPLICAOF 192.168.2.131 6379
ok
192.168.2.132:6379> CONFIG SET masterauth "123456"
ok

slave2的配置

192.168.2.133:6379> REPLICAOF 192.168.2.131 6379
ok
192.168.2.133:6379> CONFIG SET masterauth "123456"
ok

应用程序如何连接redis

Redis 官方客户端：https://redis.io/clients

java客户端连接redis是通过Jedis来实现的，java代码用的时候只要创建Jedis对象就可以建多个Jedis连接池来连接redis，应用程序再直接调用连接池即可连接Redis。而Redis为了保障高可用,服务一般都是Sentinel部署方式，当Redis服务中的主服务挂掉之后,会仲裁出另外一台Slaves服务充当Master。这个时候,我们的应用即使使用了Jedis 连接池,Master服务挂了,我们的应用将还是无法连接新的Master服务，为了解决这个问题, Jedis也提供了相应的Sentinel实现,能够在Redis Sentinel主从切换时候,通知我们的应用,把我们的应用连接到新的Master服务。

Redis Sentinel的使用也是十分简单的,只是在JedisPool中添加了Sentinel和MasterName参数，JRedis Sentinel底层基于Redis订阅实现Redis主从服务的切换通知，当Reids发生主从切换时，Sentinel会发送通知主动通知Jedis进行连接的切换，JedisSentinelPool在每次从连接池中获取链接对象的时候,都要对连接对象进行检测,如果此链接和Sentinel的Master服务连接参数不一致,则会关闭此连接,重新获取新的Jedis连接对象。

配置sentinel.conf

sentinel01的配置

cp /usr/local/src/redis-7.0.4/sentinel.conf /apps/redis/config/
grep "^[a-Z]" /apps/redis/config/sentinel.conf
port 26379 
daemonize yes 
pidfile "/apps/redis/run/redis-sentinel.pid" 
logfile "/apps/redis/log/sentinel_26379.log" 
dir "/apps/redis/" 
sentinel monitor mymaster 192.168.2.131 6379 2 #法定人数限制(quorum)，即有几个slave认为master down了就进行故障转移 
sentinel auth-pass mymaster 123456 
sentinel down-after-milliseconds mymaster 30000  #(SDOWN)主观下线的时间 
sentinel parallel-syncs mymaster 1 #发生故障转移时候同时向新master同步数据的slave数量，数字越小总同步时间越长 
sentinel failover-timeout mymaster 180000  #所有slaves指向新的master所需的超时时间
sentinel deny-scripts-reconfig yes #禁止修改脚本

sentinel02的配置

port 26379 
daemonize yes 
pidfile "/apps/redis/run/redis-sentinel.pid" 
logfile "/apps/redis/log/sentinel_26379.log" 
dir "/apps/redis/" 
sentinel deny-scripts-reconfig yes 
sentinel monitor mymaster 192.168.2.131 6379 2 
sentinel auth-pass mymaster 123456 

sentinel03的配置

port 26379 
daemonize yes 
pidfile "/apps/redis/run/redis-sentinel.pid" 
logfile "/apps/redis/log/sentinel_26379.log" 
dir "/apps/redis/" 
sentinel deny-scripts-reconfig yes 
sentinel monitor mymaster 192.168.2.131 6379 2 
sentinel auth-pass mymaster 123456 

启动哨兵

/apps/redis/bin/redis-sentinel  /apps/redis/config/sentinel.conf /apps/redis/bin/redis-sentinel  /apps/redis/config/sentinel.conf  /apps/redis/bin/redis-sentinel  /apps/redis/config/sentinel.conf 

redis Cluster模式

在哨兵sentinel机制中，可以解决redis高可用的问题，即当master故障后可以自动将slave提升为master从而可以保证redis服务的正常使用，但是无法解决redis单机写入的瓶颈问题，即单机的redis写入性能受限于单机的内存大小、并发数量、网卡速率等因素，因此redis官方在redis 3.0版本之后推出了无中心架构的redis cluster机制，在无中心的redis集群当中，其每个节点保存当前节点数据和整个集群状态,每个节点都和其他所有节点连接，特点如下：
1：所有Redis节点使用(PING机制)互联
2：集群中某个节点的失效，是整个集群中超过半数的节点监测都失效才算真正的失效
3：客户端不需要proxy即可直接连接redis，应用程序需要写全部的redis服务器IP。
4：redis cluster把所有的redis node映射到 0-16383个槽位(slot)上，读写需要到指定的redis node上进行操作，因此有多少个reids node相当于redis 并发扩展了多少倍。
5：Redis cluster预先分配16384个(slot)槽位，当需要在redis集群中写入一个key -value的时候，会使用CRC16(key) mod 16384之后的值，决定将key写入值哪一个槽位从而决定写入哪一个Redis节点上，从而有效解决单机瓶颈。

redis Cluster架构

采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：
节点A覆盖 0－5460
节点B覆盖 5461－10922
节点C覆盖 10923－16383

部署redis集群

创建redis cluster集群的前提：

1.每个redis node节点采用相同的硬件配置、相同的密码、相同的redis版本。
2.每个节点必须开启的参数 cluster-enabled yes #必须开启集群状态，开启后redis 进程会有cluster显示 cluster-config-file nodes-6380.conf #此文件有redis cluster集群自动创建和维护，不需要任何手动操作
3.所有redis服务器必须没有任何数据
4.先启动为单机redis且没有任何key value
5.设置集群节点配置文件 (启动自动生成)
cluster-config-file $REDIS_HOME/config/nodes_端口号.conf
6.设置集群节点宕机时间（即多少毫秒断开连接即被认为是宕机）
cluster-node-timeout 15000
7.设置cluster-migration-barrier 1
（即有多于1个slave节点时，slave节点能够自动迁移至没有从节点的主节点上）
8.设置cluster-require-full-coverage no（即部分节点宕机，其他节点仍对外提供服务。默认不提供服务。）

创建集群

redis版本>=5

redis-cli -a 123456  --cluster create 192.168.2.131:6379   192.168.2.131:6380    192.168.2.132:6379   192.168.2.132:6380   1 92.168.2.133:6379   192.168.2.133:6380  --cluster-replicas 1 

验证集群

由于未设置masterauth认证密码，所以主从未建立起来，但是集群已经运行，所以需要在每个slave控制台使用config set设置masterauth密码，或者写在每个redis配置文件中，最好是在控制点设置密码之后再写入配置文件当中。

设置从节点masterauth密码

redis-cli -h 192.168.2.131 -p 6380 -a 123456
192.168.2.131:6380> CONFIG SET  masterauth 123456
ok

redis-cli -h 192.168.2.132 -p 6380 -a 123456
192.168.2.132:6380> CONFIG SET  masterauth 123456
ok

redis-cli -h 192.168.2.133 -p 6380 -a 123456
192.168.2.133:6380> CONFIG SET  masterauth 123456
ok

master与slave状态验证

192.168.2.131:6380> info replication #查看slave状态确定为up
192.168.2.132:6380> info replication #查看slave状态确定为up
192.168.2.133:6380> info replication #查看slave状态确定为up

192.168.2.131:6379> info replication #查看master和slave状态是否正常
192.168.2.132:6379> info replication #查看master和slave状态是否正常
192.168.2.133:6379> info replication #查看master和slave状态是否正常

验证集群状态

192.168.2.131:6379> cluster info #确保状态为ok

查看集群node对应关系

192.168.2.131:6380> cluster nodes 

集群状态验证与监控

 redis-cli -a 123456  --cluster check 192.168.2.131:6379 #redis版本>=5

redis cluster集群节点维护

添加节点到集群

提前配置好新增节点的redis服务

add-node        new_host:new_port existing_host:existing_port
要添加的新redis节点IP和端口    添加到的集群中的master IP:端口，新的node节点加到集群之后默认是master节点，但是没有slots数据，需要重新分配。
redis-cli -a 123456 --cluster add-node  192.168.2.134:6379  192.168.2.131:6379 

重新分配槽位

添加主机之后需要对添加至集群种的新主机重新分片否则其没有分片也就无法写入数据。

redis-cli -a 123456 --cluster reshard  192.168.2.134:6379

How many slots do you want to move (from 1 to 16384)? 4096 #分配多少个槽位192.168.2.134:6379
What is the receiving node ID?  #接收slot的服务器ID，手动输入192.168.2.134的node ID 
Please enter all the source node IDs.   
Type 'all' to use all the nodes as source nodes for the hash slots.   
Type 'done' once you entered all the source nodes IDs. 
Source node #1: all #将哪些源主机的槽位分配给192.168.2.134:6379，all是自动在所有的redis node选择划分，如果是从redis cluster删除主机可以使用此方式将主机上的槽位全部移动到别的redis主机 
Do you want to proceed with the proposed reshard plan (yes/no)?  yes #确认分配

验证重新分配槽位之后的集群状态

redis-cli -a 123456 --cluster check 192.168.2.131:6379

为新的master添加slave节点

redis-cli -a 123456 --cluster add-node 192.168.2.134:6380 192.168.2.134:6379 

#更改新节点更改状态为slave：
redis-cli  -h 192.168.2.134 -p 6380 -a 123456 #登录到新添加节点
CLUSTER NODES #查看当前集群节点，找到目标master 的ID
CLUSTER  REPLICATE xxxxxxxxxx(masterID) #将其设置slave，命令格式为cluster replicate MASTERID
CLUSTER NODES #再次查看集群节点状态，验证节点是否已经更改为指定master 的slave
redis-cli -a 123456 --cluster check 192.168.2.131:6379 #验证当前集群状态

集群维护之动态删除节点

迁移master 的槽位之其他master

被迁移Redis master源服务器必须保证没有数据，否则迁移报错并会被强制中断。
连接到192.168.2.132将集群中的192.168.2.131服务器删除

redis-cli -a 123456  --cluster reshard  192.168.2.132:6379

How many slots do you want to move (from 1 to 16384)?  4096 #迁移master上的多少个槽位
What is the receiving node ID? 2252cfc400df0e6719b12475ac703abe3d5dff6c #接收槽位的服务器ID
Please enter all the source node IDs.
   Type 'all' to use all the nodes as source nodes for the hash slots.
   Type 'done' once you entered all the source nodes IDs. 
Source node #1: xxxxxxxxx #从哪个服务器迁移4096个槽位
Source node #2: done #写done，表示没有其他master了 
Do you want to proceed with the proposed reshard plan (yes/no)? yes #是否继续 
redis-cli -a 123456 --cluster check 192.168.2.131:6379 #验证卡槽迁移完成

从集群删除服务器：

虽然槽位已经迁移完成，但是服务器IP信息还在集群当中，因此还需要将IP信息从集群删除

redis-cli -a 123456 --cluster del-node 192.168.2.132:6379 xxxxxxx(要移除的192.168.2.131的nodeID)

验证node是否删除

redis-cli -a 123456 --cluster check 192.168.2.132:6379 #验证当前集群状态
注：192.168.2.131被删除之后，其之前的slave自动成为了Redis集群中其他master的slave，此节点如果不需要也可以一并删除。