Redis（3）- Redis集群

一、前言

大型网站应用中，数据和请求量往往巨大，单机性能有限，使用一台 Redis 实例显然无法满足需求，而且单机服务一旦故障整个系统就无法继续提供服务了。

这时就需要使用多台 Redis （集群）作为缓存数据库。才能在用户请求时快速的进行响应，也能保证服务的稳定。

二、Redis的三种集群模式

Redis的三种集群模式主要是：主从模式（redis2.8版本之前的模式）、哨兵sentinel模式（redis2.8及之后的模式）和redis cluster集群模式（redis3.0版本之后）。

1.主从模式

（1）模式来源：

同Mysql主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。

为了分担读压力，Redis支持主从复制，在主从复制中，数据库分为两类：主数据库(master)和从数据库(slave)。

Redis的主从结构可以采用一主多从或者级联结构，客户端可对主数据库进行读写操作，对从数据库进行读操作，主数据库写入的数据会实时自动同步给从数据库。

（2）工作机制：

当主数据库slave启动后，主动向从数据库master发送同步SYNC命令。

master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。

slave接收到快照文件和命令后加载快照文件和缓存的执行命令。

复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。

（3）优缺点

优点

• master能自动将数据同步到slave，可以进行读写分离，分担master的读压力；
• master、slave之间的同步是以非阻塞的方式进行的，同步期间，客户端仍然可以提交查询或更新请求

缺点

• 不具备自动容错与恢复功能。主从模式下，master节点在主从模式中唯一，若master挂掉，则redis无法对外提供写服务，导致客户端请求失败，需要等待机器重启或手动切换客户端IP才能恢复；
• master宕机，如果宕机前数据没有同步完，则切换IP后会存在数据不一致的问题
• 难以支持动态扩容，Redis的容量受限于单机配置。

（4）部署实例 — master-slaver 一主二从

redis安装这里不重复了，见第一节

1)创建配置文件

redis 解压后，redis home 目录下有 redis 配置的样例文件，我们不直接在此文件上就行修改，在redis home目录下新建文件夹 master-slave ，将配置文件都放于此目录下，下面是三个 redis 节点配置的关键部分

• master 配置文件：redis-6379.conf

port 6379 
daemonize yes 
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/opt/soft/redis/data"

• slave-1 配置文件：redis-6380.conf

port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/opt/soft/redis/data"
# 关键配置：将这个 redis 指定为某个第一个 redis 的 slaver
slaveof 127.0.0.1 6379

• slave-2 配置文件：redis-6381.conf

port 6381 
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
dir "/opt/soft/redis/data"
# 关键配置：将这个 redis 指定为某个第一个 redis 的 slaver
slaveof 127.0.0.1 6379

配置参数说明：
port ：端口
daemonize：守护进程

• daemonize:yes:redis采用的是单进程多线程的模式。当redis.conf中选项daemonize设置成yes时，代表开启守护进程模式。在该模式下，redis会在后台运行，并将进程pid号写入至redis.conf选项pidfile设置的文件中，此时redis将一直运行，除非手动kill该进程。
• daemonize:no: 当daemonize选项设置成no时，当前界面将进入redis的命令行界面，exit强制退出或者关闭连接工具(putty,xshell等)都会导致redis进程退出。

logfile：日志文件
dbfilename： 指定本地数据库文件名
dir：指定本地数据库存放目录
slaveof：设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步

2)分别启动这三个redis服务

redis-server  redis-6379.conf &
redis-server  redis-6380.conf &
redis-server  redis-6381.conf &

查看进程

用 info replication 查看这三个 redis-server 之间的关系

这样我们就顺利的完成了 一主二从 redis 环境的搭建

2.哨兵模式（Sentinel）

（1）模式来源：

主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因此sentinel应运而生。

sentinel中文含义为哨兵，顾名思义，它的作用就是监控redis集群的运行状况。

那么如何得知某一台redis服务器挂了，如何切换，如何保证备份的机器是原始服务器的完整备份呢？

这时候就需要Sentinel和Replication（复制）出场了。Sentinel可以管理多个Redis服务器，它提供了监控，提醒以及自动的故障转移的功能；Replication则是负责让一个Redis服务器可以配备多个备份的服务器。Redis也是利用这两个功能来保证Redis的高可用的。

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。

