4. 容量规划基础：QPS、吞吐量、内存占用估算方法、容量模型构建
容量规划是分布式缓存面试的“送分题”也是“送命题”。面试官通过这一章考察你的 数字敏感度、业务体感 和 系统思维。你需要清晰回答如何从业务指标（DAU、转化率）推导出技术指标（QPS、带宽、内存），并构建可扩展的容量模型。
核心原则：容量规划不是静态的“拍数字”，而是基于 业务指标驱动 的动态计算过程。面试官期待看到你具备从“业务语言”翻译到“技术水位”的能力。
常规问答卡片
面试问题：假设公司核心 Feed 流业务日活 5000 万，用户平均刷新 6 次，请你估算需要多少 QPS 和吞吐量来支撑 Feed 流缓存层？
面试官考察点：峰值估算能力（关注峰值因子）、请求模型理解（读/写比例）。
回答框架：1. 计算总请求量（PV）-> 日均 PV = DAU * 刷新次数。2. 计算平均 QPS -> 日均 PV / 86400。3. 计算峰值 QPS -> 平均 QPS * 峰值因子（通常 3-5）。4. 吞吐量 = 峰值 QPS * 单次响应大小。
简短示例回答：“日均 PV = 5000 万 * 6 = 3 亿。平均 QPS = 3 亿 / 86400 ≈ 3500。按 4 倍峰值因子算，峰值 QPS ≈ 1.4 万。若单次响应压缩后 10KB，则峰值吞吐量 = 1.4 万 * 10KB = 140MB/s。”
可能追问：“如果数据是 1 写 9 读，你的缓存过期策略如何应对？”
避坑提醒：不要只算平均值忽略峰值；不要忽视响应大小对网卡带宽的瓶颈影响。
面试问题：如何估算一个业务模块（如用户关系链）对 Redis 的内存占用？
面试官考察点：对 Redis 底层数据结构（SDS、Dict、ZipList）的理解，序列化开销。
回答框架：1. 拆解数据项（key + value + 元数据）。2. 计算单条数据理论大小。3. 乘以数据总量（业务条数）。4. 加入 Redis 元数据（dict entry、jemalloc 对齐）和设备冗余（Master + Replica + Buffer）。
简短示例回答：“将关系链拆为 key（uid+关系链id~64B），value（用户id列表~1KB）。单个 dict entry 约 50B 元数据。以 1 亿条计，理论值 ≈ (64+1000+50)B * 1亿 ≈ 110GB。考虑 Replica 和 buffer，建议申请 300GB+。”
可能追问：“如果使用 Hashtag 分片，内存碎片率如何控制？”
避坑提醒：不要只算用户数据，忽略 Redis 进程元数据和碎片率（通常估算因子乘 1.2）。
面试问题：设计一套容量模型，用于预测未来 6 个月的缓存集群水位。
面试官考察点：长期规划、动态预测、线性与指数增长模型的选择。
回答框架：1. 因变量提取（DAU, 留存率, 功能渗透率）。2. 基线速率计算（基于当前水位）。3. 增长率假设（引入业务侧未来 Q2/Q3 预期）。4. 模型公式：未来容量 = 当前基线 * (1 + 增长率)^月数 + 新业务预留。
简短示例回答：“当前 QPS 基线为 10 万。业务侧预期 Q2 日活增长 20%，Q3 上线新社区功能。模型设为：P(m) = 10万 * (1+0.03)^m + 3万（新业务储备）。6 个月后预测 QPS ≈ 12 万 + 3 万 = 15 万。据此提前扩容。”
可能追问：“如果模型低估或高估了 50%，你的弹性扩缩容预案是什么？需多久完成？”
避坑提醒：避免静态拍数字，忽略业务增速；避免复杂模型缺乏可解释性和可调整性。
知识结构表格：容量规划四大核心指标对比
| 指标 | 估算逻辑 | 核心瓶颈 | 面试常见坑 |
|---|---|---|---|
| QPS | PV / 86400 * 峰值因子 | CPU | 只算平均不算峰值 |
| 吞吐量 | QPS * 单次响应体大小 | 网卡带宽 | 忽略带宽监控上限 |
| 内存 | 数据量 * (1 + 元数据因子) | 机器成本 | 忘了算碎片率和 Replica |
| 连接数 | 长连接数 + 新建连接数(每秒) | FD 限制 | 忽略服务重启导致的连接风暴 |
项目案例模板：双 11 大促全链路缓存容量预估与保障
项目名称：双 11 大促全链路缓存容量预估与保障
业务背景：应对双 11 流量洪峰，需提前 1 个月完成核心交易/商品链路的缓存容量评估与交付，避免过载宕机。
规模指标：峰值 QPS 400 万，总内存占用 1.8TB，总吞吐量 2.5GB/s，覆盖 200 + 核心 Redis 集群。
技术栈：Redis Cluster（读写分离架构）、RedisShake（数据仲裁同步）、自研容量预测平台。
核心难点：1. 非核心服务降级后流量反弹导致容量黑洞。2. 大 Key / 热 Key 预热导致分片倾斜。3. 数据过期导致的主从复制延迟。
面试高频追问：“大促期间如何在不扩机器的情况下提升有效容量？” -> “业务降级、TTL 调优、冷热分离至 SSD（Pika）。”
可迁移回答话术：“我主导了双 11 容量规划，建立了‘业务指标 -> 技术水位’的预测模型。通过压测验证，在上线前 2 周完成扩容，确保了零容量故障。同时预设了降级预案，应对突发流量波动。”