第1章 岗位能力画像与简历优化模板
分布式缓存容量规划工程师的核心竞争力，体现在“容量评估—架构设计—性能调优—故障排查”四位一体的能力闭环。以下画像和简历模板帮助你在面试中精准对标岗位需求。
一、岗位能力画像
| 能力维度 | 核心要求 | 面试关键词 |
|---|---|---|
| 架构设计 | 高可用、高扩展的缓存架构方案 | 主从复制、哨兵、Cluster、一致性Hash |
| 性能调优 | 内存命中率、延迟、吞吐量优化 | LRU/LFU、内存碎片、Redis Pipeline |
| 容量评估 | 未来6-12个月容量预测与规划 | 增长率模型、水位线、分片数计算 |
| 故障排查 | 快速定位缓存相关故障并恢复 | 慢查询、OOM、连接数、延迟毛刺 |
二、简历结构模板
- 个人信息：姓名、联系电话、邮箱、GitHub/技术博客（加分）
- 技术栈：Redis/Memcached、Java/Python、Linux、监控工具（Prometheus/Grafana）
- 项目经验（2-3个）：按STAR结构，突出容量规划、性能优化、故障处理
- 成果量化：命中率从85%提升至99%、集群扩容后延迟降低50%等
- 教育/证书：本科及以上，有Redis认证或云计算认证更佳
三、关键词清单
技术关键词：Redis Cluster、Codis、Twemproxy、AOF/RDB、LRU、Bloom Filter、限流、降级、预热、缓存穿透/击穿/雪崩、内存碎片、Pipeline、连接池、慢查询、bigkey、热点Key、异步淘汰、持久化策略、容量水位、分片数、副本数、一致性Hash。
业务关键词：QPS、TPS、P99延迟、命中率、内存利用率、增长趋势、业务容量估算、SLA、SLO、DBA联动、巡检自动化。
四、成果量化句式
- 使用 “从…提升到…” 结构：缓存命中率从85%提升到99.2%，降低了数据库QPS 60%。
- 使用 “降低…” 结构：通过拆分bigkey，单次查询延迟从50ms降低至2ms。
- 使用 “支撑…” 结构：设计分片策略支撑日均10亿请求，集群规模从32节点平滑扩展至128节点。
- 使用 “减少/避免…” 结构：引入布隆过滤器，避免缓存穿透，数据库负载减少70%。
五、面试高频问答
面试问题
请描述你如何估算一个业务模块未来半年的缓存容量需求？
面试官考察点
- 是否具备容量规划的系统思维（数据收集、增长率模型、冗余策略）
- 能否将业务指标转化为技术参数（QPS→内存占用→分片数）
- 对业务发展趋势的敏感度和风险意识
回答框架
STEP 1：收集当前数据（QPS、Key数量、平均Value大小、命中率）
STEP 2：分析业务增长趋势（月增长率、大促因子）
STEP 3：计算峰值内存 = QPS × (1-命中率) × Value大小 × 安全系数（1.5~2）
STEP 4：转换为分片数和实例规格，给出扩容建议。
简短示例回答
以订单缓存为例，当前QPS 2万，Key 5000万，Value 200B，命中率92%。月增长8%，按半年后峰值估算：QPS 3.4万，需内存约120GB。建议保持30%余量，配置6台32GB实例或采用分片方案。
可能追问
- 如果业务增长超出预期，你有何快速扩容预案？
- 如何考虑Key的过期时间对内存的影响？
- 你们团队是如何验证容量预估准确性的？
面试问题
Redis集群中出现了大量bigkey，你会如何发现并处理？
面试官考察点
- 对bigkey危害的认知（阻塞、内存不均、迁移耗时）
- 发现手段（slowlog、bigkeys扫描、rdb分析）
- 优化方案（拆分、压缩、替换数据结构）
回答框架
发现：使用 redis-cli --bigkeys 扫描，或分析RDB文件定位大Key。
治理：根据业务场景拆分为多个小Key（如Hash分片），或对value做压缩/序列化优化。
预防：规范业务写入，设置value大小上限告警。
简短示例回答
通过--bigkeys发现一个Hash有200万字段，导致集群分片不均匀。我们将该Hash按用户ID取模拆成100个Hash，每个字段控制在1万以内。拆分后QPS上升，延迟从200ms降至5ms。
可能追问
- 如果bigkey不能拆分（如业务强依赖整个集合），有什么替代方案？
- 拆分后如何保证事务一致性？
- 扫描bigkey对线上性能有无影响？如何降低影响？
--sleep 参数或从节点扫描。另外注意大集合的del操作会阻塞，应使用异步删除（unlink）。
面试问题
如果缓存命中率突然从95%下降到50%，你如何排查？
面试官考察点
- 故障排查的逻辑性和系统性
- 对缓存失效原因的理解（批量过期、代码变更、数据倾斜）
- 监控体系和工具使用能力
回答框架
1. 确认时间窗口：检查监控看命中率下降起始时间。
2. 关联业务变更：同期是否有代码发布、Key过期策略修改、缓存雪崩。
3. 分析缓存键分布：检查是否有大量Key同时过期（如未加随机过期时间）。
4. 数据库负载变化：如果DB压力骤增，进一步确认是穿透还是冷启动。
简短示例回答
通过Grafana发现命中率在10:05骤降，同期有批量数据刷新任务。检查发现该任务设置Key过期时间为统一的1小时，导致整点雪崩。调整为“基础时间+随机偏移”后命中率恢复至94%。
可能追问
- 如何区分缓存穿透和缓存雪崩？分别如何处理？
- 你提到的“随机偏移”具体怎么实现？
- 如果业务不能接受缓存重建的等待时间，你会用哪些手段？（互斥锁、双缓存）
expire = base + random(0, TTL/2)）。同时需考虑分布式锁的性能损耗，高并发场景谨慎使用。