rdb的save规则在高并发下拖垮主线程，因频繁触发导致反复fork，而fork耗时与内存强相关（如12gb达300ms+），引发请求堆积、qps骤降、连接拒绝；错误配置save 60 10000易被写密集业务触发，应禁用自动save、改用定时bgsave，并调低stop-writes-on-bgsave-error至no。
为什么高并发下 RDB 的 save 规则会拖垮主线程
频繁触发 save 会导致子进程反复 fork，而 fork 耗时与 Redis 当前内存数据量强相关。12GB 数据集在 Linux 上 fork 可达 300ms+，期间主线程虽不阻塞，但客户端请求队列会快速堆积，表现为 instantaneous_ops_per_sec 骤降、rejected_connections 上升。
常见错误配置：
-
save 60 10000—— 1 分钟内改 1 万个 key 就触发，写密集型业务（如实时计数）几乎必中 -
stop-writes-on-bgsave-error yes—— 磁盘满或权限错时直接拒绝所有写入，业务瞬间中断
建议做法：
- 生产环境禁用自动
save，改用定时任务调用redis-cli bgsave，时间避开业务高峰 - 保留一条兜底规则，如
save 3600 1（1 小时至少 1 次变更才触发），避免完全无快照 - 把
stop-writes-on-bgsave-error改为no，让写继续，靠监控告警人工介入
为什么 appendfsync everysec 是 AOF 的唯一合理选项
appendfsync always 每条命令都 fsync，磁盘 I/O 成瓶颈，QPS 明显下跌；no 完全交由 OS 调度，断电可能丢数秒数据；everysec 是折中——命令先写入内核缓冲区，每秒一次批量刷盘，性能损失可控（实测 QPS 下降
但有两个隐藏坑必须处理：
- AOF 重写（
bgrewriteaof）期间，新命令仍追加到旧 AOF 文件，直到重写完成才原子替换，此时磁盘写压力翻倍 -
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size设置过激（如 50% + 64MB），小文件也会频繁重写
推荐配置：
appendfsync everysec-
no-appendfsync-on-rewrite yes—— 重写时不额外 fsync，降低干扰 -
auto-aof-rewrite-percentage 100+auto-aof-rewrite-min-size 256mb—— 避免小文件误触发
混合持久化（aof-use-rdb-preamble）不是可选项，是高并发刚需
单独开 RDB 或 AOF，在高并发下都不够稳妥：RDB 快照间隔长，AOF 重写又吃资源。开启 aof-use-rdb-preamble yes 后，AOF 文件开头是 RDB 格式快照，后面才是增量命令 —— 恢复时直接加载 RDB 部分，再重放少量 AOF 命令，恢复速度提升 3–5 倍，且重写更轻量。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
必须同步调整：
-
appendfsync everysec（已说明） -
auto-aof-rewrite-percentage应基于 RDB 大小计算，而非纯 AOF 增量大小 - 确保
dir和dbfilename配置指向同一磁盘分区，避免跨盘写入放大延迟
别忽略 latest_fork_usec 和 mem_fragmentation_ratio 这两个关键指标
latest_fork_usec 直接反映 fork 开销，线上应长期监控；超过 100000μs（100ms）就要干预。它和大 Key、内存碎片高度相关。
mem_fragmentation_ratio 超过 1.5 时，fork 耗时会指数级上升 —— 因为 jemalloc 在碎片化内存中找连续页更费劲。
所以调优不能只盯持久化参数：
- 定期用
redis-cli --bigkeys扫描并拆解 >100KB 的 Key - 启用
activedefrag yes（Redis 4.0+），配合active-defrag-threshold-lower 10控制触发阈值 - 压测时用
INFO stats对比latest_fork_usec和evicted_keys，确认是否因淘汰策略加剧了 fork 压力
真正卡住高并发的，往往不是某个开关没开，而是 fork 耗时、内存碎片、大 Key 这三者叠在一起，把每秒几次的后台操作变成了毫秒级抖动源。