（2）工作机制：

每个Sentinel（哨兵）进程以每秒钟一次的频率向整个redis集群中的master主服务器、slave从服务器以及其他的Sentinel（哨兵）进程发送一个ping命令。

如果一个实例距离最后一次有效回复ping命令的时间超过down-after-milliseconds选项所指定的值则这个实例会被Sentinel标记为主观下线（SDOWN）。

如是是master主服务器被标记为SDOWN，则正在监控这个服务器的所有Sentinel都要以每秒一次的频率确认服务器是否真的已经进入SDOWN(主观下线状态)。

当有足够数量（≥配置文件配置值）的Sentinel在指定的时间内确认了master进入了SDOWN状态，则master被标记为ODOWN(客观下线状态)。客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。

在一般情况下，每个Sentinel会每10秒向redis 主服务器和从服务器发送Info命令。但是当master被标记为客观下线时，频率改为1秒一次。若没有足够数量的Sentinel同意master服务器下线，则master的SDOWN状态被移除，若master重新向Sentinel发送ping命令返回了有效回复，则master的SDOWN状态被移除。

在master主服务器失效故障时，Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

如果 sentinel 宕机，客户端是不是就找不到redis服务了呢？sentinel 本身也支持集群部署，并且各个 sentinel 之间支持自动监控，所以sentinel本身也支持高可用的。

（3）三个特点

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

（4）部署实例 — sentinel集群

sentinel 本质上是一个特殊的 redis，大部分配置和普通的 redis 没有什么区别，主要区别在于端口和其哨兵监控设置。
下面演示典型的三个 sentinel组成一个 sentinel 集群，端口分别是 23679，23680，23681

1）三个 sentinel 配置文件

• sentinel-26379.conf

#设置 sentinel 工作端口
port 26379
#后台运行 
daemonize yes
#日志文件名称
logfile "26379.log"
#设置当前 sentinel 监控的 redis ip 和 端口
sentinel monitor mymaster 127.0.0.1 6379 2
#设置判断 redis 节点宕机时间
sentinel down-after-milliseconds mymaster 60000
#设置自动故障转移超时
sentinel failover-timeout mymaster 180000
#设置同时故障转移个数
sentinel parallel-syncs mymaster 1

• sentinel-26380.conf

#设置 sentinel 工作端口
port 26380
#后台运行 
daemonize yes
#日志文件名称
logfile "26380.log"
#设置当前 sentinel 监控的 redis ip 和 端口
sentinel monitor mymaster 127.0.0.1 6379 2
#设置判断 redis 节点宕机时间
sentinel down-after-milliseconds mymaster 60000
#设置自动故障转移超时
sentinel failover-timeout mymaster 180000
#设置同时故障转移个数
sentinel parallel-syncs mymaster 1

• sentinel-26381.conf

#设置 sentinel 工作端口
port 26381
#后台运行 
daemonize yes
#日志文件名称
logfile "26381.log"
#设置当前 sentinel 监控的 redis ip 和 端口
sentinel monitor mymaster 127.0.0.1 6379 2
#设置判断 redis 节点宕机时间
sentinel down-after-milliseconds mymaster 60000
#设置自动故障转移超时
sentinel failover-timeout mymaster 180000
#设置同时故障转移个数
sentinel parallel-syncs mymaster 1

配置参数说明

• sentinel monitor [master-group-name] [ip] [port] [quorum]
  这个命令中【master-group-name】是 master redis 的名称；【ip】和【port】分别是其 ip 和端口，很好理解。最后一个参数【quorum】是”投票数“
  举个栗子，redis 集群中有3个 sentinel 实例，其中 master 挂掉了，如果这里的票数是2，表示有2个 sentinel 认为 master 挂掉啦，才能被认为是正真的挂掉啦。其中 sentinel 集群中各个 sentinel 之间通过 gossip 协议互相通信。
  具体怎样投票还涉及到 redis 集群中的【主观下线】和【客观下线】的概念，后面再详细介绍。
• down-after-milliseconds
  sentinel 会向 master 发送心跳 PING 来确认 master 是否存活，如果 master 在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个 sentinel 会主观地认为这个 master 已经不可用了。而这个down-after-milliseconds 就是用来指定这个“一定时间范围”的，单位是毫秒。
