文章目录

Redis - 架构演变(主从、哨兵、集群)

 由于Redis是基于内存的高性能KV数据库，这些年随时Redis的快速发展，更多的技术开发者将Redis融入自己的实际项目中。为了应对各式各样的业务场景保证数据更加稳定安全，各种高可用架构以及优化方案不断改进，导致Redis的整个架构体系也有了一个演变过程。集群模式是近年来Redis架构不断改进中较好的高可用方案。我们这里会对Redis的整个演变过程中每一个环节都进行一个介绍。主要包括了单机单节点模式、主从架构(M/S主从读写分离)、哨兵模式高可用架构、redis集群高可用架构等方案。

1.单节点模式

 最初Redis刚进入我们身边的时候，是因为传统关系型数据库在某些特定场景下处理起来并不是十分合适，所以最初单机单节点的模式就能够满足我们对业务场景的应对，这里我们不做过多介绍这种模式，其实就是我们部署单个节点的Redis仅仅支持使用即可，对高可用以及数据安全性要求并不高。

2.主从架构

 随着我们Redis不断融入我们项目中各式各样业务场景，我们发现其实在大多数时候甚至超过90%的情况下，我们只Redis进行读操作，写操作只是为了支撑缓存数据内容，一次写操作之后伴随的是大量的读操作。所以Master-Slave主从架构出现了，我们通过部署额外的一些Redis服务让其与主服务器连接，主服务器会通过网络发送数据副本给从服务器进行准实时更新。我们在应用的过程中将写操作都集中在主服务器，而读操作集中在从服务器，这样就分散了主服务器的压力，使其性能更好并且更具备可用性，并且同时部署多台从服务器也能很大程度上解决读操作集中造成的性能瓶颈。
 其实主从架构还有一个好处，那就是可以保证我们数据的安全性。我们知道Redis通过持久化的功能保证了服务器重启之后只会损失少量数据甚至不会损失数据的问题。由于持久化会将我们内存中的数据保存到磁盘上，重启之后会从磁盘上加载数据。但是由于数据仅会存储在一台服务器上，当这台服务器磁盘故障那么数据也会出现丢失。为了避免这种单点故障造成的数据丢失，所以通常会部署多个服务到不同服务器上，也就能够保证数据有多个备份，数据更加安全不易丢失。

2.1 主从搭建

 我们之前讲过Redis环境的搭建Redis- Linux环境安装及使用，Redis发展迅速其实和它的强大息息相关，开发团队对这款产品的支持也是做得尽心尽责。随着整个发展趋势，Redis开发团队也对其进行了更多的功能支持。主从模式其实就是Redis现在本身就提供的，我们很简单几步就能够搭建出一个雏形并且投入使用。

2.1.1 配置文件

 这里我们就以主从服务全部集中在一台服务器为例，我们模拟的是一主两从的一个架构，首先我们分别在Redis目录下建/6379、/6380、/6381三个目录，将redis.conf复制到三个文件目录下。

mkdir 6379
mkdir 6380
mkdir 6381
cp redis.conf ./6379
cp redis.conf ./6380
cp redis.conf ./6381

 这里我们在之前讲过有一些公共的配置需要修改，例如允许远程连接、后台启动等就不在这里再讲了。这里讲一下这几个配置文件的区别。首先是三个配置文件的端口需要配置不同，其次就是从服务配置文件中需要配置关联哪个主服务。

/6379/redis.conf

port 6379

/6380/redis.conf

port 6380
slaveof 127.0.0.1 6379

/6381/redis.conf

port 6381
slaveof 127.0.0.1 6379

2.1.2 启动服务验证

 很简单的几步，修改配置完成之后，我们分别启动三个Redis服务。

./src/redis-server ./6379/redis.conf
./src/redis-server ./6380/redis.conf
./src/redis-server ./6381/redis.conf

 启动完成后我们可以通过redis-cli或者一些Redis管理工具去连接验证。
 这里我们先验证一下假如我们用从服务去写操作会怎么样？

 果然从服务是不能进行写操作的，那我们再来验证下正确的流程，通过6379端口服务写入一个数据，看是否其他从服务器会同步到该数据。



 整个流程很顺利，而且我们发现同步的效率实际上非常高的，那么Redis主从架构的一个基本搭建就是这样的。
 其实除了上面我们修改配置文件的方式能实现主从搭建，还能够在启动时指定主从关系，只需启动时加上参数

redis-server --port 6380 --slaveof 127.0.0.1 6379

