Redis如何通过开启子进程重写机制避免RDB持久化引发的主进程阻塞？

本文共计939个文字，预计阅读时间需要4分钟。

很多人以为只要使用了 `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 能同时运行吗？

可以，但不推荐。