• failover-timeout
  这个参数 redis 官方文档中并未做详细说明，但是很好理解，就是 sentinel 对 redis 节点进行自动故障转移的超时设置，当 failover（故障转移）开始后，在此时间内仍然没有触发任何 failover 操作，当前sentinel 将会认为此次故障转移失败。
• parallel-syncs
  当新master产生时，同时进行 slaveof 到新 master 并进行同步复制的 slave 个数,也就是同时几个 slave 进行同步。因为在 salve 执行 salveof 与新 master 同步时，将会终止客户端请求，因此这个值需要权衡。此值较大，意味着“集群”终止客户端请求的时间总和和较大，此值较小,意味着“集群”在故障转移期间，多个 salve 向客户端提供服务时仍然使用旧数据。

2）启动sentinel集群

启动方式有两种，两种启动方式没有区别

redis-sentinel /path/to/sentinel.conf

redis-server /path/to/sentinel.conf --sentinel

启动完成后，连接其中一个sentinel节点查看集群关系：

info sentinel 命令可以看到这个 sentinel 监控的 master redis 服务的 ip，端口，以及 maste 的 slaver 节点数量，以及 sentinel 的数量。
再连接26380这个节点看看：

可以看到结果和上面一样。如此，我们的 sentinel 集群也部署完成了。

3）高可用测试

我们手动把一主二从中的主节点 kill 掉：

然后连接 6380 节点，查看集群状态：

可以看到 6380 节点已经自动升级为了 master 节点，还有 6381 这一个 slaver 节点，自动故障转移成功

我们再手动启动 6379 节点，观察集群状态：

如图，6379节点重新启动后，自动变成了 6380 节点的从节点。

如此一套完整的 redis 高可用方案就部署完成了。

3、集群（Cluster ）

（1）模式来源：

sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。单台服务器资源的总是有上限的，CPU资源和IO资源我们可以通过主从复制，进行读写分离，把一部分CPU和IO的压力转移到从服务器上。但是内存资源怎么办，主从模式做到的只是相同数据的备份，并不能横向扩充内存；单台机器的内存也只能进行加大处理，但是总有上限的。所以我们就需要一种解决方案，可以让我们横向扩展。cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。

使用集群，只需要将redis配置文件中的cluster-enable配置打开即可。每个集群中至少需要三个主数据库才能正常运行，新增节点非常方便。还有就是客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

（2）工作机制：

在redis的每一个节点上，有两样东西我们比较关注，一个是插槽（slot），它的取值范围是：0~16383。还有一个就是cluster，它类似是一个集群管理的插件。当我们的存取的key到达的时候，通过对 Key 进行 CRC16(key)%16384 运算得到对应的槽是哪一个，这样每个 key都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

Redis Cluster 一般由多个节点组成，节点数量至少为 6 个才能保证组成完整高可用的集群，其中三个为主节点master，三个为从节点slave，三个主节点会分配槽。一个节点组有且仅有一个master，同时有0到多个slave。只有主节点master对外提供写服务，读服务可由 master/slave 提供。处理客户端的命令请求，而从节点可用在主节点故障后，顶替主节点。

上图中，key-value 全集被分成了 3 份，3段 slot（Redis Cluster有 16384 [0-16383] 个slot，每个节点服务一段区间的slot）。master主节点，对外提供写服务。分别负责 0 ~ 5460、 5461 ~ 10920和10921 ~ 16383 的slot。master-1/slave-1 、master-2/slave-2 和master-3/slave-3 之间通过主备复制的方式同步数据。

上述的3个节点，两两通过 Redis Cluster Bus 交互，相互交换如下的信息：

1、数据分片（slot）和节点的对应关系；

2、集群中每个节点可用状态；

3、集群结构发生变更时，通过一定的协议对配置信息达成一致。数据分片的迁移、主备切换、单点 master 的发现和其发生主备关系变更等，都会导致集群结构变化。

4、publish/subscribe（发布订阅）功能，在Cluster版内部实现所需要交互的信息。

