大Key导致RDB fork阻塞超时及AOF重写内存暴涨，需用MEMORY USAGE精准定位、分片拆解、调优内核参数并避免混合持久化。
大Key导致RDB fork阻塞超时
Redis在执行RDB快照时，会调用fork()创建子进程。如果内存中存在大量大Key（比如一个500MB的hash或zset），父进程页表复制开销剧增，fork()可能卡住数秒甚至触发Linux OOM Killer。此时客户端会感知到明显延迟，INFO persistence里latest_fork_usec值异常高（>1s）就是典型信号。
- 用
redis-cli --bigkeys定期扫描，重点关注hash、list、zset类型中元素数 > 1000 或序列化后体积 > 1MB 的Key - 避免在高峰时段手动触发
SAVE；改用BGSAVE并确保vm.overcommit_memory = 1（防止fork因内存策略失败） - 若业务允许，对已知大Key做分片：比如把
user:profile:12345拆成user:profile:12345:base、user:profile:12345:settings等
AOF重写时大Key引发内存暴涨
当开启AOF且配置了auto-aof-rewrite-percentage，Redis会在AOF重写期间构建新AOF文件。此时它会遍历所有Key，对大Key逐个序列化写入——这不仅吃CPU，更关键的是会额外占用与大Key等量的内存（因为要缓存重写中的内容）。一个2GB的hash可能让重写进程多占2GB RSS，直接触发系统OOM。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 关闭
aof-rewrite-incremental-fsync yes（默认开启），改用no可减少写磁盘抖动，但需确认磁盘I/O能力足够 - 设置
client-output-buffer-limit normal 0 0 0防止重写期间客户端缓冲区累积（尤其当有大量订阅者时） - 对无法拆分的大Key，考虑改用
SCAN+ 异步分批读取+写入新结构，再用RENAME原子切换，避免单次全量操作
RDB/AOF混合持久化下大Key的双重压力
启用aof-use-rdb-preamble yes后，AOF文件前半部分是RDB格式，后半部分是AOF命令。但RDB preamble仍需完整fork + 序列化所有数据——大Key照样拖慢fork，并且AOF重写时还要再处理一遍增量命令。相当于同一份大Key被序列化两次，内存和CPU压力叠加。
- 若业务能接受几秒级恢复延迟，建议关闭混合模式，纯用AOF（
appendonly yes+aof-use-rdb-preamble no），靠bgrewriteaof控制节奏 - 监控
mem_fragmentation_ratio，若长期 > 1.5，说明内存碎片严重，fork开销会进一步放大，此时需重启实例（配合主从切换） - 不要依赖
CONFIG SET动态开启混合模式——它会强制触发一次AOF重写，大Key场景下极易失败
用MEMORY USAGE精准定位问题Key
DEBUG OBJECT不准，MEMORY USAGE才是测量大Key真实内存开销的唯一可靠方式。它返回的是Redis内部实际分配的字节数，包含编码开销、指针、哈希表扩容冗余等，比序列化长度更贴近fork和重写的实际压力。
- 执行
MEMORY USAGE <key>前先用TYPE <key>确认类型，不同结构内存模型差异极大（比如ziplist编码的hash比hashtable省3倍内存） - 对
list或zset，用LLEN/ZCARD配合MEMORY USAGE看“平均单元素成本”，快速判断是否编码退化（如list从quicklist变成linkedlist） - 注意
MEMORY USAGE本身是阻塞命令，别在生产环境对疑似大Key高频轮询；应结合SCAN采样+后台脚本异步分析
fork()的真实耗时，也没看过MEMORY USAGE返回的数字。 
