容量规划与规格估算是什么
Redis 的容量要算三本账：内存、连接、带宽。内存不只是「值的大小 × 键数」，还包括每键的元数据开销（几十字节起）与内存碎片，且 fork 持久化或全量同步期间可能出现 1.5 到 2 倍的内存峰值；连接数是各客户端连接池之和加复制、监控与运维余量；带宽则按 QPS × 平均请求与响应字节估算，大 value 会显著放大。
基本信息
| 内存构成 | 数据 + 每键元数据 + 碎片 + 复制缓冲 + 客户端缓冲 |
|---|---|
| 估算起点 | 单键实测（MEMORY USAGE）× 键数 × 1.3 左右余量 |
| 峰值场景 | BGSAVE/AOF 重写期间 fork 与写时复制，可能接近 2 倍 |
| 连接预算 | 客户端池之和 + 复制 + 监控 + 运维余量 < maxclients |
| 带宽 | QPS × 平均请求/响应字节数，注意大 value |
| 观察工具 | INFO memory / INFO stats / INFO clients、MEMORY STATS |
典型使用场景
- 新业务上线前的规格评审：给出内存与连接数需求
- 缓存扩容决策：根据增长趋势提前扩容而不是等告警
- 大 key 治理：找出占用异常的单键并拆分
- 带宽评估：确认网络不是瓶颈，避免复制延迟
- 峰值预演：大促前评估 fork 与复制缓冲带来的额外内存
估算与校准
估算与校准
# 内存粗估：单键平均字节 × 键数 × 1.3（元数据与碎片余量）
# 例：100 万键 × 1KB × 1.3 ≈ 1.3GB，再留 20-50% 给 fork 与复制缓冲
# 用真实数据校准，别按拍脑袋的平均值
redis-cli MEMORY USAGE sample_key
redis-cli DBSIZE
redis-cli INFO memory | grep -E 'used_memory_human|used_memory_peak_human|mem_fragmentation_ratio'
# 连接与流量
redis-cli INFO clients | grep -E 'connected_clients|maxclients|blocked_clients'
redis-cli INFO stats | grep -E 'total_net_input_bytes|total_net_output_bytes|instantaneous_ops_per_sec'
redis-cli INFO replication | grep -E 'connected_slaves|master_repl_offset'三本账要点
| 维度 | 估算方式 | 常见遗漏 |
|---|---|---|
| 内存 | 单键实测 × 键数 × 余量 | 忽略每键元数据与碎片，低估 20-50% |
| 峰值内存 | 写入峰值 + fork/复制缓冲 | 大促期间被系统 OOM 杀掉 |
| 连接 | 各客户端池之和再加余量 | 漏掉监控、复制与运维连接 |
| 带宽 | QPS × 平均报文大小 | 大 value 让带宽估算严重偏低 |
| 持久化 | AOF/RDB 文件与重写期间的空间 | 磁盘剩余空间不足导致重写失败 |
小键多时元数据占比很高：一个 100 字节的值实际可能占用 150-200 字节，容量评审必须用样本实测（MEMORY USAGE 加 MEMORY STATS）而不是简单按值大小乘键数。
必须给 fork 与复制缓冲留足余量：BGSAVE 或全量同步期间内存可能接近平时的两倍，若机器总内存只按平时用量配置，写入高峰容易被系统 OOM Killer 直接干掉进程。