必须开启aof-rewrite-incremental-fsync yes，否则aof重写会一次性刷大量脏页导致ssd写放大、await飙升至50ms+、%util达100%；同时禁用no-appendfsync-on-rewrite yes，确保重写中主线程持续fsync。
Redis AOF重写时卡顿，SSD写入延迟飙升怎么办
直接结论：默认 aof-rewrite-incremental-fsync yes 是必须开启的，否则重写过程会一次性刷大量脏页到 SSD，触发写放大和队列积压。这不是 Redis 配置“可选”，而是 SSD 场景下的硬性要求。
常见现象是 AOF 重写期间 INFO persistence 显示 aof_rewrite_in_progress:1，同时 iostat -x 1 观察到 SSD 的 await 突增至 50ms+，%util 持续 100%，Redis 响应延迟毛刺明显。
-
aof-rewrite-incremental-fsync yes强制每 32MB 数据调用一次fdatasync()，把大块刷盘拆成小步，避免单次阻塞过长 - 关闭
no-appendfsync-on-rewrite yes—— 即便 AOF 重写中，也要继续同步主线程的 fsync，否则重写完成瞬间堆积大量待刷日志，反而更卡 - SSD 实际吞吐受限于写入模式：连续大块写（如重写输出）比随机小写友好得多，因此确保
aof-rewrite-incremental-fsync开启后，重写输出文件本身尽量不被其他进程干扰（例如避免在同盘跑 MySQL binlog）
Redis RDB快照落盘慢，save 配置怎么设才不拖垮SSD
RDB 的 save 触发逻辑本身不耗 CPU，但 fork() 后子进程 dump 内存 + 写磁盘的过程，对 SSD 是典型的高吞吐、低队列深度压力源。盲目增加 save 频率只会让 SSD 更早进入写疲劳状态。
关键不是“多久存一次”，而是“每次存多少数据”和“是否错峰”。RDB 文件大小与内存使用量正相关，而 SSD 的耐久度和稳态性能高度依赖写入均衡。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
redis-cli --stat观察used_memory_human波动，把save条件设为“内存增量超过阈值”而非固定时间，例如：save 3600 1000000（1 小时内增 100 万 key 才触发），避免空闲期频繁写空快照 - 禁用
stop-writes-on-bgsave-error yes—— SSD 在高负载下偶发write(2)超时或 ENOSPC 并不少见，让它继续服务比直接拒绝写入更合理 - 若使用 NVMe SSD，确认内核 I/O 调度器为
none（而非mq-deadline），命令：echo none > /sys/block/nvme0n1/queue/scheduler
Redis混合持久化（aof-use-rdb-preamble yes）对SSD的真实影响
开启混合持久化后，AOF 重写不再生成纯文本命令流，而是先写一个紧凑 RDB 格式头部，再追加增量命令。这确实减少了 AOF 文件体积，但对 SSD 来说，代价是写入模式从“大块顺序写”变成“一次 RDB 头部写 + 多次小命令追加”，更容易触发 SSD 的 GC 和写放大。
实测显示：在写入压力持续 > 20K QPS、key 平均大小
- 仅当业务能接受 AOF 文件体积翻倍（相比混合模式），且 SSD 容量余量 ≥ 30% 时，才建议关闭
aof-use-rdb-preamble - 若必须开混合模式，务必配合
aof-rewrite-incremental-fsync yes和更低的aof-auto-gc-threshold（例如设为 60，而非默认 100），主动触发更频繁但更轻量的重写 - 不要指望
bgrewriteaof手动触发能绕过这个问题——它仍走同一套写入路径，只是时机可控而已
SSD硬件层不可忽略的三个Redis适配点
很多性能问题根源不在 Redis 配置，而在 SSD 自身特性没对齐。NVMe 盘和 SATA SSD 表现差异极大，但 Redis 默认配置对两者一视同仁。
- 确认
/proc/sys/vm/dirty_ratio≤ 30（默认 40）：SSD 不需要像 HDD 那样攒大量 dirty page，过高会导致内核一次性刷出巨量 IO，压垮队列 - 禁用 ext4 的
data=ordered挂载选项，改用data=writeback或journal=none（若已用外部日志方案）：Redis 自己保证 AOF 一致性，文件系统日志纯属冗余开销 - 检查 SSD 是否启用 TRIM：运行
lsblk -D查看DISC-GRAN和DISC-MAX是否非零；若为 0，需sudo fstrim -v /var/lib/redis并加入 cron，否则长期运行后写入性能衰减不可逆
SSD 的“快”是条件性的：它不怕大吞吐，但怕小随机写、怕队列积压、怕写满后 GC 滞后。Redis 持久化配置不是调参游戏，而是对底层存储行为的显式契约。漏掉任意一条，IO 吞吐都可能在某次重写或快照后断崖下跌。
