哨兵进程RSS比used_memory高3倍以上说明是哨兵自身内存泄漏，需用ps命令确认，执行SENTINEL RESET *后等待2–3个quorum周期再shutdown，重启后验证known-sentinel数量与角色一致性。

哨兵进程内存持续上涨，redis-sentinel 进程 RSS 比 used_memory 高 3 倍以上

这基本不是 Redis 数据内存问题，而是哨兵自身逻辑导致的内存泄漏——比如长期未清理的客户端连接、订阅通道堆积、或旧版哨兵在主从切换频繁时未释放监控上下文。不要用 redis-cli 查 INFO memory，哨兵不暴露该命令；得直接看进程内存：ps -o pid,vsz,rss,comm -C redis-sentinel。如果 rss 持续增长且不回落，配合 top -p 观察，基本可锁定为哨兵进程泄漏。

重启前必须绕过哨兵集群自检，否则触发误判下线

哨兵不是普通服务，它依赖其他哨兵节点的投票共识。直接 kill -9 或未协调重启，会导致剩余哨兵认为“该哨兵已失联”，可能提前发起故障转移（尤其当主节点本身负载偏高时）。正确做法是：先让目标哨兵主动退出选举，再停进程：

• 向该哨兵发送 SENTINEL RESET * 命令（用 redis-cli -p SENTINEL RESET *），清空其本地对所有主节点的监控状态
• 等待 2–3 个 sentinel monitor-quorum 周期（默认 30 秒），确保它不再参与投票
• 执行 redis-cli -p shutdown ——这是安全退出，会断开所有 pub/sub 连接并释放订阅缓冲区
• 确认进程消失：! pgrep -f "redis-sentinel.*"

重启后必须验证 sentinel known-sentinel 数量与角色一致性

哨兵重启后不会自动重新发现其他哨兵，它只认自己 sentinel.conf 里写死的 sentinel monitor 和 sentinel known-sentinel 条目。常见坑是：配置文件没更新，或 sentinel.conf 被覆盖重写后丢失了其他哨兵地址。

Sentinal Redis

监控Redis服务器健康状况、内存、性能及BullMQ队列。检查队列深度、失败任务，分析慢查询并诊断问题。

下载

• 启动后立即检查：redis-cli -p SENTINEL SENTINELS ，输出应包含全部其他哨兵节点（不含自己），且 flags 字段含 sentinel 标识
• 若数量不对，手动补加：redis-cli -p SENTINEL ADD-SENTINEL
• 重点核对 redis-cli -p SENTINEL MASTER 中的 num-other-sentinels 是否等于集群总数减 1

长期规避需升级 + 关闭冗余功能

Redis 6.2 之前版本的哨兵在高频率主从切换（如网络抖动频繁）下存在已知内存泄漏路径，官方在 6.2.6+ 修复了 sentinelHandleSubjectiveVote 中的引用计数泄漏。别信“只是临时波动”——只要 rss 单日增长超 200MB，就该行动：

• 强制升级到 Redis 7.0+（当前稳定版），哨兵模块已重写为事件驱动，内存模型更可控
• 关闭非必要功能：在 sentinel.conf 中设 sentinel resolve-hostnames no（避免 DNS 缓存泄漏）、sentinel announce-ip 显式指定内网 IP（防容器/云环境解析异常）
• 禁止在哨兵节点上混跑业务或监控采集 agent，哨兵对 CPU 时间片敏感，第三方轮询会加剧调度延迟和内存碎片

真正麻烦的从来不是重启动作本身，而是哨兵重启后无法及时重建完整的 known-sentinel 视图——这个状态不一致窗口期，哪怕只有 15 秒，也可能让一次本不该发生的 failover 被触发。