SAVE 命令会阻塞 Redis 主进程同步写入 RDB 文件，期间不处理任何请求；适用于停机前且可接受中断的场景，但生产环境应优先用 BGSAVE，配合 AOF 才能保障数据不丢。
SAVE 命令会阻塞整个 Redis 实例
执行 SAVE 时，Redis 主进程会同步把所有数据写入磁盘 RDB 文件，期间完全不处理任何客户端请求。如果你的实例有几 GB 数据或正在承受高并发，这个操作可能卡住几十秒甚至更久——你看到的“没响应”不是网络问题，是 Redis 真的在等 IO 完成。
常见错误现象：redis-cli 卡住、应用连接超时、监控显示 connected_clients 突降、INFO commandstats 里 save 耗时异常高。
- 只在真正停机前、且确认无流量或可接受中断时用，比如维护窗口期的单机开发环境
- 生产环境几乎从不推荐，尤其集群或主从架构下，主节点卡住会导致从节点复制延迟飙升
- 替代方案优先考虑
BGSAVE（后台异步保存），它 fork 子进程完成，主进程继续服务
SAVE 和 BGSAVE 的持久化结果完全一致
SAVE 和 BGSAVE 生成的 RDB 文件内容、格式、校验逻辑一模一样，都是对当前内存快照的二进制序列化。区别只在于谁来执行、是否阻塞。
使用场景：当你需要确保某次保存「绝对发生」且不依赖子进程生命周期（比如容器被 SIGTERM 杀死前最后一搏），SAVE 是唯一能绕过 fork 失败风险的操作——但代价是确定性阻塞。
- fork 失败常见于内存不足、
vm.overcommit_memory=0内核配置、或容器内存限制过严；此时BGSAVE会报错Cannot fork，而SAVE仍可尝试落盘 -
SAVE不依赖fork，所以不受copy-on-write内存放大影响，但会吃满单核 CPU + 持续磁盘 IO - 检查是否成功：保存后立刻执行
INFO persistence，看rdb_bgsave_in_progress是否为 0，rdb_last_save_time是否更新
停机前只靠 SAVE 不足以保证数据不丢
Redis 默认开启 RDB 快照，但 AOF（Append Only File）才是更可靠的持久化方式。如果没开 AOF，SAVE 只能保存上一次快照以来的「全量状态」，中间所有写命令全部丢失。
参数差异：SAVE 不受 save 配置项控制（如 save 900 1），它是手动触发的独立行为；但它依然无法覆盖最后一次 SAVE/BGSAVE 之后的增量变更。
- 确认你的
redis.conf中启用了 AOF：appendonly yes，并设为appendfsync everysec或always - 停机前建议组合操作：
redis-cli CONFIG SET appendfsync always→redis-cli BGREWRITEAOF（等待完成）→redis-cli SAVE - 注意：
SAVE不会重写 AOF，也不会触发 AOF rewrite，它只管 RDB
容器或 systemd 环境下 SAVE 可能被信号中断
在 Docker stop 或 systemctl stop redis 过程中，主进程收到 SIGTERM 后若正在执行 SAVE，系统可能直接 kill 掉它，导致 RDB 文件损坏或不完整（文件大小异常、redis-check-rdb 报错）。
性能影响：SAVE 期间磁盘 IO 利用率接近 100%，若和其他服务共盘，可能拖慢整台机器。
- 务必在
SAVE前用redis-cli INFO server | grep "redis_version"确认版本 ≥ 6.2，老版本在信号处理上有竞态 bug - systemd 用户应在 service 文件中设置
ExecStop=/usr/bin/redis-cli -p 6379 SHUTDOWN SAVE，让 Redis 自己控制关机流程 - Docker 用户避免直接
docker stop，改用docker exec redis redis-cli SHUTDOWN SAVE，再等退出
真正关键的不是“有没有执行 SAVE”，而是“SAVE 有没有完整写完”。磁盘满、权限错、OSError 都会让它静默失败——每次执行完，记得 ls -l dump.rdb 看大小是否合理，redis-check-rdb dump.rdb 看校验是否通过。