Redis Cluster Bus 通过单独的端口进行连接，由于Bus是节点间的内部通信机制，交互的是字节序列化信息。相对 Client 的字符序列化来说，效率较高。

Redis Cluster是一个去中心化的分布式实现方案，客户端和集群中任一节点连接，然后通过后面的交互流程，逐渐的得到全局的数据分片映射关系。

（3）部署实例 — Redis Cluster

Redis Cluster 集群至少需要三个 master 节点，本文将以单机多实例的方式部署3个主节点及3个从节点，6个节点实例分别使用不同的端口及工作目录

1）创建工作目录

在redis安装目录下新建redis-cluster，并在该目录下再新建6个子目录，7000，7001，8000，8001，9000，9001。

2）创建配置文件

在每个子目录复制配置文件redis.conf，并根据不同子目录修改一下对应的配置

#开启后台运行
daemonize yes
#工作端口
port 7000
#绑定机器的内网IP或者公网IP,一定要设置，不要用 127.0.0.1，查看网络命令：ip addr或者ifconfig
bind 172.27.0.8  
#指定工作目录，rdb,aof持久化文件将会放在该目录下，不同实例一定要配置不同的工作目录
dir /usr/local/redis-cluster/7000/
#启用集群模式
cluster-enabled yes 
#生成的集群配置文件名称，集群搭建成功后会自动生成，在工作目录下
cluster-config-file nodes-7000.conf 
#节点宕机发现时间，可以理解为主节点宕机后从节点升级为主节点时间
cluster-node-timeout 5000 
#开启AOF模式
appendonly yes 
#pid file所在目录
pidfile /var/run/redis_8001.pid 

3）启动6个节点

./src/redis-server redis-cluster/7000/redis.conf
./src/redis-server redis-cluster/7001/redis.conf
./src/redis-server redis-cluster/8000/redis.conf
./src/redis-server redis-cluster/8001/redis.conf
./src/redis-server redis-cluster/9000/redis.conf
./src/redis-server redis-cluster/9001/redis.conf

查看服务运行状态

[root@VM-0-4-centos redis-cluter]# ps -ef | grep redis
root       453     1  0 15:52 ?        00:00:00 ../src/redis-server 172.17.0.4:7000
root       459     1  0 15:52 ?        00:00:00 ../src/redis-server 172.17.0.4:7001
root       465     1  0 15:52 ?        00:00:00 ../src/redis-server 172.17.0.4:8000
root       471     1  0 15:52 ?        00:00:00 ../src/redis-server 172.17.0.4:8001
root       477     1  0 15:52 ?        00:00:00 ../src/redis-server 172.17.0.4:9000
root      1007     1  0 15:54 ?        00:00:00 ../src/redis-server 172.17.0.4:9001

4）redis cluster创建

不同redis版本redis cluster的创建不一样

1.redis版本<5.xxx

对于低版本的redis，在使用集群方式部署时，redis官方提供了redis集群方式的工具：redis-trib.rb，位于/usr/local/src/redis-5.0.3/src目录下，它是用ruby写的一个程序，所以需要集群方式部署redis之前，需要安装Ruby环境。

安装 Ruby 和 RubyGems

yum install ruby
yum install rubygems

创建 redis cluster

./src/redis-trib.rb create --replicas 1 172.27.0.8:7000 172.27.0.8:7001 172.27.0.8:8000 172.27.0.8:8001 172.27.0.8:9000 172.27.0.8:90001

2.redis版本>=5.xxx

redis cluster安装方式不推荐使用redis-trib.rb，而是使用redis-cli

./src/redis-cli --cluster create 172.27.0.8:7000 172.27.0.8:7001 172.27.0.8:8000 172.27.0.8:8001 172.27.0.8:9000 172.27.0.8:9001 --cluster-replicas 1

登录一个redis节点，使用命令cluster nodes查看集群情况

./src/redis-cli -c -p 7000 -h 172.17.0.4

注意：这里命令要加 -c 参数开启集群模式，要不然操作key所在槽点不在该节点时会报错。

