关闭实例时的保存行为
关闭实例时，Redis 的默认行为是「先尝试保存、成功才退出」：如果启用了 RDB 或 AOF，它会按持久化配置完成一次保存，保存失败则拒绝退出并报错。强制不保存退出用于文件已损坏、磁盘异常这类抢险场景。除了显式命令，systemd 与容器编排发出的停止信号最终也走同一套关闭路径，而编排层的超时强杀可能直接跳过保存环节。
基本信息
| 默认行为 | 尝试保存，保存失败则不退出 |
|---|---|
| 强制不保存 | SHUTDOWN NOSAVE |
| 更稳的替代 | 先手动 BGSAVE，确认成功后再停服务 |
| 信号路径 | 服务管理与编排的停止信号走同样的关闭逻辑 |
| 超时风险 | 编排层强杀会跳过保存步骤 |
典型使用场景
- 计划内停机：先确认持久化正常，再优雅关闭
- 磁盘异常导致关闭被阻塞时的应急处置
- 需要清理损坏文件、准备从备份恢复时强制退出
- 容器滚动升级：确认停止信号有足够的宽限时间
- 演练停机流程，确认数据不会因超时被杀而丢失
关闭流程
关闭流程
redis-cli BGSAVE # 先手动做一次快照
redis-cli INFO persistence | grep rdb_last_bgsave_status
redis-cli SHUTDOWN # 默认：保存成功才退出
redis-cli SHUTDOWN NOSAVE # 紧急：放弃本次增量
systemctl stop redis # 由服务管理触发的关闭
redis-cli INFO persistence | grep -E 'aof_last_write_status'关闭方式对照
| 方式 | 是否保存 | 适用场景 |
|---|---|---|
| 默认关闭 | 尝试保存，失败则不退出 | 常规停机 |
| 先快照再关闭 | 保存可控且可验证 | 计划内维护的推荐做法 |
| 强制不保存 | 完全不保存 | 仅用于抢险与恢复准备 |
| 被强制杀死 | 取决于进程当时状态 | 可能丢失全部未落盘数据 |
关机流程被持久化阻塞时，先看日志找根因（磁盘写满还是目录权限异常），不要习惯性地用不保存退出把问题掩盖过去——那只是把风险推迟到下一次事故。
容器编排的宽限期如果短于一次全量快照所需时间，停止信号最终会演变成强制杀死。大实例要么显式调大宽限期，要么改成先快照再停止的两步流程。