直接停掉从节点进程会丢数据或触发误判；需先禁用复制连接、执行SLAVEOF NO ONE、通知哨兵重置并确认移除，再安全shutdown，避免kill-9。
直接停掉从节点进程会丢数据或触发误判
Redis 5.0 的从节点（replica）本身不参与写操作，但若在主从同步中被强制 kill 或未通知哨兵就下线，会导致两个风险：一是主节点的 repl_backlog 缓冲区可能被后续 replica 消费失败；二是哨兵（Sentinel）检测到该 replica 连接断开后，若配置不当，可能误判为主节点异常（尤其当 quorum 设置过低、且多个 replica 同时抖动时）。所以“优雅下线”核心是：让主节点和哨兵都明确知道这是计划内行为，而非故障。
先禁用 replica 的自动重连与同步行为
在目标从节点上执行以下命令，避免它在下线过程中反复尝试连接已计划下线的主节点（或被误认为失联）：
-
CONFIG SET repl-disable-tcp-nodelay yes（可选，降低重连敏感度） -
CLIENT KILL TYPE replica（主动断开所有复制连接，包括对主节点的 sync 请求） -
DEBUG RELOAD（慎用！仅用于测试环境快速清空状态；生产环境跳过） - 最关键的一步：
CONFIG SET slave-serve-stale-data no，再立即执行SLAVEOF NO ONE—— 这会让该节点停止作为 replica，也不再响应客户端读请求，避免脏读
通知哨兵并确认其不再将其纳入判断
如果集群使用了 Redis Sentinel，需确保哨兵不会因该 replica 下线而发起无谓的故障转移投票。操作顺序必须是：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先在哨兵节点上执行：
SENTINEL RESET <master-name>（刷新哨兵对主节点的 replica 列表缓存） - 再检查哨兵日志或运行：
SENTINEL REPLICAS <master-name>，确认目标节点已不在返回列表中 - 若仍存在，等待
sentinel monitor配置中的down-after-milliseconds超时（默认 30000ms），或手动触发一次SENTINEL CKQUORUM <master-name>验证法定票数是否仍满足
注意：SENTINEL FAILOVER 不可用于下线 replica，它只针对主节点强制触发切换，对 replica 无效且会报错 NOGOODSLAVE。
最后 shutdown 从节点服务
确认以上步骤完成后，再执行标准关闭流程：
- 在从节点机器上运行：
redis-cli -p <port> shutdown（推荐带save参数，如shutdown save，确保 RDB 持久化完成） - 若使用 systemd，可用：
systemctl stop redis@<instance-name>（取决于你的实例管理方式） - 切勿直接
kill -9进程，否则可能丢失最后几秒的 AOF 缓冲或导致 RDB 文件损坏
真正容易被忽略的是：很多团队只做了 SLAVEOF NO ONE 就以为万事大吉，结果哨兵仍在后台计数该节点的“主观下线”次数，直到超时才清理元数据——这期间一旦主节点真出问题，哨兵可能因法定人数不足而无法完成故障转移。
