Redis 之六：Redis 的哨兵模式（Sentinel）

Redis 哨兵（Sentinel）模式是一种高可用性解决方案，用于监控和自动故障转移的集群系统。

在 Redis Sentinel 架构中，哨兵是一组运行在特殊模式下的 Redis 进程，它们可以监控一个或多个主从复制结构中的 Redis 主服务器以及其他从服务器的状态。

sentinel 哨兵模式已经被集成在 redis2.4 之后的版本中，哨兵的核心功能是主节点的自动故障转移

特点与工作原理

以下是Redis哨兵模式的主要特点与工作原理：

1. 监控功能：
   • 哨兵会持续不断地通过心跳检测机制检查主节点和其他从节点的健康状态。
   • 如果主节点无法响应，哨兵会根据预设的超时规则判断主节点是否宕机。
2. 自动故障转移：
   • 当哨兵确定主节点不可达后，它会执行自动故障转移操作。
   • 选择一个从节点提升为主节点，并负责更新其他从节点的配置，让它们切换到新的主节点进行同步。
3. 协商机制：
   • 在多个哨兵组成的集群中，哨兵间会相互通信并达成共识，确保只有在足够数量的哨兵同意的情况下才会执行故障转移。
   • 这种多哨兵集群设计增强了系统的鲁棒性和正确性。
4. 通知机制：
   • 哨兵不仅负责故障转移，还会通过发布订阅功能向客户端或者其他系统发送通知，告知Redis主节点的状态变化。
5. 配置持久化：
   • 哨兵会将集群的当前配置信息持久化存储，即使哨兵自身重启也能恢复其监控状态。

通过这种模式，Redis能够实现无中心化的、高可用的服务部署，当主节点出现故障时，能够在无需人工干预的情况下快速恢复服务，保证了Redis服务的稳定性和可靠性。

架构

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 Redis 节点，不存储数据。

数据节点：主节点和从节点都是数据节点

作用

哨兵模式在Redis中主要用于提供高可用性和故障恢复功能。具体作用如下：

1. 监控：哨兵（Sentinel）进程会持续监控主服务器和从服务器的运行状态，包括但不限于检查服务是否正常响应、判断主从复制是否正常进行等。
2. 自动故障检测与转移：当主服务器发生故障（如宕机或网络断开），哨兵能及时发现并确定主服务器是否真的不可达。如果达到预设条件，哨兵将自动执行故障转移操作，选择一个从服务器升级为主服务器，并通知其他从服务器开始复制新的主节点。
3. 配置更新：哨兵不仅负责切换主从角色，还会自动更新相关的配置信息，确保整个集群中的所有节点都知道新的主服务器是谁，从而维持集群的正确配置和数据同步。
4. 系统通知：哨兵可以向管理员或者其他应用程序发送报警信息，报告关于Redis服务器的各种状态变化，通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

配置步骤

主要操作的文件是 /usr/local/bin/redis-sentinel ;

修改启动配置文件：sentinel.conf

配置文件

复制和修改配置文件

到原 redis 解压目录下复制 sentinel.conf

[root@localhost bin]# ls
dump.rdb  redis81.conf  redis82.conf  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis.conf  redis-sentinel  redis-server  sentinel.conf
[root@localhost bin]# cd /opt/soft/redis-6.0.6/
[root@localhost redis-6.0.6]# ls
00-RELEASENOTES  CONTRIBUTING  deps     Makefile   README.md   runtest          runtest-moduleapi  sentinel.conf  tests   utils
BUGS             COPYING       INSTALL  MANIFESTO  redis.conf  runtest-cluster  runtest-sentinel   src            TLS.md
[root@localhost redis-6.0.6]# cp sentinel.conf /usr/local/bin     ## 把哨兵配置文件 拷贝到 安装目录
cp: overwrite ‘/usr/local/bin/sentinel.conf’? y   
[root@localhost redis-6.0.6]# #### 切换到安装目录 检查
[root@localhost redis-6.0.6]# cd /usr/local/bin/
[root@localhost bin]# ls
dump.rdb  redis81.conf  redis82.conf  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis.conf  redis-sentinel  redis-server  sentinel.conf
[root@localhost bin]# 

监控主节点

编辑修改配置文件，监控主节点

sentinel monitor mymaster 127.0.0.1 6379 1 ###注意监控主节点

修改 把 2 修改为 1。如果有一个哨兵节点认为主节点宕机了，则开始选举机制。

启动哨兵进程

思路：启动三个节点 > 并指定主从关系 > 然后启动哨兵节点来监控主节点

[root@localhost bin]# redis-server redis.conf 
2417:C 05 Aug 2021 20:50:27.725 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2417:C 05 Aug 2021 20:50:27.725 # Redis version=6.0.6, bits=64, commit=00000000, modified=0, pid=2417, just started
2417:C 05 Aug 2021 20:50:27.725 # Configuration loaded
[root@localhost bin]# ^C
[root@localhost bin]# redis-cli -p 6379#### 上面启动成功后，下面查看自己当前角色
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=56,lag=1
slave1:ip=127.0.0.1,port=6382,state=online,offset=56,lag=0
master_replid:2a3410fe212ea06a10413e6c93b59b9746a55d7a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:56
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:56

指定主从节点

启动 6381 端口和6382 端口，并指定从节点：

[root@localhost bin]# redis-cli -p 6381
127.0.0.1:6381> slaveof 127.0.0.1 6379    ####指定主从节点####
OK
127.0.0.1:6381> info replication
# Replication
role:slave                                #####从节点#####
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:42
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:2a3410fe212ea06a10413e6c93b59b9746a55d7a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:42

