Redis哨兵模式

3、哨兵模式

3.1、背景

虽然主从复制可以解决主机的压力，确保数据的一致性，但是当主机宕机后，从机不会主动变成主机，重新再剩余的机器中组成主从复制，如果想重新使用主从复制机制就需要人为的将某台从机（slave）变成主机，然后将其他从机再加入新的主机中，这样做比较麻烦，而且可靠性比较低，因此出现了哨兵。

3.2、哨兵模式

---

哨兵：简言之就是想卫士一样，时时刻刻监控着主机，当主机宕机后，它会根据配置的策略在剩余的从机中自动选择一个当做主机，其余从机主动加入新选举的主机中。其实就是反客为主的自动版。

在哨兵模式中一共有三个角色：

1. 主节点（master）：负责处理客户端的读写请求。
2. 从节点（slave）：通过复制主节点的数据来提供读服务，并在主节点发生故障时可以升级为主节点。
3. 哨兵节点（sentinel）：监控Redis集群中的主节点和从节点的状态，并在主节点不可用时实施自动故障恢复。

哨兵节点的主要任务包括：

• 监控：定期检查主节点和从节点的健康状态，包括发送PING命令、检查返回结果和检测通信故障。
• 故障检测：当主节点不可用时，哨兵节点会将主节点标记为下线，并发起选举过程来决定新的主节点。
• 高可用性切换：选举出新的主节点后，哨兵节点会自动将从节点切换为新的主节点，并通知其他从节点更新复制目标。
• 配置提供者：当客户端连接到哨兵节点时，哨兵节点可以根据Redis集群的配置信息，将其重定向到正确的主节点。

哨兵模式的优势是提供了自动的故障检测和切换机制，使得Redis集群能够快速响应主节点故障，并通过升级从节点来实现持续的可用性。同时，哨兵模式还支持动态添加或移除哨兵节点和从节点，以适应不同规模和需求的集群。然而，哨兵模式并不能提供自动的水平扩展和负载均衡机制，需要结合其他方案来实现。

3.3、哨兵模式原理

---

​ sentinel会按照指定的频率给master发送ping请求，看看master是否还活着，若master在指定时间内未正常响应sentinel发送的ping请求，sentinel则认为master挂掉了，但是这种情况存在误判的可能，比如：可能master并没有挂，只是sentinel和master之间的网络不通导致，导致ping失败。为了避免误判，通常会启动多个sentinel，一般是奇数个，比如3个，那么可以指定当有多个sentinel都觉得master挂掉了，此时才断定master真的挂掉了，通常这个值设置为sentinel的一半，比如sentinel的数量是3个，那么这个量就可以设置为2个。

​ 当多个sentinel经过判定，断定master确实挂掉了，接下来sentinel会进行故障转移：会从slave中投票选出一个服务器，将其升级为新的主服务器， 并让失效主服务器的其他从服务器slaveof指向新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

3.4、哨兵模式配置

采用最经典的哨兵模式配置：一主二从三哨兵

角色	地址	端口
Master(主机)	192.168.12.9	6379
Slave(从机)	192.168.12.9	6380
Slave(从机)	192.168.12.9	6381
sentinel(哨兵1)	192.168.12.9	26379
sentinel(哨兵2)	192.168.12.9	26380
sentinel(哨兵3)	192.168.12.9	26381

建议：不要将主机、从机以及哨兵放在同一台服务器上

3.4.1 搭建哨兵模式

主机和从机的配置和在主从复制中的配置一样

在redis的源码中就有一个哨兵的配置文件sentinel.conf,在这个配置文件中只需要修改几个关键点即可

为了方便统一管理，建议新建一个目录，把配置文件都放在同一个文件夹下面

#在opt/redis-6.2.12目录下创建已个文件夹:sentinel
mkdir sentinel
chmod 777 sentinel

1.配置哨兵1:sentinel-26379.conf

# 配置文件目录
dir /opt/redis-6.2.12/sentinel
# 日志文件位置
logfile "/opt/redis-6.2.12/sentinel/sentinel-26379.log"
# pid文件
pidfile /var/run/sentinel_26379.pid
# 是否后台运行
daemonize yes
# 端口
port 26379
# 监控主服务器master的名字：mymaster，IP：127.0.0.1，port：6379，最后的数字2表示当Sentinel集群中有2个Sentinel认为master存在故障不可用，则进行自动故障转移
sentinel monitor mymaster 127.0.0.1 6379 2
# master响应超时时间（毫秒），Sentinel会向master发送ping来确认master，如果在60秒内，ping不通master，则主观认为master不可用
sentinel down-after-milliseconds mymaster 60000
# 故障转移超时时间（毫秒），如果3分钟内没有完成故障转移操作，则视为转移失败
sentinel failover-timeout mymaster 180000
# 故障转移之后，进行新的主从复制，配置项指定了最多有多少个slave对新的master进行同步，那可以理解为1是串行复制，大于1是并行复制
sentinel parallel-syncs mymaster 1
# 指定mymaster主的密码（没有就不指定）
sentinel auth-pass mymaster 123456

