吴中区两学一做网站,在线短链接生成网址,传奇网页游戏网,陕西建筑培训网Redis 哨兵#xff08;Sentinel#xff09;模式是一种高可用性解决方案#xff0c;用于监控和自动故障转移的集群系统。 在 Redis Sentinel 架构中#xff0c;哨兵是一组运行在特殊模式下的 Redis 进程#xff0c;它们可以监控一个或多个主从复制结构中的 Redis 主服务器以… Redis 哨兵Sentinel模式是一种高可用性解决方案用于监控和自动故障转移的集群系统。 在 Redis Sentinel 架构中哨兵是一组运行在特殊模式下的 Redis 进程它们可以监控一个或多个主从复制结构中的 Redis 主服务器以及其他从服务器的状态。 sentinel 哨兵模式已经被集成在 redis2.4 之后的版本中哨兵的核心功能是主节点的自动故障转移 特点与工作原理
以下是Redis哨兵模式的主要特点与工作原理
监控功能 哨兵会持续不断地通过心跳检测机制检查主节点和其他从节点的健康状态。如果主节点无法响应哨兵会根据预设的超时规则判断主节点是否宕机。自动故障转移 当哨兵确定主节点不可达后它会执行自动故障转移操作。选择一个从节点提升为主节点并负责更新其他从节点的配置让它们切换到新的主节点进行同步。协商机制 在多个哨兵组成的集群中哨兵间会相互通信并达成共识确保只有在足够数量的哨兵同意的情况下才会执行故障转移。这种多哨兵集群设计增强了系统的鲁棒性和正确性。通知机制 哨兵不仅负责故障转移还会通过发布订阅功能向客户端或者其他系统发送通知告知Redis主节点的状态变化。配置持久化 哨兵会将集群的当前配置信息持久化存储即使哨兵自身重启也能恢复其监控状态。
通过这种模式Redis能够实现无中心化的、高可用的服务部署当主节点出现故障时能够在无需人工干预的情况下快速恢复服务保证了Redis服务的稳定性和可靠性。
架构
哨兵节点哨兵系统由一个或多个哨兵节点组成哨兵节点是特殊的 Redis 节点不存储数据。
数据节点主节点和从节点都是数据节点 作用
哨兵模式在Redis中主要用于提供高可用性和故障恢复功能。具体作用如下
监控哨兵Sentinel进程会持续监控主服务器和从服务器的运行状态包括但不限于检查服务是否正常响应、判断主从复制是否正常进行等。自动故障检测与转移当主服务器发生故障如宕机或网络断开哨兵能及时发现并确定主服务器是否真的不可达。如果达到预设条件哨兵将自动执行故障转移操作选择一个从服务器升级为主服务器并通知其他从服务器开始复制新的主节点。配置更新哨兵不仅负责切换主从角色还会自动更新相关的配置信息确保整个集群中的所有节点都知道新的主服务器是谁从而维持集群的正确配置和数据同步。系统通知哨兵可以向管理员或者其他应用程序发送报警信息报告关于Redis服务器的各种状态变化通过发布订阅模式通知其他的从服务器修改配置文件让它们切换主机。
配置步骤 主要操作的文件是 /usr/local/bin/redis-sentinel ; 修改启动配置文件sentinel.conf 配置文件
复制和修改配置文件
到原 redis 解压目录下复制 sentinel.conf
[rootlocalhost 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
[rootlocalhost bin]# cd /opt/soft/redis-6.0.6/
[rootlocalhost 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
[rootlocalhost redis-6.0.6]# cp sentinel.conf /usr/local/bin ## 把哨兵配置文件 拷贝到 安装目录
cp: overwrite ‘/usr/local/bin/sentinel.conf’? y
[rootlocalhost redis-6.0.6]# #### 切换到安装目录 检查
[rootlocalhost redis-6.0.6]# cd /usr/local/bin/
[rootlocalhost 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
[rootlocalhost bin]# 监控主节点
编辑修改配置文件监控主节点 sentinel monitor mymaster 127.0.0.1 6379 1 ###注意监控主节点
修改 把 2 修改为 1。如果有一个哨兵节点认为主节点宕机了则开始选举机制。
启动哨兵进程
思路启动三个节点 并指定主从关系 然后启动哨兵节点来监控主节点
[rootlocalhost 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 version6.0.6, bits64, commit00000000, modified0, pid2417, just started
2417:C 05 Aug 2021 20:50:27.725 # Configuration loaded
[rootlocalhost bin]# ^C
[rootlocalhost bin]# redis-cli -p 6379#### 上面启动成功后下面查看自己当前角色
127.0.0.1:6379 info replication
# Replication
role:master
connected_slaves:2
slave0:ip127.0.0.1,port6381,stateonline,offset56,lag1
slave1:ip127.0.0.1,port6382,stateonline,offset56,lag0
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 端口并指定从节点
[rootlocalhost 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 并指定主从节点
[rootlocalhost 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 version6.0.6, bits64, commit00000000, modified0, pid2441, 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
[rootlocalhost 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 version6.0.6, bits64, commit00000000, modified0, pid2485, 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系统中确实存在一种高级的选举和故障转移机制 主观下线Subjectively Down, SDOWN单个Sentinel监控到主节点不可达时标记该节点为SDOWN。客观下线Objectively Down, ODOWN多个Sentinel通常是一个多数派集合都确认主节点不可达时将主节点状态改为ODOWN。Leader Sentinel选举当主节点被确定为ODOWN后Sentinel集群内部会进行一次Leader Sentinel的选举。这个选举通常是通过协商一致的方式达成其中一个Sentinel充当领导者并负责执行故障转移操作。新主节点选举Leader Sentinel会根据预定义的规则选择一个从节点作为新的主节点。这可能基于优先级、复制偏移量等因素决定选择最优的从节点晋升为主节点。故障转移与配置更新选定从节点升级为主节点后Leader Sentinel会通知其他Sentinel及从节点更新配置信息使得整个集群重新达到一致状态。 总之在Redis Sentinel模式下选举机制主要用于确保即使在主节点发生故障时也能快速地选出一个新的主节点以恢复服务的可用性并保证数据的一致性和完整性。 测试选举机制停止主节点后哨兵节点会输出日志监控到变化和启动选举机制
127.0.0.1:6379 shutdown
not connected quit2485: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节点以实现对主从复制集群的高可用性和故障转移功能。 优缺点
以下是多哨兵模式的优缺点
优点
高可用性通过部署多个Sentinel节点即使有个别Sentinel发生故障其他Sentinel也能继续监控和管理Redis集群确保系统的整体稳定性和可用性。自动故障检测与恢复当主服务器出现故障时多个Sentinel可以通过协商机制达成一致意见并选举出一个Leader Sentinel执行故障转移操作将新的主服务器推举出来从而实现快速恢复服务。容错能力增强由于有多个哨兵并行工作可以减少单点故障的风险增加对网络波动、机器宕机等异常情况的容忍度。分布式决策通过投票机制确定主服务器是否下线以及选择哪个从服务器升级为主服务器避免了单一节点决策可能带来的误判或延迟。
缺点
复杂性增加配置和维护多哨兵架构会比单个哨兵更为复杂需要考虑哨兵之间的通信、配置一致性等问题。资源消耗每个哨兵都是一个独立运行的进程因此需要额外的计算资源和网络带宽来支持其运行。潜在的问题点增多随着哨兵数量的增加可能出现更多潜在的故障点例如如果所有哨兵同时无法正确监测到主节点状态可能会导致集群不能正常进行故障切换。一致性问题虽然Sentinel之间通过协议保证了一致性但在实际部署中如若配置不当或网络分区等因素仍有可能引发一致性问题比如脑裂现象即不同哨兵群组认为不同的节点是主服务器。
总结来说多哨兵模式增强了Redis集群的健壮性和可靠性但也相应增加了管理和运维的复杂度因此在设计和部署时需要权衡这些因素确保系统的稳健运行。
