首页
技术小册
AIGC
面试刷题
技术文章
MAGENTO
云计算
视频课程
源码下载
PDF书籍
「涨薪秘籍」
登录
注册
01 | 基本架构:一个键值数据库包含什么?
02 | 数据结构:快速的Redis有哪些慢操作?
03 | 高性能IO模型:为什么单线程Redis能那么快?
04 | AOF日志:宕机了,Redis如何避免数据丢失?
05 | 内存快照:宕机后,Redis如何实现快速恢复?
06 | 数据同步:主从库如何实现数据一致?
07 | 哨兵机制:主库挂了,如何不间断服务?
08 | 哨兵集群:哨兵挂了,主从库还能切换吗?
09 | 切片集群:数据增多了,是该加内存还是加实例?
10 | 第1~9讲课后思考题答案及常见问题答疑
11 | “万金油”的String,为什么不好用了?
12 | 有一亿个keys要统计,应该用哪种集合?
13 | GEO是什么?还可以定义新的数据类型吗?
14 | 如何在Redis中保存时间序列数据?
15 | 消息队列的考验:Redis有哪些解决方案?
16 | 异步机制:如何避免单线程模型的阻塞?
17 | 为什么CPU结构也会影响Redis的性能?
18 | 波动的响应延迟:如何应对变慢的Redis?
20 | 删除数据后,为什么内存占用率还是很高?
21 | 缓冲区:一个可能引发“惨案”的地方
22 | 第11~21讲课后思考题答案及常见问题答疑
23 | 旁路缓存:Redis是如何工作的?
24 | 替换策略:缓存满了怎么办?
25 | 缓存异常(上):如何解决缓存和数据库的数据不一致问题?
26 | 缓存异常(下):如何解决缓存雪崩、击穿、穿透难题?
27 | 缓存被污染了,该怎么办?
28 | Pika:如何基于SSD实现大容量Redis?
29 | 无锁的原子操作:Redis如何应对并发访问?
30 | 如何使用Redis实现分布式锁?
31 | 事务机制:Redis能实现ACID属性吗?
32 | Redis主从同步与故障切换,有哪些坑?
33 | 脑裂:一次奇怪的数据丢失
34 | 第23~33讲课后思考题答案及常见问题答疑
35 | Codis VS Redis Cluster:我该选择哪一个集群方案?
36 | Redis支撑秒杀场景的关键技术和实践都有哪些?
37 | 数据分布优化:如何应对数据倾斜?
38 | 通信开销:限制Redis Cluster规模的关键因素
39 | Redis 6.0的新特性:多线程、客户端缓存与安全
40 | Redis的下一步:基于NVM内存的实践
当前位置:
首页>>
技术小册>>
Redis核心技术与实战
小册名称:Redis核心技术与实战
### 08 | 哨兵集群:哨兵挂了,主从库还能切换吗? 在Redis的高可用架构中,哨兵(Sentinel)系统扮演着至关重要的角色,它负责监控Redis主从集群的健康状态,并在主节点出现故障时自动进行故障转移,确保服务的连续性和数据的一致性。然而,当哨兵系统本身遭遇故障时,读者自然会关心:哨兵挂了,Redis的主从库是否还能正常进行主从切换?本章将深入解析这一问题,探讨哨兵集群的容错机制、哨兵故障对Redis集群的影响,以及如何在哨兵故障时确保Redis集群的稳定运行。 #### 一、哨兵集群的基本概念与工作原理 在深入探讨之前,我们先简要回顾哨兵集群的基本概念和工作原理。哨兵是一个运行在特殊模式下的Redis服务器,它不接受任何客户端命令,而是专注于执行以下任务: 1. **监控**:哨兵会持续地监控主节点和从节点的健康状况,包括实例是否在线、主从复制是否正常运行等。 2. **自动故障转移**:当检测到主节点故障时,哨兵会执行一系列选举和切换操作,将从节点中的一个提升为新的主节点,并通知其他从节点和客户端更新配置。 3. **配置提供者**:哨兵会作为客户端连接信息的提供者,包括新主节点的地址和端口,帮助客户端实现无缝的故障恢复。 哨兵通常部署为多个实例组成的集群,以增强系统的容错性和可靠性。通过哨兵之间的相互监控和通信,确保即使部分哨兵实例故障,剩余的哨兵也能继续完成监控和故障转移的任务。 #### 二、哨兵挂了,对Redis集群的影响 当哨兵集群中的部分哨兵实例出现故障时,其对Redis集群的影响主要取决于以下几点: 1. **剩余哨兵数量**:如果剩余的哨兵数量仍然满足哨兵集群的法定人数(quorum)要求,那么哨兵集群仍然能够正常工作,继续执行监控和故障转移任务。法定人数是哨兵集群中参与决策的最小哨兵数量,通常设置为哨兵总数的一半加一。 2. **主从节点状态**:只要Redis的主从节点本身运行正常,且至少有一个哨兵能够正常工作,那么Redis集群的基本功能不会受到影响。哨兵故障主要影响的是故障转移的自动化过程和客户端连接信息的更新。 3. **客户端行为**:对于依赖于哨兵提供连接信息的客户端,如果所有哨兵都不可用,客户端将无法自动获取最新的主节点信息,可能导致连接失败或数据写入旧的主节点(如果旧主节点已恢复为从节点)。然而,如果客户端配置了多个哨兵地址,并且至少有一个哨兵可用,那么客户端通常能够顺利连接到新的主节点。 #### 三、哨兵集群的容错机制 为了应对哨兵故障,哨兵集群设计了一系列容错机制: 1. **哨兵间的相互监控**:哨兵之间会相互监控彼此的健康状态,如果一个哨兵发现另一个哨兵超时未响应,它会认为该哨兵已经故障,并从内部列表中移除。这有助于哨兵集群快速识别并排除故障哨兵,确保决策的正确性。 2. **法定人数机制**:如前所述,法定人数机制确保了只有足够数量的哨兵参与决策时,才会触发故障转移。这有效防止了因个别哨兵故障导致的误判和不必要的故障转移。 3. **持久化配置**:哨兵的配置信息(如监控的Redis节点地址、密码、法定人数等)可以持久化到磁盘文件中,即使哨兵重启也能恢复之前的配置,保证系统的连续性和一致性。 4. **客户端的哨兵列表**:建议客户端配置多个哨兵地址,而不是仅仅依赖一个哨兵。这样,即使某个哨兵故障,客户端也能通过其他哨兵获取到最新的主节点信息,保持与Redis集群的连接。 #### 四、哨兵故障时的应对策略 当遇到哨兵故障时,可以采取以下策略来确保Redis集群的稳定运行: 1. **及时恢复哨兵实例**:对于故障的哨兵实例,应尽快查明原因并恢复其正常运行。这可以通过重启哨兵进程、修复网络问题或调整系统资源等方式实现。 2. **手动触发故障转移**:如果剩余的哨兵数量不足以触发自动故障转移,或者出于某种原因需要立即切换主节点,管理员可以手动触发故障转移。这通常涉及到使用哨兵的`SENTINEL failover`命令来强制执行主从切换。 3. **优化哨兵集群配置**:定期检查并优化哨兵集群的配置,如调整法定人数、增加哨兵实例的数量、优化哨兵间的通信参数等,以提高哨兵集群的容错能力和稳定性。 4. **增强客户端的容错能力**:在客户端层面,可以通过编写重试逻辑、使用连接池、配置多个哨兵地址等方式来增强对哨兵故障的容忍度,确保在哨兵故障时客户端仍能保持与Redis集群的连接。 #### 五、结论 综上所述,哨兵挂了并不意味着Redis的主从库就无法进行主从切换。通过哨兵集群的容错机制、合理的配置和及时的故障应对策略,我们可以有效地降低哨兵故障对Redis集群的影响,确保Redis服务的高可用性和数据的可靠性。因此,在设计和部署Redis高可用架构时,应充分考虑哨兵集群的容错能力和可靠性要求,以应对各种潜在的故障场景。
上一篇:
07 | 哨兵机制:主库挂了,如何不间断服务?
下一篇:
09 | 切片集群:数据增多了,是该加内存还是加实例?
该分类下的相关小册推荐:
Redis的Lua脚本编程
Redis面试指南
Redis零基础到实战