AOF 不比 RDB 更耗 CPU，RDB 的 fork 和全量序列化才是 CPU 密集型操作；AOF 主要开销在磁盘 I/O 和内存缓冲管理，appendfsync everysec 几乎不增加 CPU 使用率，真正耗 CPU 的是 bgrewriteaof 和混合持久化中的 RDB 部分。
AOF 并不比 RDB 更消耗 CPU 资源；相反，RDB 的 fork + 全量序列化才是 CPU 密集型操作，AOF 的主要开销在磁盘 I/O 和内存缓冲管理上。
为什么 bgsave 会明显卡住 Redis 主进程（尤其大内存场景）
RDB 的 CPU 峰值压力集中在 bgsave 触发时的 fork 阶段：
- fork 子进程本身需复制父进程页表，若 Redis 占用 20GB 内存，即使启用写时复制（COW），页表项数量仍达数百万级，该过程由内核完成，主进程会短暂阻塞（毫秒到数百毫秒不等）
- 子进程遍历全部 key-value 对、执行序列化（包括字符串编码压缩、整数转 LZF 等）、计算校验和、写入临时文件 —— 这些都是纯 CPU 计算，且无法并行加速
- 若系统开启透明大页（THP），fork 开销可能翻倍，因内核需拆分大页；
/sys/kernel/mm/transparent_hugepage/enabled应设为never
为什么 appendfsync everysec 几乎不增加 CPU 使用率
AOF 的“日志追加”本质是内存拷贝 + 缓冲区管理，CPU 成本极低：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每个写命令仅做一次
memcpy到 AOF 缓冲区（aof_buf），长度通常几十字节，耗时纳秒级 - 每秒一次的
write(2)系统调用由后台线程或主线程异步触发，不参与命令执行路径 - 真正耗 CPU 的是
bgrewriteaof—— 它也要 fork 子进程、遍历全量数据、生成新 AOF 文件，和bgsave属于同一量级的 CPU 压力源
appendfsync always 不是 CPU 问题，而是磁盘同步瓶颈
该模式下每次写都调用 fsync(2)，问题不在 CPU，而在存储延迟：
- SSD 上
fsync平均耗时约 0.1–0.3ms，机械盘可达 5–15ms；高并发写时大量线程被阻塞在fsync等待队列中 - CPU 使用率可能反而下降（大量线程 sleep），但
redis-cli --latency会显示 p99 延迟飙升 - 错误日志里常见
Asynchronous AOF fsync is taking too long，这是内核 I/O 调度器反馈，不是 Redis 自身计算慢
真正容易被忽略的 CPU 消耗点：AOF 重写与混合持久化
当同时开启 RDB 和 AOF（appendonly yes + save 配置），风险叠加：
- 若
bgrewriteaof和bgsave在相近时间触发，两个子进程同时遍历内存、序列化、压缩 —— CPU 使用率可瞬时拉满，导致主进程响应延迟升高 - AOF 重写期间，主进程还需维护重写缓冲区（
aof_rewrite_buf_blocks），每次写命令都要额外判断是否需同步到该缓冲区，带来微小但持续的分支预测开销 - Redis 7.0+ 引入的混合持久化（
aof-use-rdb-preamble yes）会在 AOF 文件开头嵌入 RDB 快照，首次加载时省去命令重放，但生成时仍需 fork + RDB 序列化 + AOF 命令拼接，CPU 成本高于纯 AOF