2.2 主从如何实现数据同步的？

 我们知道主从同步主要是主服务器通过网络发送数据副本给从服务器以保证数据同步，那具体是如何做的呢？另外还有一个问题我们可以思考下，如果从服务器宕机后重启是否能保证数据一致呢？如果新增一台从服务器那又如何保持数据一致呢？
 说到数据同步那我们就不得不提持久化这个概念。Redis中主要包含两种持久化方式：RDB(全量持久化)、AOF(Append Only If 增量持久化)，对于这两种持久化方式之后我们会有详细的博客讲解。

2.2.1 SYNC

 Redis在2.8版本之前使用的是旧版复制方式SYNC，SYNC实际上是一个非常耗费资源的操作，我们来看下它是如何操作的就知道了。

  1. 主服务器会执行BGSAVE命令来生成RDB文件，这个生成过程会耗费主服务器大量的的CPU、内存和磁盘读写资源。
  2. 主服务器会将RDB文件发送给从服务器，这个发送过程也会耗费主从服务器大量的网络带宽和流量，并对主服务器响应命令
    请求的时间产生影响，即接收到RDB文件的从服务器在载入文件的过程是阻塞的，无法处理命令请求。

2.2.2 PSYNC

 Redis在2.8之后对主从复制进行了改进，采用的是新版复制方式PSYNC，PSYNC命令具有完整重同步(Full Resynchronization)和部分重同步(Partial Resynchronization)两种模式。部分重同步功能主要由以下三个部分构成：

  1. 主服务的复制偏移量(Replication Offset)和从服务器的复制偏移量。
  2. 主服务器的复制积压缓冲区(Replication Backlog),默认大小为1M。
  3. 服务器的运行ID(run ID),用于存储服务器标识，如从服务器断线重新连接，取到主服务器的运行ID与重接后的主服务器运行ID进行对比，从而判断是执行部分重同步还是执行完整重同步。

2.2.3 重同步流程

 这里我简单地画了一个重同步流程，大家可以看看做一个大概的了解。

2.3 分布式系统高可用架构

 Redis从单机到主从、再到哨兵模式、最后到集群模式，这一切发展并不是无中生有，而是因为我们在实际场景中有这样的需求。那么我们为何要这么去做，这么去设计，就是因为我们希望自己提供的服务保持一个高可用的状态。Redis、MySQL等这些技术不断在架构方面发展进步，不单单是因为需要性能优化，也是为了整个服务更牢固。

2.3.1 什么是高可用？

 高可用HA(High Availability)顾名思义就是指整个服务功能尽可能地每时每刻都保证一个正常可用的状态，在分布式系统架构设计中也是必须考虑的因素之一，通过设计减少系统不能提供服务的时间。

2.3.2 高可用

 对于高可用，有几点核心要点：

  1. 单点设计是系统高可用的大敌，应该尽量在系统设计的过程中避免单点设计。
  2. 保证系统高可用架构设计的核心准则是：冗余。
  3. 设计高可用架构一定需要考虑故障转移，若出现故障都由人工介入恢复势必会影响系统正常服务时间

2.3.3 典型互联网系统分层架构

 我们这里来看看一个典型的互联网系统分层架构整个流程是怎么样的。

  1. 客户端发起一个请求会先通过DNS域名系统去解析，然后通过解析后的IP进行访问。
  2. 客户端层到代理层的高可用主要是通过代理层的冗余实现。以这里的Nginx为例，我们会部署两台Nginx，一台提供对线上的服务，另一台用作后备来保证高可用，Nginx可以通过KeepAlived存活检测来保证高可用切换。
  3. 代理层到应用服务层的高可用是通过服务站点冗余实现的，我们在Nginx中会配置多个服务站点路径，在请求服务时会根据指定算法分配到某台服务上，并且Nginx也能够检测到多个服务的存活性以便随时可以修改请求分配规则。
  4. 应用服务层到缓存层的高可用主要通过缓存数据冗余来实现。Redis自身提供复制功能，支持主从同步，并且官方还提供了Sentinel哨兵机制做存活检测、自动选举等功能用来保证Redis高可用。
  5. 应用服务层到数据库层的高可用和缓存层类似，主要通过主从同步、读写分离等架构实现高可用，读库高可用一般采取多台服务部署冗余数据的方式，写库高可用采用KeepAlived存活检测、binlog同步等方式保证高可用。