2.配置哨兵2:sentinel-26380.conf

 # 配置文件目录
dir /opt/redis-6.2.12/sentinel
# 日志文件位置
logfile "/opt/redis-6.2.12/sentinel/sentinel-26380.log"
# pid文件
pidfile /var/run/sentinel_26380.pid
# 是否后台运行
daemonize yes
# 端口
port 26380
# 监控主服务器master的名字：mymaster，IP：127.0.0.1，port：6379，最后的数字2表示当Sentinel集群中有2个Sentinel认为master存在故障不可用，则进行自动故障转移
sentinel monitor mymaster 127.0.0.1 6379 2
# master响应超时时间（毫秒），Sentinel会向master发送ping来确认master，如果在60秒内，ping不通master，则主观认为master不可用
sentinel down-after-milliseconds mymaster 60000
# 故障转移超时时间（毫秒），如果3分钟内没有完成故障转移操作，则视为转移失败
sentinel failover-timeout mymaster 180000
# 故障转移之后，进行新的主从复制，配置项指定了最多有多少个slave对新的master进行同步，那可以理解为1是串行复制，大于1是并行复制
sentinel parallel-syncs mymaster 1
# 指定mymaster主的密码（没有就不指定）
sentinel auth-pass mymaster 123456
 

3.配置哨兵3:sentinel-26381.conf

dir /opt/redis-6.2.12/sentinel
# 日志文件位置
logfile "/opt/redis-6.2.12/sentinel/sentinel-26381.log"
# pid文件
pidfile /var/run/sentinel_26381.pid
# 是否后台运行
daemonize yes
# 端口
port 26381
# 监控主服务器master的名字：mymaster，IP：127.0.0.1，port：6379，最后的数字2表示当Sentinel集群中有2个Sentinel认为master存在故障不可用，则进行自动故障转移
sentinel monitor mymaster 127.0.0.1 6379 2
# master响应超时时间（毫秒），Sentinel会向master发送ping来确认master，如果在60秒内，ping不通master，则主观认为master不可用
sentinel down-after-milliseconds mymaster 60000
# 故障转移超时时间（毫秒），如果3分钟内没有完成故障转移操作，则视为转移失败
sentinel failover-timeout mymaster 180000
# 故障转移之后，进行新的主从复制，配置项指定了最多有多少个slave对新的master进行同步，那可以理解为1是串行复制，大于1是并行复制
sentinel parallel-syncs mymaster 1
# 指定mymaster主的密码（没有就不指定）
sentinel auth-pass mymaster 123456

4.分别启动这三个哨兵

#启动哨兵1(端口:26379)
/opt/redis-6.2.12/src/redis-sentinel /opt/redis-6.2.12/sentinel/sentinel-26379.conf

#启动哨兵2(端口:26380)
 /opt/redis-6.2.12/src/redis-sentinel /opt/redis-6.2.12/sentinel/sentinel-26380.conf
 
 #启动哨兵3(端口:26381)
  /opt/redis-6.2.12/src/redis-sentinel /opt/redis-6.2.12/sentinel/sentinel-26381.conf

5.分别查看3个sentinel的信息

#查看sentinel(端口:26379)的信息
redis-cli -p 26379
info sentinel
#查看sentinel(端口:26380)的信息
redis-cli -p 26380
info sentienl
#查看sentinel(端口:26381)的信息
redis-cli -p 26381
info sentinel

显示已经启动哨兵成功

查看哨兵信息

3.5、 验证故障自动转移

1.将主机（Master）挂了

shutdown

根据配置的哨兵信息down-after-milliseconds 的值 可知,等待2分钟故障就会自动转移

2.查看从机(端口:6380)的信息

3.查看从机(端口:6381)的信息

可以看出此时6381成为了主机 , 6380默认自动加入了新的主机

从哨兵信息中也可以看出此时主机已经变成6381了

4.验证新的主从复制

#在6381中向数据库中写入数
set p s

#在6380中可以读取主机(端口:6381)写的数据
get p

5.俯首称臣

当之前的主机(端口:6379)重启恢复后,自动变成从机(slave)

redis-server /opt/redis-6.2.12/master-slave/redis-6379.conf 
redis-cli -h 127.0.0.1 -p 6379

3.6、选举规则

哨兵在选举新的主机时，不是毫无头脑选择的，而是有一定的 选取规则，大概可以分为以下几个规则，优先级依次递减

1. 优先级数值越小越优先：redis.conf中配置 slave-priority 100(数值越小,优先级越高)
2. 位偏移量大的优先：谁从master中获取的数据最多,那么谁的偏移量就越大
3. runid越小越优先：每个从服务启动之后都会随机生成一个40位的runid

需要注意的是，哨兵节点在进行选举时会互相交换选票和信息，并进行多次投票和讨论，直至达成一致。此过程可能需要些时间，因此在选举期间，Redis集群可能会暂时不可用。

---

redis主从复制:结丹之境