根本原因在于fork()系统调用开销及内存遍历，而非磁盘写入：千万级Key下，fork()复制页表和建立COW映射耗时数十至数百毫秒，子进程遍历混合编码数据结构进一步拉长耗时；THP开启会加剧fork抖动，需禁用；应关闭自动save、改用定时BGSAVE+轮转，并预留足够内存防OOM。
为什么BGSAVE在千万级Key下会变慢
RDB快照时间变长，根本原因不在“写磁盘”，而在fork()和后续的内存遍历。当Redis实例有千万级Key（比如1500万+）、内存占用超20GB时，fork()本身就会卡住主线程几十毫秒甚至上百毫秒——这不是Redis代码慢，是操作系统复制页表、建立COW映射的开销。接着子进程遍历整个内存数据结构（dict + skiplist + ziplist等混合编码），哪怕数据已压缩，遍历+序列化仍需大量CPU时间。你看到的“BGSAVE耗时3分钟”，往往前10秒卡在fork()，剩下170秒在序列化。
必须关掉Transparent Huge Pages（THP）
这是千万级Key场景下最容易被忽略、但影响最大的系统级坑。Linux默认开启THP，它会让内存页从4KB变成2MB大页，看似提升吞吐，但在fork()时会导致：所有大页必须被拆成小页并复制，引发严重抖动；fork()延迟从毫秒级飙升到秒级；INFO persistence里能看到rdb_bgsave_in_progress:1但长时间没进展。验证是否开启：cat /sys/kernel/mm/transparent_hugepage/enabled，如果输出包含[always]就中招了。
临时禁用：echo never > /sys/kernel/mm/transparent_hugepage/enabled
永久禁用：在/etc/rc.local或systemd启动脚本里加这行，或通过内核参数transparent_hugepage=never启动。
调低save策略频率，改用定时BGSAVE + 备份轮转
默认配置save 60 10000在高写入场景下极易误触发——每分钟只要改1万个key就强制一次RDB，而千万级Key实例通常QPS上万，等于几乎每分钟都在做全量快照，IO和fork压力雪球式增长。更糟的是，多个save规则共存时，只要满足任一条件就触发，根本无法预测节奏。
实际做法是：
- 注释掉redis.conf里所有
save行，彻底关闭自动触发 - 用crontab每4小时执行一次
redis-cli -p 6379 BGSAVE（避开业务高峰） - 配合Shell脚本做RDB文件轮转：保留最近5个快照，旧文件自动
gzip压缩并移出数据盘 - 关键点：脚本里加
sleep等待redis-cli INFO persistence | grep rdb_bgsave_in_progress返回0再继续，避免并发BGSAVE
预留足够内存，防止fork失败或OOM Killer介入
千万级Key实例，fork()子进程理论上需要和父进程一样多的**虚拟内存空间**（物理内存不立即增加，但OS要预留）。如果系统剩余内存不足，fork()直接失败，日志里出现Can't save in background: fork: Cannot allocate memory。更危险的是，即使fork()成功，后续子进程序列化过程中若物理内存不足，Linux OOM Killer可能把Redis主进程干掉。
安全水位线建议：
- Redis最大内存设为总内存的55%～60%，例如64GB机器，
maxmemory 36gb - 确保
free -h显示的可用内存始终＞Redis当前内存使用量 × 1.2 - 监控项必加：
INFO memory里的mem_rss和used_memory比值，持续＞1.8说明内存碎片严重，也会拖慢RDB
真正卡住RDB的，往往不是磁盘IO，而是fork()那一刻的系统状态和内存布局。THP、内存水位、自动save策略这三者叠加，才是千万级Key下RDB慢的根因。调参前先看INFO stats里的latest_fork_usec，它比任何理论都真实。