启动6382 并指定主从节点

[root@localhost bin]# redis-server redis82.conf 
2441:C 05 Aug 2021 20:51:19.197 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2441:C 05 Aug 2021 20:51:19.197 # Redis version=6.0.6, bits=64, commit=00000000, modified=0, pid=2441, just started
2441:C 05 Aug 2021 20:51:19.197 # Configuration loaded
127.0.0.1:6382> slaveof 127.0.0.1 6379
OK
127.0.0.1:6382> info replication

启动哨兵节点

redis-sentinel sentinel.conf

[root@localhost bin]# redis-sentinel sentinel.conf 
2485:X 05 Aug 2021 20:54:16.497 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2485:X 05 Aug 2021 20:54:16.497 # Redis version=6.0.6, bits=64, commit=00000000, modified=0, pid=2485, just started
2485:X 05 Aug 2021 20:54:16.497 # Configuration loaded
2485:X 05 Aug 2021 20:54:16.497 * Increased maximum number of open files to 10032 (it was originally set to 1024).

选举机制

Redis Sentinel（哨兵）模式下的选举

在Redis Sentinel系统中，确实存在一种高级的选举和故障转移机制：

1. 主观下线（Subjectively Down, SDOWN）：单个Sentinel监控到主节点不可达时，标记该节点为SDOWN。
2. 客观下线（Objectively Down, ODOWN）：多个Sentinel（通常是一个多数派集合）都确认主节点不可达时，将主节点状态改为ODOWN。
3. Leader Sentinel选举：当主节点被确定为ODOWN后，Sentinel集群内部会进行一次Leader Sentinel的选举。这个选举通常是通过协商一致的方式达成，其中一个Sentinel充当领导者并负责执行故障转移操作。
4. 新主节点选举：Leader Sentinel会根据预定义的规则选择一个从节点作为新的主节点。这可能基于优先级、复制偏移量等因素决定，选择最优的从节点晋升为主节点。
5. 故障转移与配置更新：选定从节点升级为主节点后，Leader Sentinel会通知其他Sentinel及从节点更新配置信息，使得整个集群重新达到一致状态。

总之，在Redis Sentinel模式下，选举机制主要用于确保即使在主节点发生故障时，也能快速地选出一个新的主节点以恢复服务的可用性，并保证数据的一致性和完整性。

测试选举机制：停止主节点后，哨兵节点会输出日志，监控到变化和启动选举机制

127.0.0.1:6379> shutdown
not connected> quit

2485:X 05 Aug 2021 20:55:34.787 # +sdown master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.787 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
2485:X 05 Aug 2021 20:55:34.787 # +new-epoch 1
2485:X 05 Aug 2021 20:55:34.787 # +try-failover master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.788 # +vote-for-leader fe3f7dda47b7a9ca63194aeaeb31660c30a7316a 1
2485:X 05 Aug 2021 20:55:34.788 # +elected-leader master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.788 # +failover-state-select-slave master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.860 # +selected-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.860 * +failover-state-send-slaveof-noone slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.919 * +failover-state-wait-promotion slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:35.924 # +promoted-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:35.924 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:35.999 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:36.992 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:36.992 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:37.093 # +failover-end master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:37.093 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6382
2485:X 05 Aug 2021 20:55:37.093 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6382
2485:X 05 Aug 2021 20:55:37.093 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6382
2485:X 05 Aug 2021 20:56:07.186 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6382

多哨兵模式

然而一个哨兵进程对 Redis 服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。 各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

多哨兵模式通常指的是在Redis Sentinel（哨兵）系统中部署多个Sentinel节点，以实现对主从复制集群的高可用性和故障转移功能。

优缺点

以下是多哨兵模式的优缺点：

优点：

1. 高可用性：通过部署多个Sentinel节点，即使有个别Sentinel发生故障，其他Sentinel也能继续监控和管理Redis集群，确保系统的整体稳定性和可用性。
2. 自动故障检测与恢复：当主服务器出现故障时，多个Sentinel可以通过协商机制达成一致意见，并选举出一个Leader Sentinel执行故障转移操作，将新的主服务器推举出来，从而实现快速恢复服务。
3. 容错能力增强：由于有多个哨兵并行工作，可以减少单点故障的风险，增加对网络波动、机器宕机等异常情况的容忍度。
4. 分布式决策：通过投票机制确定主服务器是否下线以及选择哪个从服务器升级为主服务器，避免了单一节点决策可能带来的误判或延迟。

缺点：

1. 复杂性增加：配置和维护多哨兵架构会比单个哨兵更为复杂，需要考虑哨兵之间的通信、配置一致性等问题。
2. 资源消耗：每个哨兵都是一个独立运行的进程，因此需要额外的计算资源和网络带宽来支持其运行。
3. 潜在的问题点增多：随着哨兵数量的增加，可能出现更多潜在的故障点，例如如果所有哨兵同时无法正确监测到主节点状态，可能会导致集群不能正常进行故障切换。
4. 一致性问题：虽然Sentinel之间通过协议保证了一致性，但在实际部署中，如若配置不当或网络分区等因素，仍有可能引发一致性问题，比如脑裂现象，即不同哨兵群组认为不同的节点是主服务器。

总结来说，多哨兵模式增强了Redis集群的健壮性和可靠性，但也相应增加了管理和运维的复杂度，因此在设计和部署时需要权衡这些因素，确保系统的稳健运行。