bgsave 仍会阻塞主线程，因其依赖 fork() 系统调用，该操作同步且耗时随内存页数增加而上升；关闭 THP、限制实例内存 ≤16GB、错开写入高峰、启用从节点生成 RDB 可有效缓解。
为什么 bgsave 还会阻塞主线程？
很多人以为只要用了 bgsave 就完全不阻塞，其实不然。Redis 在执行 bgsave 时，主进程仍需做 fork() 系统调用——这个过程本身是同步的，且耗时与当前 Redis 内存页数量正相关。当实例内存达几十 GB、系统负载高或使用了透明大页（THP）时，fork() 可能卡住主线程数百毫秒甚至秒级，表现为客户端请求延迟突增、INFO stats 中 latest_fork_usec 值飙升。
常见误判：看到日志里 “Background saving started” 就认为安全了，但 fork 阶段已在主线程完成，此时阻塞早已发生。
如何降低 fork() 开销？
核心思路是减少主进程内存“脏页”压力和优化内核行为，而非单纯调大 save 间隔：
- 关闭 Linux 透明大页：
echo never > /sys/kernel/mm/transparent_hugepage/enabled（必须重启 Redis 生效，否则 fork 耗时可能翻倍） - 限制单个 Redis 实例内存规模，建议 ≤16GB；超大实例拆分为多个分片，比硬扛更可控
- 避免在
bgsave前后高频写入大量 key（如批量导入），因写时复制（COW）机制会导致子进程内存页被提前拷贝 - 确认
vm.overcommit_memory = 1（Linux 内核参数），否则 fork 可能失败并退化为save
bgrewriteaof 和 bgsave 能同时运行吗？
可以，但不推荐。Redis 允许 AOF 重写与 RDB 快照并发执行，但两者都会触发 fork()，叠加后对主线程冲击更大。尤其当磁盘 I/O 已饱和时，两个子进程争抢 I/O 资源，反而延长整体阻塞时间。
实操建议：
- 通过
CONFIG SET no-appendfsync-on-rewrite yes降低 AOF 重写期间的 fsync 压力（注意：仅适用于 AOF 模式且可接受少量数据丢失场景） - 用
redis-cli --stat观察rdb_changes_since_last_save和aof_rewrite_in_progress，错开高峰期手动触发bgsave - 若启用了混合持久化（
aof-use-rdb-preamble yes），AOF 重写本身会生成 RDB 片段，此时可考虑禁用定期save规则，只依赖 AOF 重写兜底
真正免阻塞的替代方案：RDB + 复制 + 外部备份
纯靠 Redis 自身机制无法彻底消除 fork 阻塞，生产环境更可靠的路径是绕过它：
- 关闭主节点的自动
save，仅保留appendonly yes+aof-use-rdb-preamble yes - 让一个从节点开启
save配置，主节点专注服务，所有 RDB 由从节点生成（需确保从节点不承担读流量或已配置slave-read-only yes） - 用
redis-cli --rdb /path/to/dump.rdb在从节点上生成快照文件，再通过 rsync 或对象存储上传，全程不触发 fork
这个方案的关键在于：fork 发生在从节点，不影响主节点 SLA；而外部拉取 RDB 的方式，连子进程都不需要启动。
真正难的不是选哪个命令，而是理解 fork 是操作系统层行为，Redis 只能缓解，不能消除。任何指望靠改几个配置就“彻底解决阻塞”的想法，都会在大内存+高负载下暴露出来。
