【Redis哨兵集群】

@

目录

• 开始配置主从复制
• 开始配置Redis Sentinel

---

在开始之前，我们先来看看Redis的主从复制

主从复制原理：

1. 从服务器向主服务器发送SYNC命令。
2. 主服务器接到SYNC命令后，会调用BGSAVE命令，创建一个RDB文件，并使用缓冲区记录接下来执行的所有写命令。
3. 当主服务器执行完BGSAVE命令后，会向从服务器发送RDB文件，而从服务器则会接收并执行这个文件。
4. 主服务器将缓冲区存储的所有写命令发送给从服务器执行。

---------

Redis主从复制使用的是RDB备份方式来同步主从服务器的数据的。

同步开始之后，通过主库命令传播的方式，主动复制方式实现。

2.8以后实现PSYNC饿机制，实现断线重连。

Redis主从复制的背景问题



Reids主从复制可将主节点数据同步给从节点，从节点此时有两个作用：

1. 一旦主节点宕机，从节点作为主节点的备份可以随时顶上来.
2. 扩展主节点的读能力，分担主节点的读压力.

.

一旦主节点宕机，从节点上位，那么就需要人为修改所有应用方的主节点地址（指定新的master地址），还需要命令所有从节点复制新的主节点.

这个问题很麻烦，而redis-sentinel就可以很好的解决这个问题.

---

Redis-Sentinel



    Redis-Sentinel是redis官方推荐的高可用性能解决方案，当用redis做master-slave的高可用时，如果master本机宕机，redis本身或者客户端都没有实现主从切换的功能，而redis-sentinel是一个独立运行的进程，用于监控多个maser-slave集群，其自动发现master宕机，进行自动切换：slave > master

---

Sentinel主要功能

• 不时的监控redis是否良好运行，如果节点不可达就会对节点做下线标示.
• 如果被标示的是主节点，则sentinel就会和其它的sentinel节点“协商”，如果其它节点也认为主节点不可达，就会选举一个sentinel节点来完成自动故障转移.
• 在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换.

---

Sentinel工作原理



每一个Sentinel以每秒钟一次的频率向它所知的所有Master、Slave以及其它Sentinel实例发送一个PING命令.



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



如果一个Master被标记为主观下线，则正在监视这个Master的所有Sentinel都会以每秒一次的频率确认这个Master的确进入了主观下线状态.



当有足够数量的Sentinel(大于等于配置文件中指定的值)在指定的时间范围内确认这个Master的确进入了主观下线状态，那么这个Master会被标记为客观下线.



在一般情况下，每个Sentinel会以每10秒一次的频率向它已知的所有Master、Slave发送INFO命令.



当有Master被Sentinel标记为客观下线时，Sentinel向下线的Master的所有Slave发送INFO命令的频率会从10秒一次改为每秒一次.



若没有足够数量的Sentinel同意Master已经下线，则此Master的客观下线状态就会被移除.

---

主观下线和客观下线



主观下线

Subjectively Down，简称SDOWN，指的是当前Sentinel实例对某个redis服务器做出的下线判断



客观下线

Objectively Down，简称ODOWN，指的是多个Sentinel实例在对Master Server做出SDOWN判断，并且通过SENTINEL is-master-down-by-addr命令互相交流之后，得出的Master Server下线判断，然后开启failover.



SDOWN

适合于Master和Slave，只要一个Sentinel发现Master进入了ODOWN，这个Sentinel就可能会被其它Sentinel推选出，并对下线的主服务器执行自动故障迁移操作.



ODOWN

只适用于Master，对于Slave的Redis实例，Sentinel在将它们判断为下线前不需要进行协商，所以Slave的Sentinel永远不会到达ODOWN.

主从复制架构图

Redis Sentinel架构图



Sentinel是redis一个进程，不存储数据，只负责监控redis.



关于Redis的发布订阅，详见此文献【Redis发布订阅】

---

开始配置主从复制

搭建环境：

一台Redis服务器（版本redis-5.0.2）

三个Redis实例（一个主节点Master，两个从节点Slave）

配置文件

---

主节点 7001.conf

port 7001
daemonize yes
logfile /usr/local/redis-5.0.2/logs/7001.log
dbfilename dump-7001.rdb
dir /usr/local/redis-5.0.2/db/7001/

从节点 7002.conf

port 7002
daemonize yes
logfile /usr/local/redis-5.0.2/logs/7002.log
dbfilename dump-7002.rdb
dir /usr/local/redis-5.0.2/db/7002/

# 指定主节点
slaveof 127.0.0.1 7001

从节点 7003.conf

port 7003
daemonize yes
logfile /usr/local/redis-5.0.2/logs/7003.log
dbfilename dump-7003.rdb
dir /usr/local/redis-5.0.2/db/7003/

# 指定主节点
slaveof 127.0.0.1 7001

验证主从关系

---

在主节点上查看主从通信关系





在从节点上查看主从通信关系

此时，一主双从已经搭建完毕了，可在Master上写入些数据，然后在Slave查看.

---

开始配置Redis Sentinel

搭建环境：

包含上面搭建主从的所有环境

还增加了三个redis-sentinel实例（27001.conf、27002.conf、27003.conf）

配置文件

---

27001.conf

port 27001
daemonize yes
dir "/usr/local/redis-5.0.2/db/"
logfile "/usr/local/redis-5.0.2/logs/27001.conf"

sentinel monitor mymaster 127.0.0.1 7001 2
# mymaster：主节点的别名
# 当前Sentinel节点监控 127.0.0.1 7001 这个主节点
# 2：表示主节点失败至少需要2个Sentinel节点同意

sentinel down-after-milliseconds mymaster 30000
# 每个Sentinel节点都要定期发PING命令来判断Redis数据节点和其余Sentinel节点是否可达
# 这里配置为30000毫秒，即超过30秒未收到某个节点的PING命令且未收到回复，则判定不可达

sentinel parallel-syncs mymaster 1
# 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点
# 原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1

sentinel failover-timeout mymaster 180000
# 设定故障转移的超时时间为180000毫秒

27002.conf、27003.conf的配置与上面的配置(27001.conf)差异仅在于端口.

启动哨兵：redis-sentinel 配置文件

启动后，哨兵的配置文件会被重写入sentinel myid等信息.

验证哨兵集群

---

[root@fedora conf]# redis-cli -p 27001 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:7003,slaves=2,sentinels=3
# 看到最后一条信息即正确配置了哨兵集群
# name=mymaster  -> 哨兵别名
# status=ok  -> 状态OK
# address=127.0.0.1:7003  -> 监控的地址
# slaves=2 -> 当前有2个从节点
# sentinels=3  -> 当前共有3个哨兵

到这里，哨兵集群已经搭建完毕了.

不用说，此时你肯定是想去干掉主节点了吧，先别慌，我们来看看下面的监控扩扑图.

监控扩扑图

验证故障转移的大致思路

• 干掉主节点的Redis进程7001端口，等待down-after-milliseconds配置的时间后，观察从节点是否会进行新的master选举，进行切换.
• 重新恢复旧的“master”节点，查看此时的redis身份.