假设广告投放系统在双十一等大促期间，请求量激增（如每秒百万级），请设计系统架构以应对高并发，并说明如何保证低延迟和高可用。

1) 【一句话结论】针对双十一百万级请求量，采用“负载均衡+分布式缓存+异步处理+数据库分片+熔断降级”的组合架构，通过水平扩展、请求削峰、数据分片等手段，确保系统高并发下的低延迟和高可用。

2) 【原理/概念讲解】当请求量激增时，单机处理能力不足，需通过水平扩展（增加后端服务实例）和负载均衡（如Nginx）分发请求。分布式缓存（如Redis）用于缓存热点数据（如广告内容、用户信息），减少数据库压力，降低响应延迟。异步处理（如消息队列Kafka）将非实时任务（日志记录、数据分析）从请求路径中剥离，提升实时响应速度。数据库分片（如ShardingSphere）将数据水平切分到多个数据库实例，提高查询和写入性能。熔断降级（如Hystrix）防止故障扩散，保障核心功能可用。
类比：双十一抢购，用多个收银台（水平扩展）分摊压力，用缓存（预存商品信息）快速响应，用消息队列（处理订单通知）异步处理，避免排队时间过长。

3) 【对比与适用场景】

组件/策略	定义	特性	使用场景	注意点
负载均衡器（Nginx）	分发请求到后端多实例	轮询、权重、健康检查	高并发请求分发	需配置健康检查，避免挂服务被调用
分布式缓存（Redis）	分布式存储热点数据	高速读写、持久化	缓存广告数据、用户信息	需考虑缓存击穿、雪崩、过期问题
消息队列（Kafka）	异步处理非实时任务	高吞吐、持久化	日志记录、数据分析、通知	需消费者处理延迟，避免数据积压
数据库分片（ShardingSphere）	数据水平切分到多实例	提高查询/写入性能	广告数据、用户数据	跨分片查询复杂，需额外中间件

4) 【示例】
请求示例：用户请求广告展示，系统处理流程：

• 负载均衡器（Nginx）将请求分发到后端服务实例。
• 后端服务检查Redis缓存（如key: ad_123_456），命中则直接返回广告内容。
• 若缓存未命中，查询数据库（分片1），结果写入缓存（TTL 3600秒）。
• 异步处理：将请求日志写入Kafka主题“ad_logs”，由消费者处理，不阻塞前端响应。

伪代码（后端服务逻辑）：

def get_ad(request):
    key = f"ad_{request.user_id}_{request.campaign_id}"
    ad = redis.get(key)
    if ad:
        return json.loads(ad)
    ad = db.query("SELECT * FROM ads WHERE user_id=? AND campaign_id=?", request.user_id, request.campaign_id)
    if ad:
        redis.set(key, json.dumps(ad), ex=3600)
    return ad

5) 【面试口播版答案】
面试官您好，针对双十一百万级请求量，我设计的系统架构核心是通过负载均衡+分布式缓存+异步处理+数据库分片+熔断降级的组合，保证低延迟和高可用。首先，前端请求由负载均衡器（如Nginx）分发到多个后端服务实例，实现请求分流。后端服务首先查询分布式缓存（如Redis），缓存命中则直接返回广告，避免数据库压力。若缓存未命中，则查询数据库（通过分片技术，将广告数据分到多个数据库实例），并将结果写入缓存，同时可能将非关键操作（如日志、数据分析）通过消息队列（如Kafka）异步处理，减少实时响应时间。此外，引入熔断降级机制（如Hystrix），当某个服务响应超时或错误率超过阈值时，自动降级，防止级联故障。最后，通过监控和自动扩容（如K8s的HPA），根据请求量动态调整实例数量，保证系统弹性。这样，既能应对高并发，又能保证低延迟和高可用。

6) 【追问清单】

• 问题1：如何处理缓存击穿问题？
  回答要点：通过设置热点数据预加载（如预热缓存），或使用互斥锁（如Redis的SETNX）保证同一时间只有一个实例加载数据并缓存，避免大量请求同时击穿缓存。
• 问题2：数据库分片的具体方案？
  回答要点：采用水平分片（如按用户ID或广告ID哈希分片），将数据分散到多个数据库实例，提高查询和写入性能；同时使用中间件（如ShardingSphere）管理分片路由，简化开发。
• 问题3：异步处理的消息队列选择？
  回答要点：选择高吞吐、持久化的消息队列，如Kafka，用于处理日志、数据分析等非实时任务，避免阻塞前端请求；同时配置消息确认机制（如ACK），确保数据不丢失。
• 问题4：熔断降级的阈值如何设定？
  回答要点：根据服务响应时间（如超过200ms视为超时）、错误率（如超过50%错误视为故障），动态调整阈值；例如，当服务响应时间超过200ms或错误率超过50%时，触发熔断，返回降级提示（如“广告加载中”）。
• 问题5：系统监控和告警机制？
  回答要点：通过Prometheus监控请求量、响应时间、错误率等指标；结合Grafana可视化，当指标超过阈值时，通过Alertmanager发送告警（如邮件、短信），及时处理故障。

7) 【常见坑/雷区】

• 坑1：只考虑缓存，忽略缓存雪崩。
  雷区：所有缓存同时过期，导致大量请求击穿数据库，引发雪崩效应，需设置缓存过期时间随机化（如±10%）。
• 坑2：数据库分片导致跨分片查询复杂。
  雷区：未考虑业务场景，如广告投放需要跨分片查询用户数据，导致查询逻辑复杂，需设计合理的分片键或使用中间件简化。
• 坑3：异步处理导致数据不一致。
  雷区：消息队列消费者延迟处理，导致数据积压，影响系统稳定性，需设置消息堆积上限，并监控消费者延迟。
• 坑4：负载均衡器选择不当。
  雷区：使用轮询负载均衡，导致新实例未充分预热，或健康检查不严格，挂服务被调用，需选择更智能的负载均衡策略（如加权轮询、最小连接数）。
• 坑5：忽略网络延迟或硬件瓶颈。
  雷区：未考虑网络带宽、服务器CPU/内存限制，导致系统在高并发下性能下降，需进行压力测试，优化网络和硬件配置。