redis高并发下卡住请求的主因是rdb fork()阻塞和aof fsync争抢磁盘i/o：fork()时主线程确定性暂停，内存越大阻塞越久（如64gb常超100ms），导致p99延迟破5ms；appendfsync everysec为高并发事实标准，兼顾可靠性与吞吐，而混合持久化仍存在加载慢、rewrite阻塞及监控复杂等硬伤。
大，而且影响是直接可测的——RDB fork() 阻塞和 AOF fsync 争抢磁盘 I/O，在 QPS 超 5 万的系统里，延迟抖动和吞吐下降会立刻暴露出来。
RDB 快照在高并发下为什么会卡住请求？
Redis 主线程调用 fork() 创建子进程写 dump.rdb 时，主线程会暂停（尤其是内存 > 16GB 时）。这不是“偶尔慢一点”，而是确定性阻塞：
-
fork()时间 ≈ 内存大小 / 磁盘 I/O 带宽，64GB 机器 + 普通 SATA 盘，阻塞常超 100ms - 阻塞期间所有命令排队，P99 延迟直接破 5ms（电商库存系统红线）
- 如果
save配置太激进（如save 60 10000），高频写入会频繁触发快照，形成“阻塞-积压-更频繁阻塞”循环
AOF 的 appendfsync 怎么选才不拖垮性能？
不是越安全越好，而是要看你能不能承受写放大和 I/O 尖峰：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
appendfsync always：每次写都刷盘 → 数据零丢失，但 QPS 可能跌 60% 以上，基本不用 -
appendfsync everysec：每秒一次 fsync → 丢最多 1 秒数据，实测对吞吐影响可控（QPS 下降约 10–15%），是高并发场景事实标准 -
appendfsync no：全靠 OS 刷盘 → 吞吐最高，但宕机可能丢几十秒数据，只适合日志类非关键数据 - 注意：
aof-rewrite过程也会fork()，和 RDB 同样有阻塞风险，别让它和 RDB 快照撞在同一时段
为什么 Redis 4.0+ 的混合持久化（aof-use-rdb-preamble yes）不是万能解药？
它把 RDB 文件内容作为 AOF 开头，再追加增量命令，听起来完美，但实际有硬伤：
- 重启加载时仍要先载入 RDB 部分（快照体积大 → 加载慢），再重放 AOF 尾部（命令多 → 解析慢）
-
aof-rewrite仍需fork()，且生成的混合文件比纯 RDB 大 20–30%，网络传输/备份耗时增加 - 监控难度上升：RDB 和 AOF 的延迟、大小、失败率要分开看，不能只盯一个指标
- 真正缓解瓶颈的是“关掉不必要的持久化”——比如只读从节点完全禁用 AOF 和 RDB，专注服务流量
最常被忽略的一点：持久化不是开开关关就能平衡的事。它和主从同步、内存淘汰策略、甚至客户端连接数都耦合在一起。比如 maxmemory 设得太低，频繁触发 LRU 淘汰，会额外加重 AOF 日志量；而 slave 连接数太多，又会让 fork() 更吃力。调参必须连着看，单点优化容易翻车。
