主线程被阻塞的典型表现是突发延迟spikes（如200ms+）及INFO stats中latest_fork_usec超100ms，源于fork后大内存实例的页表复制开销；AOF重写期间启用incremental-fsync虽缓解IO压力，但fsync频次上升仍可能拖慢响应。
落盘期间主线程被阻塞的典型表现
Redis 在执行 RDB 快照或 AOF 重写时，fork() 子进程本身不耗时，但后续的内存页表复制（尤其是大内存实例）会触发内核级拷贝，导致主线程卡顿。你观察到的「突然延迟 spikes（比如 200ms+）」「INFO stats 中 latest_fork_usec 超过 100ms」，基本就是这个阶段。更隐蔽的是，AOF 重写期间若开启 aof-rewrite-incremental-fsync yes，虽缓解 IO 压力，但 fsync 频次上升仍可能拖慢响应。
RDB 落盘优化：减少 fork 开销与写盘干扰
关键不是禁用 RDB，而是让 fork 更轻、写盘更“隐身”：
-
vm.overcommit_memory = 1（Linux 内核参数），避免 fork 因内存检查失败而退化为全量 copy - 设置
save ""禁用自动 RDB，改用redis-cli bgsave手动触发，并避开业务高峰 - 若使用 SSD，确认
io-threads-do-reads yes和io-threads 4（需 Redis 6.0+），让子进程写盘走多线程，不挤占主线程 CPU - 监控
INFO memory | grep mem_allocator，若为jemalloc，确保版本 ≥5.2.1 —— 旧版在 fork 后易产生高碎片，加剧后续分配延迟
AOF 落盘优化：控制 fsync 频率与重写节奏
AOF 的响应影响主要来自 fsync 和重写竞争。不要盲目设 appendfsync always：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 生产环境优先用
appendfsync everysec，它平衡了数据安全与延迟；若业务允许秒级丢失，可临时切到no（依赖 OS 刷盘） - 重写阈值调高：
auto-aof-rewrite-percentage 100+auto-aof-rewrite-min-size 512mb，避免小文件频繁重写 - 启用
aof-rewrite-incremental-fsync yes，让重写子进程分批 fsync，而不是一次刷完 - 禁止在重写期间做 BGREWRITEAOF：用
redis-cli config get aof_rewrite_in_progress检查状态，脚本化规避
混合落盘下最容易被忽略的冲突点
同时开启 RDB 和 AOF（aof-use-rdb-preamble yes）看似稳妥，但实际会放大风险：
- RDB 快照完成瞬间，AOF 会立即追加 preamble，此时若正有大量写入，AOF 缓冲区可能暴涨，触发
client-output-buffer-limit pubsub类似机制的隐式限流 - 两个落盘任务（
bgsave和bgrewriteaof）若撞上同一时刻，fork 压力翻倍，mem_fragmentation_ratio可能瞬时飙到 1.8+ - 真正该做的，是把 RDB 当冷备、AOF 当热备，用
redis-cli --rdb /tmp/dump.rdb定期导出快照，而非依赖自动 save
落盘优化的本质，不是压低单次耗时，而是把不可控的阻塞拆成可控的抖动 —— 重点盯住 fork、fsync、page fault 这三个动作发生的时机和资源争抢点。
