Linux 下 Redis 6.2 开启持久化后消息队列延迟升高，通常是因为 AOF 重写或 RDB 快照触发 fork 子进程时阻塞主线程，或磁盘 fsync 策略过于频繁。优先调整 appendfsync 为 everysec，关闭 aof-rewrite-incremental-fsync，并监控内存碎片率。
先说结论：持久化导致的延迟主要源于磁盘 I/O 阻塞和 fork 操作，需平衡数据安全与性能。
- 先定位：确认延迟峰值是否与 AOF 重写或 RDB 快照时间吻合
- 先做：调整 fsync 策略为 everysec，禁用 rewrite 期间的增量 fsync
- 再验证：通过慢日志和 latency 命令观察延迟是否回落
命令速用版
以下命令用于快速查看延迟状态和修改关键配置，需在 redis-cli 中执行：
redis-cli `--latency` -h 127.0.0.1 -p 6379
CONFIG SET appendfsync everysec
CONFIG SET aof-rewrite-incremental-fsync no
SLOWLOG GET 10
为什么会这样
Redis 持久化导致延迟的核心原因是 fork 子进程和磁盘同步操作占用了主线程资源。Redis 采用单线程模型处理命令，当执行 RDB 快照或 AOF 重写时，操作系统需要 fork 一个子进程，此过程会阻塞主线程毫秒级时间，若内存较大阻塞时间更长。同时，AOF 的 fsync 策略若设置为 always，每次写入都同步磁盘，会显著增加写入延迟。
分步处理
按以下顺序调整配置和排查问题，每一步调整后需观察业务影响：
1. 调整 AOF 同步策略
将 appendfsync 从 always 改为 everysec，牺牲秒级数据安全性换取性能提升。在配置文件中设置 appendfsync everysec 或运行时执行 CONFIG SET 命令。
2. 关闭重写期间的增量同步
AOF 重写过程中默认会进行增量 fsync，增加磁盘压力。执行 CONFIG SET aof-rewrite-incremental-fsync no 关闭该功能。
3. 优化 RDB 触发时机
避免在业务高峰期触发 save 命令。调整 save 配置，例如移除高频触发规则，或仅在低峰期手动触发 bgsave。
4. 排查大 Key 与内存碎片
大 Key 删除和内存碎片过高会加剧 fork 阻塞。使用 redis-cli `--bigkeys` 扫描大键，使用 UNLINK 替代 DEL 异步删除。监控 mem_fragmentation_ratio，超过 1.5 时考虑重启或清理。
怎么验证是否生效
通过内置监控工具确认优化效果，关注延迟峰值和慢查询数量变化：
1. 实时延迟监控
运行 redis-cli `--latency-history` -i 1，观察 max 值是否稳定在较低水平，例如毫秒级以下。
2. 慢日志分析
执行 SLOWLOG GET 10，确认是否有耗时超过阈值的命令，若慢日志减少说明优化有效。
3. 系统负载检查
使用 top 命令观察 Redis 进程 CPU 使用率，确认没有持续的 iowait 过高情况。
常见坑
优化过程中需注意以下风险，避免引发新问题：
- 数据丢失风险：appendfsync 设置为 no 或 everysec 可能在宕机时丢失秒级数据，需评估业务容忍度
- 内存溢出：关闭持久化或调整策略后，若内存无限制可能导致 OOM，需配置 maxmemory
- 网络带宽占用：持久化文件传输或主从同步可能占用带宽，影响网络延迟
常见问题
开启 AOF 后延迟一定比 RDB 高吗？
不一定，取决于 fsync 策略。AOF 设置为 everysec 时性能接近 RDB，但设置为 always 时延迟会显著升高。
为什么删除大 Key 会导致延迟？
DEL 命令是同步阻塞的，删除大 Key 会占用主线程时间，建议改用 UNLINK 命令异步删除。
内存碎片率高会影响持久化吗？
会，内存碎片率高会导致 fork 子进程时复制页表变慢，增加主线程阻塞时间。
参考来源
- Redis 慢查询问题与优化策略
- Redis 性能优化实战 - 知乎
- Redis 延迟问题全面排障指南