要用 redis-benchmark 模拟突发写入压力，需设 -n 500000 -c 200 -t set -P 10，清空 save 配置并禁用自动 RDB，通过 INFO persistence 监控 rdb_bgsave_in_progress 和 aof_delayed_fsync 等指标定位瓶颈。
如何用 redis-benchmark 模拟突发写入压力
直接用 redis-benchmark 走默认参数，根本压不出 RDB/AOF 的瓶颈点——它默认只发 10 万请求、并发 50，节奏太匀，没法触发 fork 阻塞或 AOF fsync 延迟。要测“突发”，得人为制造短时高吞吐+长连接堆积。
实操建议：
- 用
-n 500000 -c 200 -t set：50 万次写入、200 并发，比默认更易让子进程 fork 拖慢主线程 - 加
-P 10启用 pipeline，单连接批量发命令，模拟真实业务突发场景（比如秒杀后集中落库） - 务必在测试前清空
save配置项，避免干扰；同时用CONFIG SET save ""动态关闭自动 RDB，只保留你手动控制的时机 - 记录
INFO persistence中的rdb_bgsave_in_progress和aof_rewrite_in_progress变化，比看日志更准
RDB fork 阻塞怎么定位和量化
fork 不是“卡死”，而是主线程在复制页表时短暂不可响应，表现为 client 端超时或延迟毛刺。Linux 的 vm.overcommit_memory=1 设置会影响 fork 效率，但更关键的是 Redis 进程的内存页数量——不是总内存大小，而是实际分配的匿名页数。
实操建议：
- 用
cat /proc/$(pidof redis-server)/status | grep VmRSS查 RSS，再结合getconf PAGESIZE估算页数，页越多 fork 越慢 - 在
redis.conf中设置auto-aof-rewrite-percentage 0，禁用 AOF rewrite，避免它和 RDB fork 冲突 - 用
strace -p $(pidof redis-server) -e trace=fork,clone监控 fork 耗时（注意 strace 本身有开销，仅用于定位） - 观察
latency monitor输出：redis-cli --latency -h x.x.x.x -p 6379，突发期间若出现 >100ms 的延迟尖峰，大概率是 fork 导致
AOF fsync 策略对写入吞吐的真实影响
appendfsync always 在突发写入下不是“每次写都磁盘刷”，而是每次 write() 后立刻调用 fsync()，这会让吞吐暴跌到几百 QPS；everysec 是折中，但要注意：它不是“每秒刷一次”，而是把这一秒内所有 write 缓冲合并刷盘，一旦后台刷盘线程卡住（比如磁盘 I/O 高），缓冲区会堆积，最终触发阻塞式 fsync。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- 测试前用
CONFIG SET appendonly yes+CONFIG SET appendfsync everysec，再用redis-cli BGREWRITEAOF触发一次重写，确保 AOF 文件干净 - 监控
INFO persistence中的aof_delayed_fsync：值大于 0 表示已发生延迟刷盘，说明缓冲区开始积压 - 对比
appendfsync no（依赖 OS 刷盘）下的吞吐，你会发现它接近 RDB 模式，但崩溃丢失风险不可控——这不是性能问题，是数据可靠性边界问题 - 别只看平均延迟，用
redis-cli --intrinsic-latency 100测 Redis 自身事件循环抖动，排除网络和客户端干扰
RDB 和 AOF 混合开启时谁真正接管写入路径
Redis 4.0+ 的混合持久化（aof-use-rdb-preamble yes）不是“RDB 和 AOF 同时工作”，而是在 AOF rewrite 完成后，用 RDB 格式快照替代前面的文本协议命令。所以日常写入仍走 AOF append，只有 rewrite 期间才生成 RDB 片段。
实操建议：
- 开启混合模式后，
redis-cli BGREWRITEAOF生成的 AOF 文件开头是REDIS0009魔数（RDB 格式），后面才是 AOF 命令——用head -c 10 aof-file可验证 - 不要以为开了混合模式就能“兼顾速度和安全”：rewrite 期间依然会 fork，且 AOF 文件体积比纯 RDB 大得多，恢复更慢
- 测试恢复时间时，用
time redis-server redis.conf --appendonly yes启动并计时，注意观察INFO persistence中的aof_last_load_time_sec字段，它比 shell 的 time 更准 - 线上若用混合模式，必须预留足够内存：rewrite 过程中，Redis 会同时持有旧 AOF、新 AOF（含 RDB 片段）、以及 fork 出的子进程内存副本
最常被忽略的一点：持久化行为高度依赖操作系统调度和磁盘 I/O 调度器。同一份配置，在 ext4 + deadline 和 xfs + mq-deadline 下表现可能差 3 倍——别只盯着 Redis 参数调优，先确认 cat /sys/block/*/queue/scheduler 和 vm.swappiness 是否合理。
