假设在双11大促期间，推荐系统需要处理百万级用户请求，如何设计高并发架构来保证低延迟和高可用？请说明负载均衡、缓存、消息队列等组件的应用。

1) 【一句话结论】
采用分层高并发架构，通过负载均衡分发请求、缓存加速热点数据、消息队列异步处理复杂任务，结合数据库集群保证数据高可用，实现低延迟和高可用。

2) 【原理/概念讲解】
老师口吻解释关键组件：

• 负载均衡：像交通指挥，把用户请求分到多个服务器，避免单个服务器过载。常用Nginx+LVS或HAProxy，算法有轮询（流量均等）、随机（随机分配）、加权（根据服务器性能分配权重）。
• 缓存：像超市的货架，把用户常访问的数据（如用户画像、商品信息）存到Redis等内存数据库，访问速度极快，减少对数据库的查询压力。需注意防止缓存击穿（热点数据全过期）和缓存雪崩（大量数据过期）。
• 消息队列：像快递中转站，把需要复杂计算的任务（如实时推荐）推入队列，由多个消费者异步处理，解耦业务层和计算层，实现削峰填谷。常用Kafka或RabbitMQ，需考虑消息丢失和顺序保证。

3) 【对比与适用场景】

组件	定义	特性	使用场景	注意点
负载均衡	分发请求到多个服务器，避免单点过载	高可用、负载均衡	请求分发（如用户请求到业务服务器）	选择算法（轮询、随机、加权），需考虑流量不均
缓存	存储热点数据，加速访问	快速访问、减少数据库压力	用户画像、商品信息、推荐结果	防止缓存击穿（预加载/互斥锁）、缓存雪崩
消息队列	异步通信，解耦系统	解耦、削峰填谷	复杂计算（推荐、日志）、任务调度	消息丢失（持久化）、顺序保证（需选顺序队列）

4) 【示例】
伪代码示例（用户请求：GET /recommend?userId=1001）：

• 负载均衡（Nginx）将请求分发到业务服务器（Server1）。
• 业务服务器先查询Redis缓存（key: user_profile_1001），若存在，直接返回数据。
• 若缓存不存在，查询MySQL数据库（用户画像表），获取数据后，更新Redis缓存（setex key, ttl, value）。
• 对于推荐计算（复杂，如调用大模型），将任务推入Kafka（topic: recommend_task），消费者（推荐服务）消费后，计算推荐结果，存入Redis（key: recommend_1001），并返回给用户。

5) 【面试口播版答案】
面试官您好，针对双11百万级用户请求，我会设计一个分层高并发架构。首先，接入层通过负载均衡（如Nginx+LVS）分发请求到多个业务服务器，避免单点过载。业务层处理请求时，优先查询Redis缓存（热点数据如用户画像、商品信息），减少数据库压力。对于需要复杂计算（如实时推荐）的请求，将计算任务推入Kafka消息队列，由消费者异步处理，结果存入缓存，实现解耦和削峰填谷。数据层用MySQL分库分表保证数据高可用，缓存集群（Redis集群）保证缓存高可用。整体通过负载均衡分发、缓存加速、消息队列异步处理，确保低延迟和高可用。

6) 【追问清单】

• 问题1：负载均衡的算法选择？
  回答要点：根据流量特性选算法，如流量不均用加权轮询，流量均衡用随机，热点请求用一致性哈希。
• 问题2：缓存如何解决缓存击穿问题？
  回答要点：设置热点数据预加载（预热），或用互斥锁（分布式锁）保证同一时间只有一个请求查询数据库并更新缓存。
• 问题3：消息队列如何保证消息不丢失？
  回答要点：持久化存储（Kafka的日志持久化），事务机制（生产者确认、消费者确认），以及重试机制。
• 问题4：数据库如何分库分表？
  回答要点：按用户ID哈希分库，按时间分表（如按月分表），避免热点表。
• 问题5：如何监控和调优？
  回答要点：监控负载均衡的请求分发率、缓存命中率、消息队列的延迟和堆积，通过日志和指标调整参数（如缓存TTL、队列消费者数量）。

7) 【常见坑/雷区】

• 坑1：忽略缓存雪崩，只考虑缓存击穿，导致大量请求同时查询数据库，引发雪崩。
• 坑2：消息队列选择同步队列，导致业务层阻塞，无法处理请求，影响延迟。
• 坑3：负载均衡算法选错，比如在流量不均时用轮询，导致某些服务器负载过高，而其他服务器空闲。
• 坑4：未考虑数据一致性，比如缓存和数据库数据不同步，导致用户看到过时推荐。
• 坑5：未设计容灾方案，比如消息队列单点故障，导致任务丢失，影响推荐结果。