前面我们了解了Redis主从复制主从架构解决了两个核心问题数据热备份、读写分离有效提升了查询并发能力和数据安全性。但是纯主从架构没有自动故障转移能力。一旦主节点宕机从节点正常运行但不会自动升级为主节点整个集群写服务就会瘫痪必须人工登录服务器手动更换运维成本高、故障时间不可控。为了解决这种问题Redis 推出了哨兵机制。哨兵模式基于主从复制额外增加了节点监控、自动故障发现、自动主从切换、客户端通知的功能。二、哨兵模式核心概念与架构2.1 什么是哨兵Sentinel哨兵是 Redis 的独立监控进程不存储业务数据只负责监控主从节点状态、处理故障转移。哨兵本身也是集群部署保证自身高可用避免单点故障。2.2 标准生产架构1主2从3哨兵标准部署1 个 Master写节点2 个 Slave读节点、备份节点3 个 Sentinel监控、投票、故障转移为什么哨兵必须部署奇数个因为故障转移需要半数以上投票奇数可以避免平票、保证选举结果唯一。2.3 哨兵四大核心功能1. 监控哨兵持续心跳检测 Master、Slave 节点实时监听节点在线状态、运行状态。2. 消息通知节点异常、故障切换完成后哨兵主动通知客户端新的主节点地址业务无需改配置。3. 自动故障转移主节点宕机后哨兵自动完成重新选出主节点、从库升级成主节点、修改其他从库指向、原主库重启后变为从库。4. 配置提供者客户端连接哨兵集群获取当前集群真实主节点地址哨兵集群内部维护着集群的最新状态返回当前存活的真正主节点的IP和端口号不需要硬编码 代码中不用写死主节点地址只是主从复制则只能写死Redis 地址。三、哨兵核心工作原理重点3.1 两种下线状态1. 主观下线单个哨兵节点 ping 不通主节点超过超时时间单方面判定节点下线。流程每个哨兵节点会隔1s向Redis主从节点发送PING心跳检测如果超过配置的超时时间哨兵节点一直收不到PONG回复当前该哨兵节点就会认为该节点宕机。仅仅是单个哨兵认为挂了不触发故障转移。2. 客观下线当超过半数哨兵判定主节点主观下线才会标记为客观下线。只有客观下线才会触发自动故障转移。3.2 故障转移完整流程心跳检测失败Master 宕机哨兵检测心跳超时多哨兵投票确认半数以上哨兵确认宕机标记客观下线哨兵领导者选举首先在3个哨兵中选出一个负责人专门执行切换工作最优从节点选举选新主按照规则挑选最健康的从节点升级为主节点升级新主从节点执行slaveof no one变成可写主节点其他从节点重新挂载剩余从库自动跟随新主节点原主节点降级旧的主节点重启后自动变成从节点推送新配置给客户端业务自动切换新主节点业务无感客户端连接哨兵集群哨兵集群维护着集群的最新状态返回当前存活的主节点的IP和端口号所以业务无感3.3 新主节点选举规则面试高频哨兵不会随机选从库有严格优先级1优先选择优先级高replica-priority 数值越小优先级越高可配置如果设置为0永远不可能被升级成主节点,2优先级一致选择数据同步偏移量最大最大可能的保证数据的完整性。3依然一致选择运行ID最小的节点redis每次启动实例都会生成一个40位随机的runId对字符串你做字典序比较runId更小生出属于兜底逻辑一般用不到四、手把手搭建 Redis 哨兵模式我们这里使用docker来进行部署。docker利用linux内核技术隔离出独立的运行环境容器每个容器内部只能跑一个redis进程每个容器有自己独立的IP端口号网卡独立文件系统独立进程可以互相访问。这里使用两个yml文件一个yml文件创建3个数据节点用来存数据另外一个yml文件创建三个哨兵节点。首先创建各自的目录再在各自的目录下面创建docker-compose.yml文件后续直接docker-compose up -d命令启动三个容器。数据节点配置信息如下启动后会自动挂载不用再单独写配置文件启动三个数据节点一个命令直接启动三个数据节点接下来配置哨兵节点的docker-compose.yml文件这里面就具体配置的作用如下主要负责四件事拉取redis镜像启动哨兵程序把本地三个独立的哨兵配置文件挂载进容器配置文件具体写在外部映射宿主机的不同端口避免三个哨兵端口冲突。加入同一个docker网络让哨兵能解析redis-master容器名docker-compose文件启动时会自动生成一个网络文件名格式为 文件夹名_default不同的yml文件生成完全隔离的不同网桥一个网桥对应一套DNS解析服务容器名类比成内网域名networks配置就是为了加入到数据主节点所在的网络方便进行网络通信接下来给每个哨兵节点配置配置文件以及配置项含义五、哨兵模式优缺点6.1 优点1实现自动故障转移解决主从架构无法故障转移的问题2高可用哨兵集群无单点故障单个哨兵节点宕机不影响工作3支持读写分离读压力分摊到从库4运维简单、资源占用低哨兵进程极轻量5客户端自动感知切换无需改配置、无需重启服务6.2 缺点生产核心短板1不支持数据分片所有节点存储全量数据无法扩容内存容量2容量受单节点内存限制数据量大后无法横向扩展3依然存在主从延迟异步复制部分场景可能会导致短暂数据不一致六、生产高频踩坑与解决方案坑点1哨兵部署偶数节点偶数节点容易出现平票无法触发故障转移生产必须3哨兵奇数部署。坑点2防火墙/端口未开放哨兵之间需要互通、哨兵与所有主从互通端口不通会导致误判宕机。坑点3主从延迟导致选主数据丢失网络抖动时部分从库数据旧优先保证偏移量最新的节点升级减少丢失风险。坑点4客户端直连Redis节点故障切换后IP变化客户端必须连接哨兵动态获取主节点地址。七、生产最佳实践1生产固定架构1主2从3哨兵2哨兵节点独立部署不与业务Redis抢资源3合理配置心跳超时时间避免网络抖动误切换4读写分离写主库、读从库减轻主库压力5开启RDBAOF双持久化最大程度保证数据安全6监控哨兵切换日志、主从偏移量、节点上下线记录八、总结哨兵模式是主从架构的增强版高可用方案它解决了主从架构不能自动故障转移的致命问题。但哨兵不支持数据分片扩容无法应对海量数据的场景。如果业务数据量大、QPS高需要进一步扩展为 Redis Cluster 分片集群。
)
