save命令同步阻塞主进程，导致redis完全不可用；bgsave通过fork子进程异步执行，仅fork瞬间短暂阻塞，主进程持续服务，且自动触发的持久化（如save配置、shutdown、主从同步）均实际调用bgsave。
SAVE 命令会让 Redis 主进程完全停摆，所有客户端请求排队等待，直到 RDB 文件写完 —— 这不是“慢”，是真·卡死。线上环境必须禁用 SAVE，只用 BGSAVE。
SAVE 为什么卡死整个 Redis
Redis 是单线程事件循环模型，SAVE 直接在主线程调用 rdbSave()，全程阻塞：
– 不处理任何新命令（GET、SET、DEL 全部挂起）
– 不响应心跳、不处理超时、不执行定时任务（比如 serverCron）
– 阻塞时间 = 序列化全部 key + 写入磁盘耗时，数据量达 GB 级时可能卡住几十秒
常见错误现象：
– 客户端报错 Connection refused 或 Timeout（其实是连接能建，但命令不返回）
– redis-cli 执行 SAVE 后光标不动，几秒甚至几分钟没反应
– 监控看到 connected_clients 暴涨、rejected_connections 上升
BGSAVE 的 fork 机制和真实开销
BGSAVE 并非“完全不卡”，它只在 fork() 系统调用瞬间阻塞主线程 —— 通常几毫秒，但受以下因素影响：
– 内存页数量：Redis 占用 10GB 物理内存时，fork 可能卡 50~200ms
– 内核版本与 vm.overcommit 设置：Linux 低版本或 vm.overcommit_memory=2 时，fork 可能失败并报 Cannot allocate memory
– 写密集场景：子进程依赖 COW（Copy-On-Write），若主进程高频修改 key，会触发大量内存页复制，实际内存占用翻倍
执行后立即返回 Background saving started，不代表已结束；需用 LASTSAVE 查看最后成功时间，或监控 INFO persistence 中的 rdb_bgsave_in_progress 和 rdb_last_bgsave_status
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
自动触发的 save 配置其实走的是 BGSAVE
配置文件里的 save 60 10000 看似叫 “save”，但 Redis 内部根本不会调用同步 SAVE —— 它触发的是 BGSAVE。
– 唯一例外：当 BGSAVE 因 fork 失败无法启动时，Redis 才会退化为同步 SAVE（日志里会出现 Can't save in background: fork: Cannot allocate memory）
– shutdown 命令默认也走 BGSAVE（除非显式加 NOSAVE 或 AOF 已启用）
– 从节点全量同步时，主节点生成 RDB 也是 BGSAVE
所以你看到配置项叫 save，别被名字骗了 —— 它只是规则名，底层全是异步子进程。
什么时候真该用 SAVE（极少）
只有两种现实场景可考虑 SAVE：
– Redis 实例即将下线，且确认无客户端连接（如容器销毁前），需要确保最后一次快照绝对一致、不依赖子进程生命周期
– BGSAVE 持续失败（fork 错误），而你又不能接受数据丢失，只能硬扛一次阻塞来保底
注意：SAVE 不比 BGSAVE “更可靠”——RDB 文件格式完全一样，差异只在执行路径。所谓“一致性更强”是误解：COW 机制下 BGSAVE 快照仍是某一时刻的精确副本，只是主进程在 fork 后继续写，不影响子进程看到的内存视图。
真正容易被忽略的点：即使你从不手动敲 SAVE，某些运维脚本、旧版备份工具或监控探针仍可能隐式调用它；务必检查自动化流程中所有 Redis 命令调用点。
