哨兵进程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 <pid></pid> 观察，基本可锁定为哨兵进程泄漏。
重启前必须绕过哨兵集群自检，否则触发误判下线
哨兵不是普通服务，它依赖其他哨兵节点的投票共识。直接 kill -9 或未协调重启，会导致剩余哨兵认为“该哨兵已失联”，可能提前发起故障转移（尤其当主节点本身负载偏高时）。正确做法是：先让目标哨兵主动退出选举，再停进程：
- 向该哨兵发送
SENTINEL RESET *命令（用redis-cli -p <sentinel-port> SENTINEL RESET *</sentinel-port>），清空其本地对所有主节点的监控状态 - 等待 2–3 个
sentinel monitor-quorum周期（默认 30 秒），确保它不再参与投票 - 执行
redis-cli -p <sentinel-port> shutdown</sentinel-port>——这是安全退出，会断开所有 pub/sub 连接并释放订阅缓冲区 - 确认进程消失：
! pgrep -f "redis-sentinel.*<port>"</port>
重启后必须验证 sentinel known-sentinel 数量与角色一致性
哨兵重启后不会自动重新发现其他哨兵，它只认自己 sentinel.conf 里写死的 sentinel monitor 和 sentinel known-sentinel 条目。常见坑是：配置文件没更新，或 sentinel.conf 被覆盖重写后丢失了其他哨兵地址。
- 启动后立即检查：
redis-cli -p <port> SENTINEL SENTINELS <master-name></master-name></port>，输出应包含全部其他哨兵节点（不含自己），且flags字段含sentinel标识 - 若数量不对，手动补加：
redis-cli -p <port> SENTINEL ADD-SENTINEL <master-name><ip><port></port></ip></master-name></port> - 重点核对
redis-cli -p <port> SENTINEL MASTER <master-name></master-name></port>中的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 被触发。
