📚 课程目录第4章在线存储与低延迟服务高频问题

4. 在线存储与低延迟服务高频问题

Feature Store 的在线层，是面试官判断你“能不能扛住真实流量”的核心战场。离线链路可以容忍小时级延迟，但在线服务通常要求 P99 控制在 10ms 到 50ms 之间，还要面对高并发、热点键、特征回填、模型实时推理等多重压力。本章围绕 Redis、HBase、DynamoDB 的选型逻辑、缓存策略、P99 延迟优化，以及面试回答框架展开，帮助你把“用过”讲成“设计过、权衡过、优化过”。

本章核心问题：当面试官问“你们在线特征存储为什么选 Redis 而不是 HBase”时，他真正想听的不是产品对比，而是你的约束识别能力、权衡路径和量化结果。

一、核心原理：三种在线存储的定位差异

Redis 是内存型键值存储，优势是亚毫秒级点查、丰富数据结构和原子操作，适合特征维度少、QPS 极高、可接受内存成本的场景。HBase 基于 HDFS，擅长海量稀疏数据的随机读写，单行点查可控制在毫秒级，但受 RegionServer 热点和 Compaction 影响，P99 容易抖动。DynamoDB 是全托管 NoSQL，自动分区和弹性扩缩容，适合全球化部署和运维人力有限的团队，但按 RCU/WCU 计费，成本模型需要精细估算。

面试中不要孤立比较，而要绑定约束：特征规模、QPS、P99 目标、一致性要求、团队运维能力、预算。例如，用户侧实时特征通常选 Redis；物品侧宽表特征可能选 HBase；出海业务多区域低延迟则倾向 DynamoDB。

二、方法流程：选型与缓存策略的落地步骤

明确 SLA：写出 P99 目标、峰值 QPS、特征新鲜度、一致性级别。
拆解访问模式：点查、批量查、范围查、前缀扫描各占多少比例。
列出候选并压测：用真实特征分布和热点键做基准测试，记录 P50/P99/P999。
设计缓存策略：本地缓存 + Redis 集群 + 回源 HBase，设置 TTL、空值缓存、布隆过滤器。
建立监控与降级：监控命中率、回源率、大 key、热 key、连接池等待。

缓存策略要点：热点特征用本地缓存扛住瞬时峰值；空值缓存防止穿透；TTL 加随机抖动避免雪崩；批量接口用 pipeline 或 mget 降低 RTT。

三、案例场景：P99 从 80ms 降到 18ms

某推荐场景在线特征服务使用 Redis 集群，平均延迟 3ms，但 P99 高达 80ms。排查发现：部分热 key 集中在单个分片，导致该分片 CPU 打满；同时存在大 key（单 value 超过 1MB），网络传输和序列化耗时波动大。

优化前：
- 热 key 分片 CPU：95%
- 大 key 数量：1200+
- P99：80ms
- 缓存命中率：92%

优化动作：
1. 热 key 本地缓存 500ms，降低 Redis 压力
2. 大 key 拆分为多个小 key，按特征组存储
3. 使用 hash tag 打散分片，避免单分片过热
4. 开启连接池预热，减少建连抖动

优化后：
- 热 key 分片 CPU：55%
- P99：18ms
- 缓存命中率：97%

这个案例的面试价值在于：你能说清“平均延迟好不代表 P99 好”，并能定位到分片、大 key、连接池三个根因。

四、误区与复盘：面试中常见的失分点

误区	面试官视角	正确表达
只背产品特性	缺乏真实场景判断	先讲约束，再讲选型
忽略 P99 只谈平均	没有生产经验	给出 P99/P999 和毛刺定位
缓存策略只说 TTL	理解太浅	穿透、雪崩、热点、一致性全覆盖
不提成本与运维	缺乏工程权衡	对比内存成本、托管费用、人力投入
没有失败复盘	可信度低	讲一次故障和修复过程

高频追问：“Redis 挂了怎么办？”回答要包含降级到本地缓存、回源 HBase、限流熔断、以及特征缺失时的模型兜底策略。只答“加机器”会显得单薄。

五、公司侧重点与回答模板

大厂面试官通常按业务线区分侧重点：电商推荐关注热点 key 和实时性；广告系统关注高并发和成本；金融风控关注一致性和审计；云厂商关注多租户隔离和托管能力。回答时先判断对方业务，再调整案例权重。

推荐回答模板：“我们的约束是 P99 < 20ms、峰值 50 万 QPS、特征以点查为主。候选有 Redis 和 HBase。Redis 点查更快但内存成本高，HBase 成本低但 P99 抖动大。最终选择 Redis 集群 + 本地缓存，热 key 打散，空值缓存防穿透。上线后 P99 稳定在 15ms，命中率 97%。后来遇到一次分片热点，通过 hash tag 和本地缓存解决。”

把这段模板练熟，再根据面试官追问补充压测数据、监控指标和故障复盘，你就能在在线存储与低延迟服务这一高频模块中建立明显优势。