扩容判断要区分两类问题
扩容决策的前提是把问题分成两类：容量不足（内存长期贴近上限、淘汰速率上升、命中率下降、出现写错误），和访问模式恶化（少数键或少数客户端把资源吃光）。前者加资源有效，后者扩容只是把故障推迟；先看清是哪一类，再谈加内存还是改代码。
基本信息
| 硬信号 | 写入返回内存相关错误、淘汰持续增长 |
|---|---|
| 软信号 | 命中率下滑、延迟随内存压力波动 |
| 结构信号 | 碎片率高、客户端缓冲占比上升 |
| 可选动作 | 加内存、拆分实例、增加分片、优化键结构 |
| 判断前提 | 先确认访问模式还有没有可优化空间 |
信号与优先动作
| 信号 | 含义 | 优先动作 |
|---|---|---|
| used_memory 长期贴近 maxmemory | 容量水位高 | 评估扩容，或缩短数据生存期 |
| evicted_keys 增长且命中率下降 | 淘汰开始影响业务 | 扩容，或调整淘汰策略与容量预算 |
| 写入返回内存相关错误 | 已到硬上限 | 立即扩容，或释放可再生成的数据 |
| 少数键或少数分片独占资源 | 热点倾斜 | 拆分热点键，单纯加节点无效 |
| 碎片率高、rss 远大于 used_memory | 内存利用效率低 | 评估碎片整理、迁移或重启重建 |
取证命令
取证命令
redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'
redis-cli INFO stats | grep -E 'evicted_keys|keyspace_hits|keyspace_misses'
redis-cli MEMORY DOCTOR
redis-cli MEMORY STATS | head -20
redis-cli --bigkeys # 确认是否存在可拆分的大键典型使用场景
- 容量评审：预算与水位对照，决定扩容节点数或内存规格
- 告警响应分级：区分「需要立即扩容」与「可以优化结构」
- 分片数决策：判断是总量不足还是分布不均
- 成本评估：确认扩容收益大于键结构与写入模式优化的成本
- 复盘口径：说明这次故障扩容能否真正解决
判断顺序建议是先看键结构与访问模式（大键、批量全量扫描、无节制写入），再评估资源；能靠代码改掉的增长，加机器只是把曲线往后推。
集群环境还要看分布是否均衡：单个分片内存远高于其他分片时，增加节点不解决问题，先处理倾斜。