突发写入的内存峰值
突发批量写入会把内存同时从多处抬高：数据集本身增长、客户端查询与输出缓冲膨胀、复制积压、持久化缓冲，如果撞上后台保存还会有写时复制的额外占用。峰值管理的目标不是「不出峰值」，而是让峰值始终留在水位以下，并且能在可接受时间内回落。
基本信息
| 峰值来源 | 数据集增长、客户端缓冲、复制积压、持久化缓冲 |
|---|---|
| 控制手段 | 批次大小、写入速率、任务排期 |
| 观测字段 | used_memory_peak、client_recent_max_output_buffer |
| 关键数字 | 距水位余量与回落到常态的时间 |
| 验证方式 | 压测复现突发模式后灰度上线 |
| 风险叠加 | 写峰与 fork 保存撞车时写时复制放大占用 |
典型使用场景
- 批量任务排期：把导入与后台任务挪到低峰，避开持久化窗口
- 容量论证：申请资源用峰值加余量，而不是平均速率
- 限速设计：入口限速必须配回压，否则上游堆积换个地方爆
- 事故复盘：峰值与淘汰、延迟尖峰同期出现时判断是突发造成的
- 压测验收：用接近真实的突发模式复现峰值与恢复过程
最小示例
最小示例
redis-cli INFO memory | grep -E 'used_memory_human|used_memory_peak_human|maxmemory_human'
redis-cli INFO clients | grep -E 'connected_clients|client_recent_max_output_buffer'
redis-cli INFO stats | grep -E 'evicted_keys|rejected_connections'
redis-cli INFO persistence | grep -E 'rdb_bgsave_in_progress|aof_rewrite_in_progress'
redis-cli SLOWLOG GET 10 # 突发期间的慢命令
redis-cli --latency-history -i 5 # 突发期间的延迟变化突发期看什么
| 观察项 | 含义 | 处理方向 |
|---|---|---|
| 已用内存与峰值 | 峰值记录下突发留下的水位 | 用峰值加余量做容量规划 |
| 输出缓冲峰值 | 突发期间单连接缓冲膨胀 | 分批返回，避免一次拉取大量数据 |
| 淘汰与拒绝计数 | 是否已触顶被处理 | 触顶说明余量不足，需扩容或限速 |
| 持久化进行中标志 | 是否与写峰撞车 | 错开调度，减少写时复制叠加 |
| 恢复时间 | 峰值回落到常态的耗时 | 恢复慢说明积压未消化，需继续限速 |
峰值管理的关键数字是余量与恢复时间：只看余量不看恢复时间，会把「勉强扛过去」误判成没问题。
限速必须配回压：入口把速率压下来而上游没有背压机制，堆积只是从 Redis 换到了上游队列里。