3.哨兵模式

 在我们使用主从模式时，从节点主要有两个作用：

  1. 分担主节点读压力，保证数据安全性。
  2. 主节点宕机后，从节点可以作为主节点的备份顶上来。

 那么如果主节点宕机后，我们需要如何操作？首先将即将顶替主节点的从节点取消主备，然后将另外的从节点绑定上新的主节点。

 slaveof no one       # 取消主备，变更为主节点
 slaveof 新host  新节点  # 将其他节点设置为新主节点的备份节点

 这整个过程，包括从节点晋升为主节点，其他从节点修改关联主节点都需要人工操作，对于系统高可用都是不理想的方式。值的高兴的是，Redis已经给我们提供了Sentinel哨兵模式，哨兵模式就是自动帮我们去做灾备故障转移的一个机制。

3.1 哨兵模式搭建

 我们在Redis下新建一个目录sentinel用于存放哨兵配置文件，然后我们需要修改几个地方：

mkdir sentinel
cp sentinel.conf ./sentinel/sentinel_1.conf
vi ./sentinel/sentinel_1.conf

sentinel monitor mymaster 127.0.0.1 6379 1   
sentinel down-after-milliseconds mymaster 10000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

 这里我们在使用时主要需要修改这几个配置：

  1. sentinel monitor mymaster 127.0.0.1 6379 1：主节点名称为mymaster ，最后一个参数1表示将这个主服务器判断为失效至少需要1个Sentinel投票，只要投票Sentinel的数量不够，自动故障迁移就不会执行。
  2. down-after-milliseconds：设置Sentinel判定服务器已经断线所需的毫秒数。
  3. failover-timeout：failover(失效备援，即灾备故障转移)过期时间。当failover开始后，在该时间内未触发任何failover操作，当前sentinel将会认为此次failoer失败。
  4. parallel-syncs：设置在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。
    ps:如果从服务器被设置为允许使用过期数据集， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入主服务器发来的RDB文件时， 仍然会造成从服务器在一段时间内不能处理命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。

 修改完配置后，我们通过./src/redis-sentinel ./sentinel/sentinel_1.conf启动哨兵，可以看到当前哨兵监控的一些信息。

 此时我们将6379端口主服务停止。

 再去查看6380服务可以发现已经成为主节点，并且6381也已经成为6380的从节点。


 在我们实际开发中搭建的Redis一般是3主3从或者是3主6从，这里通过Sentinel很便捷就实现了主从灾备切换。
