Redis RDB快照导致主线程卡住的根本原因是fork后子进程写时复制（COW）期间，主线程大量修改内存页触发内核逐页分配与复制，争抢CPU和内存带宽。
Redis RDB快照为什么会让主线程卡住
根本原因不是 fork 本身耗时长，而是 fork 后子进程做内存页拷贝（写时复制，Copy-on-Write）期间，主线程一旦修改大量内存页，就会触发内核逐页分配新物理页并复制内容——这个过程在高负载下会争抢 CPU 和内存带宽，表现为 Redis 主线程响应延迟飙升。
常见错误现象：INFO commandstats 显示 command_call_duration_ms 突增；redis-cli --latency 观测到周期性毫秒级毛刺；监控里 used_memory_peak_human 在 SAVE/BGSAVE 期间明显跳升。
- 大 key（如 500MB 的 hash）被修改时，对应的所有内存页都会被 COW，哪怕只改一个字段
- 开启了透明大页（THP）的 Linux 系统会加剧延迟，因为 THP 的页分裂和合并操作与 COW 冲突
-
vm.overcommit_memory = 0（默认值）时，fork失败概率上升，但更隐蔽的问题是：即使 fork 成功，后续 COW 也可能因内存不足被 OOM killer 干掉子进程
怎么配置才能让 fork 更轻量
核心思路是减少 fork 前主线程的内存“脏页”数量，同时避免内核层面的额外开销。
- 关闭透明大页：
echo never > /sys/kernel/mm/transparent_hugepage/enabled（需 root，重启失效，建议写入/etc/rc.local或 systemd service） - 调大 overcommit：设
vm.overcommit_memory = 1，允许内核乐观分配内存，避免fork因预估失败而拒绝 - 控制内存碎片率：
INFO memory查看mem_fragmentation_ratio，若 > 1.5，说明内存碎片严重，COW 时更易触发页分配；可通过CONFIG SET activedefrag yes启用主动碎片整理（4.0+） - 避免在高峰写入期触发
BGSAVE，用save ""关闭自动保存，改由运维脚本在低峰期调用BGSAVE
哪些操作会让 RDB fork 变得更危险
不是所有写操作影响一样。关键看是否引起大量内存重分配或 page fault。
-
HSET big_hash key1 value1—— 安全：只修改已有 slot，不触发扩容 -
HSET big_hash new_key new_value—— 危险：hash 扩容可能引发整个 dict 重建，大量内存页被标记为 dirty -
LPUSH huge_list item—— 危险：list 底层 ziplist 转 linkedlist 时，旧结构整块内存失效，COW 开销陡增 -
DEL huge_key—— 表面安全，实则危险：key 删除后内存不会立刻归还 OS，但该内存页仍属 Redis 进程，若此时 fork，子进程仍要 copy 这些“待回收”页
替代方案：什么时候该放弃 RDB fork
当实例长期 > 10GB、写入 QPS > 5k、且无法接受任何 sub-ms 级延迟波动时，RDB 的 fork 机制本质不可靠。
- 用 AOF +
appendfsync everysec替代 RDB 做持久化主路径，避免 fork；AOF rewrite 也走fork，但可设auto-aof-rewrite-percentage 0手动控制时机 - 升级到 Redis 7.0+，启用
replica-serve-stale-data no+replica-read-only yes，把 RDB 生成任务完全交给从节点（slave-serve-stale-data已废弃，新版用replica-serve-stale-data） - 极端场景下，直接禁用 RDB（
save ""），用外部工具如redis-rdb-cli定期扫描 dump 文件，或依赖云厂商的内存快照能力（如阿里云 Redis 的“备份上云”不走 fork）
真正难处理的从来不是 fork 调优，而是业务层对大 key 和稀疏写放大缺乏感知——等监控报警再动手，往往已经卡过好几次了。