172.27.0.8:7000> cluster nodes
23b41c74723f557b9ffb5d80635e47afcb614f45 172.27.0.8:8001@18001 slave b2b71c05668a100bed6a324cedb37e975ad20582 0 1619424556000 3 connected
4af44ce4ab5869b7e657160d403e63903a066357 172.27.0.8:9001@19002 slave dde212082134d325bb60c33489f3fab6de357281 0 1619424556918 2 connected
b1b10a65889819782ceaff4d3f2a981c1ff228ae 172.27.0.8:9000@19000 slave 7660ac1dea5a1cb42c86d5aa458c22f2c5e8a17f 0 1619424556416 1 connected
dde212082134d325bb60c33489f3fab6de357281 172.27.0.8:7001@17001 master - 0 1619424557419 2 connected 5461-10922
7660ac1dea5a1cb42c86d5aa458c22f2c5e8a17f 172.27.0.8:7000@17000 myself,master - 0 1619424554000 1 connected 0-5460
b2b71c05668a100bed6a324cedb37e975ad20582 172.27.0.8:8000@18000 master - 0 1619424555412 3 connected 10923-16383

如上所示，一个 3主3从的 redis cluster 分布式集群就搭建成功了，7000、7001、8000分别是三个 master 节点，8001、9000和9001为对应的 slaver 节点。

5）高可用测试

手动kill8000主节点，查看节点信息

172.27.0.8:8001> cluster nodes
7660ac1dea5a1cb42c86d5aa458c22f2c5e8a17f 172.27.0.8:7000@17000 master - 0 1619426340000 1 connected 0-5460
4af44ce4ab5869b7e657160d403e63903a066357 172.27.0.8:9001@19001 slave dde212082134d325bb60c33489f3fab6de357281 0 1619426340311 2 connected
23b41c74723f557b9ffb5d80635e47afcb614f45 172.27.0.8:8001@18001 myself,master - 0 1619426339000 7 connected 10923-16383
b1b10a65889819782ceaff4d3f2a981c1ff228ae 172.27.0.8:9000@19000 slave 7660ac1dea5a1cb42c86d5aa458c22f2c5e8a17f 0 1619426339809 1 connected
b2b71c05668a100bed6a324cedb37e975ad20582 172.27.0.8:8000@18000 master,fail - 1619426276562 1619426274000 3 disconnected
dde212082134d325bb60c33489f3fab6de357281 172.27.0.8:7001@17001 master - 0 1619426340813 2 connected 5461-10922

可以看到8000节点显示fail状态，8001节点变成了master节点
再启动恢复8000节点

../src/redis-server 8000/redis.conf

172.27.0.8:7000> cluster nodes
23b41c74723f557b9ffb5d80635e47afcb614f45 172.27.0.8:8001@18001 master - 0 1619426415000 7 connected 10923-16383
4af44ce4ab5869b7e657160d403e63903a066357 172.27.0.8:9001@19001 slave dde212082134d325bb60c33489f3fab6de357281 0 1619426416291 2 connected
b1b10a65889819782ceaff4d3f2a981c1ff228ae 172.27.0.8:9000@19000 slave 7660ac1dea5a1cb42c86d5aa458c22f2c5e8a17f 0 1619426415286 1 connected
dde212082134d325bb60c33489f3fab6de357281 172.27.0.8:7001@17001 master - 0 1619426414283 2 connected 5461-10922
7660ac1dea5a1cb42c86d5aa458c22f2c5e8a17f 172.27.0.8:7000@17000 myself,master - 0 1619426415000 1 connected 0-5460
b2b71c05668a100bed6a324cedb37e975ad20582 172.27.0.8:8000@18000 slave 23b41c74723f557b9ffb5d80635e47afcb614f45 0 1619426415085 7 connected

可以看到8000节点变成了从节点。

当一个节点的master和slave都下线时，该槽范围对应的key将不可使用

172.27.0.8:7000> get a
(error) CLUSTERDOWN The cluster is down

三、总结

Redis 服务的部署方案的选型大家根据自己项目的需求部署即可，一般来说 redis sentinel 就够用了，也是目前用得最多的模式，但是 redis 3.0 之后官方推出的 redis-cluster 虽然本质是用于实现数据分片和分布式存储，但是其也实现了 redis sentinel 的全部功能，有完全的 HA 能力，并且部署起来更简单，因此成为了官方推荐的 HA 方案。我个人也更加推荐 redis cluster 方案。