哨兵进程不自动修改sentinel.conf，所谓“自动剔除节点”实为运行时状态同步与配置重载；sentinel reset才是手动剔除离线节点的唯一有效操作。
哨兵进程本身不会自动修改 sentinel.conf 文件内容，所谓“自动剔除节点”其实是通过运行时状态同步和配置重载实现的，不是靠改配置文件。
sentinel reset 命令才是实际剔除离线节点的操作入口
当某个 Redis 主从节点永久下线（比如机器报废、IP 变更、端口停用），哨兵仍会持续尝试连接它，导致日志刷屏、主观下线误报、甚至干扰故障转移判断。此时必须手动触发清理：
-
redis-cli -p 26379 sentinel reset mymaster：重置对mymaster的所有监控状态，清空已知的从节点列表（包括已掉线但未被自动摘除的） - 该命令需在每个哨兵节点上分别执行，不能只跑一次
- 执行后哨兵会重新向当前主节点发
INFO replication拉取最新从节点列表，相当于“刷新认知” - 如果主节点本身也挂了，
reset会失败，得先恢复主节点或人工指定新主再操作
为什么 sentinel.conf 不会被自动更新
sentinel.conf 是启动配置的“快照”，仅用于初始化加载；哨兵运行时的所有拓扑信息（如当前从节点 IP/端口、主观下线标记、quorum 投票结果）都存在内存中，并通过 Gossip 协议在哨兵间同步。它不反向写回配置文件，原因很实在：
- 频繁写磁盘影响性能，尤其在频繁网络抖动场景下可能每分钟触发多次变更
- 多个哨兵同时写同一份文件会引发冲突，而哨兵设计上不带分布式锁机制
- 配置项如
sentinel monitor定义的是监控目标，不是当前存活节点列表 —— 后者是运行时动态发现的 - 真要持久化拓扑变更，得靠运维脚本配合
SENTINEL slaves mymaster输出 + 定期备份生成新配置
常见误操作：以为重启哨兵就能“自动同步”节点列表
重启单个哨兵进程只会让它按 sentinel.conf 里的 sentinel monitor 行去连主节点，然后再次拉取 INFO replication。但它不会主动“扫描”其他哨兵的当前节点视图 —— 这个同步依赖 Gossip，且需要至少一个正常哨兵先拿到最新拓扑再广播出去。所以：
- 如果整个哨兵集群刚启动，而主节点还没起来，所有哨兵都会卡在“无法获取从节点列表”状态，不会自动跳过
- 若只有 1 个哨兵存活，它无法达成
quorum判定客观下线，也就不会触发任何故障转移逻辑，更不会“聪明地”删掉旧从节点 - 用
sentinel set动态修改参数（如down-after-milliseconds）是生效的，但不改变节点发现行为
真正容易被忽略的是：哨兵对“掉线节点”的容忍窗口，取决于 down-after-milliseconds 和 quorum 的组合，而不是配置文件里有没有那行 sentinel monitor —— 那行只是起点，不是终点。
