AOF 机制本身不阻塞读请求，GET 等读命令完全不受影响；真正影响读的是 bgrewriteaof 的 fork 开销、重写缓冲区压力及磁盘 I/O 瓶颈。
没有直接影响。Redis 的 AOF 机制本身不阻塞读请求，GET、HGET 等纯读命令在主线程中执行时，完全不受 AOF 日志写入路径干扰。
AOF 写入发生在独立线程或内核缓冲区，不抢占读操作 CPU 时间
AOF 的实际写盘行为由 appendfsync 策略控制，但无论选 always、everysec 还是 no，写入动作都不在 Redis 主线程同步完成：
-
always：主线程调用write()+fsync()，但仅当磁盘 I/O 延迟极高（如机械盘满负载）时，才可能短暂拖慢主线程 —— 此时读请求延迟会上升，但本质是 I/O 瓶颈，不是 AOF 逻辑阻塞读 -
everysec（默认）：主线程只负责把命令追加到内存缓冲区aof_buf；后台有单独线程每秒执行一次write()和fsync()，读请求完全不受影响 -
no：主线程只调用write()，后续全交由操作系统刷盘，对主线程零开销
真正会卡住读请求的，是 AOF 重写（bgrewriteaof）期间的子进程 fork 和缓冲区拷贝
虽然 AOF 日志追加本身不阻塞读，但 bgrewriteaof 触发时，以下环节可能间接拖慢读请求：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 主进程
fork()子进程：在内存大、页表多的实例上，fork()耗时可能达百毫秒级，期间主线程暂停所有命令处理（包括读） - 重写缓冲区
aof_rewrite_buf持续接收新写命令：若写流量极大，该缓冲区膨胀会增加内存压力和 memcpy 开销 - 重写完成前，新旧 AOF 文件并存，磁盘 IO 压力上升 —— 若磁盘带宽饱和，可能拖慢
fsync()，进而让everysec策略下的后台线程积压，间接影响主线程调度（极少见，但高负载下可观察到）
配置不当放大风险：appendfsync everysec + 高频重写 = 读延迟毛刺
当 AOF 文件增长过快（比如重写阈值设得太低），导致 bgrewriteaof 频繁触发，就容易在日志中看到读请求超时或 BUSY 错误：
- 检查当前重写触发条件：
CONFIG GET auto-aof-rewrite-percentage和CONFIG GET auto-aof-rewrite-min-size - 默认是
100%增长 +64mb下限，对写密集型业务太激进；建议调高为200或500，且min-size设为1gb以上 - 避免和
save规则同时触发 RDB 快照 ——save也会fork()，叠加后主线程停顿时间翻倍
真正要盯住的不是“AOF 开了会不会卡读”，而是“重写是否频繁”和“磁盘 I/O 是否成为瓶颈”。只要重写间隔拉长、磁盘不打满，读请求基本感受不到 AOF 的存在。
