增长预测与扩容排期
内存预测的方法不复杂：用周环比配合季节因子外推增长，用「距水位余量除以日均增长」估算触线时间，再按采购与交付周期倒排扩容启动时间。难的是先分辨增长性质——数据量增长可以外推，开销类增长不能，后者要先解决根因。
基本信息
| 方法 | 周环比加季节因子外推 |
|---|---|
| 数据来源 | INFO memory、INFO keyspace、监控趋势 |
| 输出 | 距水位的触线时间点预测 |
| 触发动作 | 按交付周期倒排扩容启动时间 |
| 异常先查 | 无 TTL 的键、大键累积、客户端缓冲与碎片 |
| 纪律 | 留出缓冲并定期校准模型 |
典型使用场景
- 扩容排期：按交付周期倒推启动时间，避免临门一脚
- 预算申报：用预测曲线论证资源需求，而不是拍数字
- 模型校准：按预测与实际的偏差回头修正参数
- 异常识别：增长突然变陡时先查键泄漏或大键累积
- 数据治理：发现无 TTL 键占比高时推动补齐过期策略
最小示例
最小示例
redis-cli INFO memory | grep -E 'used_memory_human|used_memory_peak_human'
redis-cli INFO keyspace # 各库键数与过期键占比
redis-cli DBSIZE # 键数总量，用于对照内存增速
redis-cli INFO stats | grep expired_keys # 过期回收速度
redis-cli MEMORY STATS | grep -A1 keys # 键数与平均每键占用判断与动作
| 现象 | 判断 | 动作 |
|---|---|---|
| 内存与键数同步增长 | 数据量增长 | 按增速预测触线时间并排扩容 |
| 内存涨而键数平稳 | 开销类问题 | 查碎片、客户端缓冲、复制积压 |
| 曲线突然变陡 | 出现异常来源 | 先定位无 TTL 键或大键，再谈扩容 |
| 键数涨而内存不涨 | 小键为主或有正常过期回收 | 关注键数对遍历类命令的影响 |
| 增长呈台阶 | 字典扩容或结构改造所致 | 按台阶修正模型，不做线性外推 |
预测不是精确科学：留出缓冲、写清假设、按月校准回归，比追求单点精确更有价值。
先分辨增长性质再排期：数据增长可以外推，开销类增长不可外推，两者的处理方式完全不同。