redis持久化磁盘io开销非固定，取决于策略、写入节奏、磁盘类型与配置：aof always易压满hdd随机写吞吐，rdb bgsave引发数十mb/s突发io；everysec实际io不均，重写时两路io叠加；混合持久化拆分io但未减少总量；调度器不当（如cfq）会加剧延迟毛刺。
Redis持久化对磁盘IO的开销不是固定值，而是高度依赖你选的策略、数据写入节奏、磁盘类型和配置参数。在高并发写场景下，AOF appendfsync always 可能吃满单块HDD的随机写吞吐，而RDB bgsave 一次触发就可能造成几十MB/s的突发IO——这足以拖慢同盘上的其他服务。
RDB快照的IO爆发特征
RDB本身不持续写盘，但每次触发都会产生集中式IO压力：
-
bgsave由子进程执行，但fork后子进程需遍历整个内存页并序列化，若内存大（比如32GB），即使启用rdbcompression yes，写入SSD也要持续2–5秒，期间磁盘写队列可能堆积 - 机械硬盘上，RDB写入速度常卡在80–120 MB/s，远低于SSD的500+ MB/s，容易成为瓶颈
- 如果配置了
save 60 10000（60秒内1万次变更就触发），在写密集型业务中可能每分钟都触发一次，IO变成准持续状态
AOF everysec模式的真实IO行为
appendfsync everysec 看似“每秒一次”，实际IO并不均匀：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Linux内核会把AOF缓冲区内容攒到4KB或超时才刷盘，所以多数秒内无IO，但某一秒可能集中刷入几十MB（尤其批量写入后）
- 重写（
bgrewriteaof）期间，新AOF日志仍持续追加，同时后台进程要读旧AOF + 写新AOF，两路IO叠加 - 若开了
no-appendfsync-on-rewrite yes，重写时暂停fsync，那这一秒的数据就裸奔——不是丢不丢的问题，是“丢多少”取决于崩溃时刻
混合持久化加重还是缓解IO？
混合模式（aof-use-rdb-preamble yes）不是简单叠加，而是分阶段IO：
- 启动时先加载RDB部分（快），再回放AOF尾部（慢但量小），整体恢复快，但生成文件时仍要先写RDB再追加AOF，磁盘写总量比纯RDB略大
- RDB部分仍受fork内存复制影响；AOF部分仍要承担重写压力——它没减少IO，只是把IO拆成“集中+轻量”两段
- 真正降低IO的是配合策略：比如用
appendfsync no+ 混合持久化，此时AOF只靠OS缓存刷盘，IO几乎不可见，但断电可能丢数秒
最容易被忽略的一点：Redis自身不控制磁盘调度策略。哪怕你用SSD，如果系统IO调度器还是cfq（旧默认），RDB fork后的大量顺序写也可能被AOF的小块随机写插队，导致延迟毛刺。生产环境建议切到deadline或none（NVMe）。
