Redis哨兵模式
3、哨兵模式
3.1、背景
虽然主从复制可以解决主机的压力，确保数据的一致性，但是当主机宕机后，从机不会主动变成主机，重新再剩余的机器中组成主从复制，如果想重新使用主从复制机制就需要人为的将某台从机（slave）变成主机，然后将其他从机再加入新的主机中，这样做比较麻烦，而且可靠性比较低，因此出现了哨兵。
3.2、哨兵模式
哨兵：简言之就是想卫士一样，时时刻刻监控着主机，当主机宕机后，它会根据配置的策略在剩余的从机中自动选择一个当做主机，其余从机主动加入新选举的主机中。其实就是反客为主的自动版。
在哨兵模式中一共有三个角色：
- 主节点（master）：负责处理客户端的读写请求。
- 从节点（slave）：通过复制主节点的数据来提供读服务，并在主节点发生故障时可以升级为主节点。
- 哨兵节点（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、选举规则
哨兵在选举新的主机时，不是毫无头脑选择的，而是有一定的 选取规则，大概可以分为以下几个规则，优先级依次递减
- 优先级数值越小越优先：redis.conf中配置 slave-priority 100(数值越小,优先级越高)
- 位偏移量大的优先：谁从master中获取的数据最多,那么谁的偏移量就越大
- runid越小越优先：每个从服务启动之后都会随机生成一个40位的runid
需要注意的是，哨兵节点在进行选举时会互相交换选票和信息，并进行多次投票和讨论，直至达成一致。此过程可能需要些时间，因此在选举期间，Redis集群可能会暂时不可用。
redis主从复制:结丹之境