电商大促期间（如双11），AI推荐模型需要处理海量请求，如何设计部署架构，保证低延迟和高可用？考虑负载均衡、缓存、容错机制。请说明架构设计及关键技术选型。

淘天集团AI Infra难度：中等

答案

1) 【一句话结论】采用分层微服务架构+多级缓存+动态弹性扩缩容+多副本容错+智能负载均衡的混合方案，通过服务网格实现流量治理，确保大促期间低延迟和高可用。

2) 【原理/概念讲解】老师会这样解释：

分层微服务拆分：将推荐模型拆成“特征计算（处理用户行为数据，如点击、购买记录）”“模型推理（调用AI模型，如推荐排序算法）”“结果聚合（整合多模型结果，如综合排序）”，每个服务独立部署，降低单点故障影响（类比：把大模型拆成多个轻量级服务，一个模块坏掉不影响整体）。
多级缓存：分三层设计——
- CDN缓存静态资源（如推荐页面的图片、页面模板），响应时间低（类比：CDN是离用户最近的缓存，像快递站，用户直接从附近拿，不用等总部发货）；
- Redis缓存热点特征（如用户常访问的商品特征，如“手机”类商品的特征）和模型结果（如热门商品的推荐排序），缓存热点数据，减少对后端服务的压力（类比：Redis是中间缓存，像仓库，存放常用商品，用户要的话直接拿，不用去工厂）；
- 本地缓存（模型服务进程内缓存），提升冷启动速度（第一次请求时，本地缓存快速返回，后续请求直接命中，类比：本地缓存是服务内部的“小仓库”，第一次请求时先去小仓库拿，没的话再去大仓库）。
动态弹性扩缩容：基于请求量（QPS）自动调整服务实例数，比如用Kubernetes的Horizontal Pod Autoscaler（HPA），当QPS超过阈值（如1000 QPS）时，自动增加模型推理服务的Pod数量（类比：像自动调节空调，热的时候开多台，冷的时候关几台）；当QPS下降时，自动缩减实例，节省成本。
多副本容错：每个服务部署3 - 5个副本，通过Liveness/Readiness probes（健康检查）检测故障（Liveness检查服务是否存活，Readiness检查服务是否可接收请求），若实例故障，自动替换为健康实例（比如模型推理服务实例宕机，Kubernetes会自动启动新实例，Istio会自动将流量切换到新实例）（类比：像公交车的备用车辆，一辆坏了，另一辆马上顶上，保证服务不中断）。
智能负载均衡：Nginx做四层负载均衡（分发用户请求到不同Nginx实例），LVS做七层负载均衡（根据请求内容路由到对应服务），服务网格（Istio）实现智能流量治理（如熔断、降级），根据服务健康状态动态调整流量（比如模型推理服务负载过高时，Istio会分流到其他健康实例）（类比：Nginx是“分发员”，LVS是“调度员”，Istio是“智能调度员”，能根据情况调整分配）。

3) 【对比与适用场景】

方案	定义	特性	使用场景	注意点
Nginx	四层负载均衡器	高性能，配置灵活，支持HTTP/HTTPS	前端请求分发，简单场景	需手动配置，扩展性一般
LVS	七层负载均衡器	高并发，支持多协议（TCP/UDP/HTTP）	大规模请求（如电商大促）	需内核支持，配置复杂
服务网格（Istio）	基于Sidecar的服务间通信	智能流量治理（熔断、降级、路由）	微服务架构，复杂流量控制	增加网络开销，需容器化

4) 【示例】
架构示例（文字描述）：
用户请求 → Nginx（四层负载均衡，分发到LVS实例）→ LVS（七层负载均衡，路由到对应微服务集群）→ 服务网格（Istio，智能流量治理）→ 微服务集群（特征计算、模型推理、结果聚合）。
请求流程：

用户请求先检查CDN缓存（静态资源），命中则返回；
若未命中，检查Redis缓存（热点特征/模型结果），命中则返回；
若未命中，查询本地缓存（模型服务进程内），命中则返回；
若未命中，调用模型服务（多副本，健康检查通过），返回结果后更新Redis+本地缓存。
容错：若模型服务实例故障，Istio自动切换到健康实例，并触发重试（最多3次）；若多次失败则降级（返回默认推荐结果，如热门商品列表）。
缓存雪崩应对：Redis设置随机过期时间（如随机+5分钟），避免集中过期；限流+熔断（如QPS超过5000时，熔断模型服务，返回默认结果）。
模型更新：采用热更新（Istio的Sidecar支持模型更新），先更新新版本服务，再逐步切换流量（蓝绿部署），避免服务中断。

5) 【面试口播版答案】
面试官您好，针对电商大促海量请求场景，我设计的架构核心是分层微服务+多级缓存+动态弹性扩缩容+多副本容错+智能负载均衡。首先，将推荐模型拆分为特征计算、模型推理、结果聚合三个微服务，降低单点影响。然后，采用三级缓存：CDN缓存静态资源，Redis缓存热点特征和模型结果，本地缓存提升冷启动速度。接着，通过Kubernetes的HPA实现动态扩缩容，当QPS超过1000时自动增加实例。容错方面，每个服务部署3-5个副本，用Liveness/Readiness probes检测故障，自动替换。负载均衡用Nginx+LVS+Istio，Nginx做四层分发，LVS做七层，Istio实现智能流量治理和熔断降级。这样能保证大促期间低延迟和高可用。

6) 【追问清单】

问题1：模型更新时如何保证服务不中断？
回答要点：采用热更新（如Istio的Sidecar支持模型更新），或蓝绿部署，先更新新版本服务，再逐步切换流量。
问题2：缓存雪崩如何处理？
回答要点：设置随机过期时间，限流+熔断，避免集中过期。
问题3：动态扩缩容的具体阈值如何设计？
回答要点：根据历史数据（如双11前一周的QPS峰值）和资源利用率（如CPU使用率超过80%）设定阈值（如QPS>1000或CPU>80%时扩容）。
问题4：容错机制中重试次数和降级策略如何设计？
回答要点：根据请求类型设置重试次数（如关键请求重试3次），降级时返回默认推荐结果或热门商品。
问题5：服务网格的Sidecar是否增加网络开销？
回答要点：虽然增加少量开销，但带来智能流量治理能力，适合复杂场景。

7) 【常见坑/雷区】

只说负载均衡不提缓存，导致延迟问题；
忽略动态扩缩容，导致资源不足或浪费；
容错机制不具体，只说多副本而不提故障检测和恢复；
缓存策略错误，比如没有考虑热点数据，导致缓存命中率低；
模型服务更新时未考虑兼容性，导致服务中断。