`

3.2 哨兵模式三大工作任务

 哨兵模式的运用主要是由于它有三大工作任务：

  1. 监控(Monitoring)： Sentinel 会不断地检查主服务器和从服务器是否运作正常。
  2. 提醒(Notification)： 当被监控的某个Redis服务器出现问题时， Sentinel可以通过API向管理员或者其他应用程序发送通知。
  3. 自动故障迁移(Automatic failover)： 当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为变更为新的主从关系。当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

 说到服务故障，这里再提及两个相关概念：冷备和热备。

  1. 冷备：冷备份发生在服务已经正常关闭的情况下，当正常关闭时会提供给我们一个完整的数据库。
    优点：效率很高，只需备份文件，维护度低安全性高。
    缺点：单独使用时只能够提供某一个时间点的备份数据恢复，例如每天凌晨12点备份一次，则两天之间服务若出现问题则会出现部分数据丢失；在备份过程中，服务必须用作备份而不能同时用于提供服务。
  2. 热备：热备份是在服务运行状态下，采用archivelog mode方式备份数据库。
    优点：备份时间短，备份时不影响服务正常运行，可达秒级恢复。
    缺点：无法根据时间点维度恢复数据，维护困难。

3.3 哨兵模式工作模式

 在了解哨兵模式之后，其实我们对其工作原理也有了一个大概的认识，哨兵对于节点的处理主要依靠主观下线和客观下线。

  1. 主观下线：概念主观下线(Subjectively Down，简称SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。
    特点：如果一个服务器没有在master-down-after-milliseconds指定时间内 对向它发送PING命令的Sentinel返回一个有效回复(valid reply)，那Sentinel就会将这个服务器标记为主观下线。
    服务器PING命令有效回复：+PONG、-LOADING错误 、-MASTERDOWN 错误。
  2. 客观下线：多个Sentinel实例对同一个服务器做出SDOWN判断， 并通过SENTINEL is-master-down-by-addr命令互相交后，得出的服务器下线判断。一个Sentinel可以通过向另一个Sentinel发送SENTINEL is-master-down-by-addr命令来询问对方是否认为给定的服务器已下线。
    特点：从主观下线状态切换到客观下线状态并没有使用严格的法定人数算法(strong quorum algorithm)，而是使用了流言协议：如果Sentinel在给定的时间范围内，从其他 Sentinel 接收到足够数量的主服务器下线报告，那Sentinel就会将主服务器的状态从主观下线改变为客观下线。如果之后其他 Sentinel 不再报告主服务器已下线，那么客观下线状态就会被移除。
    ps：客观下线条件只适用于主服务器，对于任何其他类型的Redis实例，Sentinel在将它们判断为下线前不需要进行协商，所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。 只要一个 Sentinel 发现某个主服务器进入了客观下线状态，这个 Sentinel 就可能会被其他 Sentinel 推选出，并对失效的主服务器执行自动故障迁移操作。另外当一个主服务器下线之后再次上线，那么它则会成为从服务器角色，而非主服务器。

3.4 SpringBoot整合哨兵模式

 由于哨兵模式是Redis官方提供的，所以在新版本整合Redis时也提供了该模式的支持，只需要稍微修改即可直接使用。首先导包必不可少，在之前已经使用Redis单机或者主从的项目则已经完成该步骤。这里我们用之前分布式锁Redis - 分布式锁实现以及相关问题解决方案中的项目快速修改验证即可。

pom.xml

<!-- SpringBoot整合Redis-->
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

 这里只需要将之前单机模式或者集群模式IP配置稍作修改即可。

application.properties

#spring.redis.cluster.nodes=10.200.11.214:6379,10.200.11.214:6380,10.200.11.214:6381 集群配置
#spring.redis.host=10.200.11.214 单机配置
#spring.redis.port=6379
# redis集群中的哨兵模式配置
spring.redis.sentinel.master=mymaster
# 哨兵模式集群 多台哨兵监控一组redis集群
spring.redis.sentinel.nodes=10.200.11.214:26379

 启动项目，验证结果，大功告成。

Lock success,execute business,current time:1562570310300
Lock expand expire success! 192.168.126.1:8081
Lock expand expire success! 192.168.126.1:8081

4.高可用集群

 即使我们使用了哨兵，每个Redis实例仍然是全量存储数据，每个Redis存储的内容都是完整的数据，浪费内存影响性能。为了可以最大化利用内存，cluster集群出现了，也就是分布式存储。即每台redis存储不同的内容，采用redis-cluster架构正是如此。关于redis-cluster架构中如何将数据分片存储存储的后面我们会讲到。

 在Redis官方文档中对集群架构有一段说明：在集群架构下，默认master用于接收读写，slave只用于备份。当请求发送到slave时则会重定向到对应的master处理。若能够接受读取的是可能过期的数据并且对写请求于鏊求，则可通过Readonly命令将
slave设置为只读，从而达到读写分离。

4.1 集群搭建

4.1.1 配置文件

 我们在之前已经安装的Redis目录下新建一个cluster文件夹用于存放集群配置的配置文件，先准备六个目录。

mkdir cluster
cd cluster

mkdir 7000
mkdir 7001
mkdir 7002
mkdir 7003
mkdir 7004
mkdir 7005

 然后我们将默认的redis.conf文件复制一份放置每个目录下。

cp redis.conf ./cluster/7000
cp redis.conf ./cluster/7001
cp redis.conf ./cluster/7002
cp redis.conf ./cluster/7003
cp redis.conf ./cluster/7004
cp redis.conf ./cluster/7005

 现在我们修改配置文件，大部分配置相同，但是有几个不同的需要注意，注释中带*即为需要根据端口区分的。

protected-mode no //保护模式
daemonize    yes                          //redis后台运行
port  7000                                //端口7000,7001,7002,7003,7004,7005 *该配置根据端口修改
cluster-enabled  yes                      //开启集群
cluster-config-file  nodes_7000.conf      //集群的配置  配置文件首次启动自动生成 7000,7001,7002,7003,7004,7005 *该配置根据端口修改名称
cluster-node-timeout  5000                //请求超时  设置5秒够了
appendonly  yes                           //aof日志开启  有需要就开启，它会每次写操作都记录一条日志
bind 172.16.244.144                       //IP   ifconfig查看ip addr
logfile "/usr/local/redis/redis-4.0.6/log/redis_7000.log"   //log文件路径 *该配置根据端口修改名称

4.1.2 启动集群节点

 这里复制服务启动文件，并分别启动各节点。

cp ../src/redis-server ./
./redis-server 7000/redis.conf
./redis-server 7001/redis.conf
./redis-server 7002/redis.conf
./redis-server 7003/redis.conf
./redis-server 7004/redis.conf
./redis-server 7005/redis.conf

 ps -ef|grep redis查看运行状态，这里可以看到已经启动成功。

 在启动各节点这一步，可能有些同学会碰到一些问题，比如我这里遇到的open file数量已满，nodes.conf文件重复等，这里我们可以通过之前设置的logfile路径下生成的日志找出对应问题的解决答案，这里给大家推荐一篇博客Redis 启动警告解决，或许对大家有帮助。

4.1.3 创建集群

 我们上面已经启好了需要作为集群节点的服务，现在我们需要通过官方提供的redis-trib.rb去创建集群将这些节点关联起来。看到.rb后缀大家应该知道，这是Ruby的扩展名，这里创建集群我们是需要安装了Ruby环境的，在这整个环节中还是很容易碰见各种问题的，这里我们一步步来看如何解决这些问题。当然还有一些其他这里没遇到的问题，需要大家自行去查阅资料解决。
 其实整个过程主要就是以下两个命令，顺利安装万事大吉，但是由于涉及到了其他编译环境大家可能会遇到一些问题。

  yum -y install ruby ruby-devel rubygems rpm-build 
  gem install redis

 首先在我们使用gem install redis命令时，会遇到上面的问题，这可能是由于镜像源连接时出现问题，我们可以通过修改gem源解决。【报Unable to download data from https://rubygems.org/的解决方案】

gem sources -r https://rubygems.org/
gem sources -a http://rubygems.org

 修改了源之后，我们再次去运行gem install redis，这次它告诉我们Ruby版本过低，那我们再去将Ruby升级好了。
 我这台服务器由于有网络受限，很多镜像网站包括下载源无法访问，大家大部分都可以通过【redis requires Ruby version >= 2.2.2问题】这篇博客解决，这里我通过离线安装Ruby去解决这个问题。受限我们通过【Ruby官网】去下载一个比较新版本的Ruby，根据提示2.3.0及以上即可，这里我选择的是比较新的2.6.3。

 这里我们将下载好的包放在/usr/local下，并通过tar -zxvf ruby-2.6.3.tar.gz命令解压出来。

 解压成功后，进入解压目录，通过./configure --prefix=/usr/local/ruby指定安装路径。

 指定完安装目录后通过make && make install开始编译安装。

 后面这两个过程可能会耗费一点时间，不过付出是有回报的。安装完成后我们通过ruby -v查看当前Ruby版本号。

 这里看到目前系统应用的Ruby版本号为1.8.7而不是我们的2.6.3，这是由于linux本身会带有低版本的ruby环境，这里我们通过vi /etc/profile修改配置文件。

 这里需要注意的是，我们需要将我们自己安装的Ruby路径放在$PATH前面，这样才能优先使用我们自己的Ruby版本。修改保存后再通过source /etc/profile使其立即生效。再次查看Ruby版本，已经变为我们自己安装的版本了。

 再次执行gem install redis命令，大功告成。

 其实整个过程还是很曲折的，不过就是在这种不断磕磕碰碰中才能更快提升我们自己的能力。接下来我们去利用之前启动的节点创建集群。首先进入到之前Redis目录下，通过src/redis-trib.rb create --replicas 1 10.200.11.214:7000 10.200.11.214:7001 10.200.11.214:7002 10.200.11.214:7003 10.200.11.214:7004 10.200.11.214:7005创建节点。

 这里可以看到7000-7002端口被分配为主节点，而7003-7005端口被分配为从节点。并且可以看到各个节点生成的节点ID以及每个主节点所被分配负责的slots,即数据分片，这个下面会提到。此时我们可以去通过连接客户端验证，到这里集群搭建就成功了。如果在安装中还碰到一些问题也可以参考这篇博客【Linux 安装Ruby详解(在线和离线安装)】。另外我们用于搭建集群的节点关闭最好不要用kill命令杀死，可以通过./src/redis-cli -p 7000 shutdown命令去关闭比较稳妥。

4.2 集群特点

4.2.1 集群数据分片

 Redis 集群总共有16384个哈希槽,每个key通过CRC16校验后对16384取模(hash_slot = crc16(key) mod 16384)来决定放置哪个槽.集群的每个节点负责一部分hash槽,。

 以我们之前搭建的集群为例，节点7000约包含0-5460号哈希槽、节点7001约包含5461-10922号哈希槽、节点7002约包含10923-16838号哈希槽。节点7003属于节点7000从节点，节点7004属于节点7001从节点，节点7005属于节点7002从节点。当一对主从节点都挂掉，例如节点7000和节点7003同时挂掉时整个集群是不可用的。这里我们可以通过客户端随便连接一台通过cluster nodes查看集群状态。

 这里哈希槽的分配和我们之前预计的是一致的，并且可以看到这里每个节点都还包含一个服务端口+10000的端口号，这个端口号用于集群内部通信。

4.2.2 集群主从复制模型

 Redis为了使部分节点失败或者大部分节点无法通信的情况下集群仍然可用，同时还采用了主从复制模型。每个节点都会有N-1个复制品。在我们上面例子中具有7000,7001,7002三个节点的集群，假如没有复制模型的情况下节点7001失败了或者无法通信，那么整个集群就会由于缺少5461-10922范围的槽而不可用。Redis集群做主从备份就是为了解决这个问题。

4.2.3 集群一致性保证

 从节点同步主节点命令的操作在主节点返回响应给客户端之后，这是因为若每次主节点处理命令请求都需要等待复制同步完成的话，那么主节点处理命令请求的速度将大大地降低。故必须在性能和一致性之间做出权衡。例如客户端请求主节点进行操作后，主节点还未来得及同步命令给从节点就挂掉，此时从节点会顶替上来成为主节点，但是由于同步不及时就会丢失这次操作的命令。

4.2.4 集群模拟故障转移

 这里我们手动将一个主节点下线，看看集群会有怎样的一个变化。这里主要涉及的命令就是debug segfault。

 此时我们将7000节点下线，再通过其他节点去查看集群状态。

 此时可以看到，7000节点已经下线，对应的7003从节点顶上来成为了主节点并且负责0-5460哈希槽的数据操作。

4.3 集群分片重哈希

4.3.1 集群重新分片

 在集群中，我们是可以通过操作手动进行哈希槽重新分片的。这里我们通过src/redis-trib.rb reshard 10.200.11.214:7003连接上7003所在的集群，并且制定需要重新分片的哈希槽以及分配到哪个节点上。

 分配完成后可以通过cluster nodes查看集群状态。大家可以和之前节点哈希槽分配比对，这里是发生了变化的，7003和7002各分配50个哈希槽给7001节点。

4.3.2 集群添加主节点

 我们将之前集群节点配置文件拷贝一份，修改节点端口为7006之后启动。通过./src/redis-trib.rb add-node 10.200.11.214:7006 10.200.11.214:7001将7006节点添加到7001节点所在集群中。

 此时再去查看集群状态，可以发现7006端口已经加入到集群中。只是此时并没有哈希槽分配在该节点上。

4.3.3 集群添加从节点

 这里和上面添加主节点一样，我们先启动一个节点7007，通过./src/redis-trib.rb add-node --slave 10.200.11.214:7007 10.200.11.214:7001将7007节点以从节点角色添加到7001节点所在集群中。

 此时再去查看集群状态，可以发现7007端口已经加入到集群中，并且此时作为7003节点的从节点。由于之前7003属于7000从节点，我们将7000节点关闭之后7003作为主节点而不具备从节点，所以这里自动将7007节点挂为7003节点的从节点了。

4.3.4 集群移除节点

 移除节点也十分简单，这里我们通过./src/redis-trib.rb del-node 10.200.11.214:7001 4fe7575cf1e40f0f54f04b3d6b0f10f7bd1dc456命令移除7006节点。这里需要注意的是和之前有点顺序不一样，第一个参数是集群中可连接的节点，第二个参数是需要移除的集群节点ID.

 移除节点后，再查看节点状态可以看到7006节点已经不存在该集群中。

 这里有一点需要注意的是，移除从节点可以直接移除成功，但是移除主节点需要先确保该节点没有已分配的哈希槽。

4.4 SpringBoot整合集群

 SpringBoot整合Redis集群十分简单，在我们之前项目的基础上，只要将配置文件中单机或者哨兵模式ip:port的相关配置修改为下面的即可。

spring.redis.cluster.nodes=10.200.11.214:7000,10.200.11.214:7001,10.200.11.214:7002,10.200.11.214:7003,10.200.11.214:7004,10.200.11.214:7005