高负载下Redis持久化瓶颈源于磁盘I/O争抢和主线程fork阻塞；应禁用自动RDB、启用混合持久化、设appendfsync为everysec、AOF重写避开高峰，并将持久化文件存于独立SSD以优化I/O调度。
高负载下，Redis持久化性能瓶颈通常来自磁盘I/O争抢和主线程阻塞。直接关掉持久化最省事，但多数业务不能接受数据全丢——关键是要让持久化“不拖慢写入”，而不是“不持久化”。
避免 save 触发频繁 RDB 快照
默认的 save 900 1、save 300 10 在高写入场景下极易被触发，导致 BGSAVE 子进程频繁 fork + dump，CPU 和 I/O 压力陡增。
- 把
save全部注释掉（或设为save ""），彻底禁用自动 RDB；只靠 AOF 或混合模式兜底 - 若必须保留 RDB 备份，改用定时脚本在低峰期手动执行
BGSAVE，避开业务高峰 - 确认
stop-writes-on-bgsave-error设为no，防止一次快照失败就卡住所有写入
把 appendfsync 设为 everysec 而非 always
appendfsync always 会让每次写命令都 fsync() 到磁盘，实测 QPS 可跌 40%+，尤其在机械盘或云盘上更明显。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 生产环境几乎无例外地用
appendfsync everysec：每秒一次fsync，最多丢 1 秒数据，性能损失可控 - 绝对不要用
appendfsync no—— 看似快，但内核延迟刷盘不可控，宕机可能丢几分钟数据 - 搭配
no-appendfsync-on-rewrite yes，确保 AOF 重写期间不额外触发fsync，避免 I/O 雪崩
启用混合持久化（aof-use-rdb-preamble yes）
纯 AOF 在重启时需重放全部命令，大文件恢复慢；纯 RDB 恢复快但丢数据多。混合模式是高负载下的实用折中。
- Redis 4.0+ 必须开启：
aof-use-rdb-preamble yes，让 AOF 文件开头是 RDB 格式快照，后面接增量 AOF 日志 - 效果：重启加载速度接近 RDB，数据安全性接近 AOF（仍受
appendfsync策略影响） - 注意：开启后 AOF 文件体积会略增（RDB 部分 + 日志部分），但比纯 AOF 小得多，且重写更高效
AOF 重写要避开峰值时段
BGREWRITEAOF 或自动重写会读取全量数据、生成新日志，期间 CPU 和磁盘带宽占用高，可能间接拖慢客户端响应。
- 关闭自动重写：
auto-aof-rewrite-percentage 0，完全由运维控制时机 - 用
redis-cli --raw config set auto-aof-rewrite-percentage 0动态关闭（无需重启） - 在凌晨或流量低谷手动触发
BGREWRITEAOF，并监控redis-cli info persistence中的aof_rewrite_in_progress状态
真正容易被忽略的点是：持久化不是“开或关”的二选一，而是 I/O 资源的调度问题。哪怕配置全对，如果 Redis 和 AOF 文件共用一块普通 SATA 盘，性能照样垮——高负载下，把 dir 和 appendfilename 指向 NVMe 或独立挂载的 SSD 分区，比调参数更立竿见影。
