设计一个高并发的广告投放系统，请描述其核心模块设计，包括请求路由、缓存、数据库、容错等关键点，并说明各模块如何协同工作以支撑高并发场景下的广告请求处理。

1) 【一句话结论】：高并发广告投放系统需通过请求路由（负载均衡+去重）、缓存（加速+雪崩防护）、数据库（读写分离+分库分表）、容错（熔断降级+重试）等核心模块协同，实现低延迟、高可用，支撑海量广告请求的快速处理与稳定运行。

2) 【原理/概念讲解】：

• 请求路由（负载均衡）：负责将用户请求分发到后端处理节点。核心是负载均衡算法，如轮询（简单易实现，按顺序分发）、加权轮询（考虑节点性能，性能高的节点处理更多请求）、一致性哈希（节点增减时数据迁移少，适合动态扩容）。需结合健康检查（如心跳检测），确保只分发到健康节点。
• 请求去重：避免用户重复请求导致资源浪费。常用Redis布隆过滤器（快速判断请求是否已处理），或分布式ID生成器（如Snowflake，结合请求ID生成唯一标识）。
• 缓存：存储高频广告数据（如广告位信息、用户画像、广告素材）。采用Redis，支持高并发读写。需考虑缓存雪崩（全量失效），通过设置随机TTL、分片缓存、预加载热数据解决。
• 数据库：存储核心广告数据（广告主、素材、策略）。采用读写分离（主库写，从库读，分担读压力），分库分表（分库：按广告位ID哈希分库，避免单广告位数据集中；分表：按时间维度分表，如按天分表，减少单表数据量，优化查询性能）。优化索引（如广告位ID+用户ID联合索引，加速用户广告位匹配）。
• 容错：应对系统故障。熔断（当后端服务超时率超过阈值，直接返回失败，避免级联故障）；降级（非核心功能延迟或关闭，如统计上报）；重试（对非关键请求，如素材加载失败，采用指数退避策略重试，避免雪崩）。

3) 【对比与适用场景】：

• 负载均衡算法对比

  算法	定义	优势	劣势	适用场景
  轮询	按顺序分发请求到节点	简单易实现	节点负载不均（如节点性能差异）	节点数量少，负载均衡要求不高
  加权轮询	根据节点性能/权重分发	考虑节点负载，性能高的节点处理更多请求	权重计算复杂	节点性能差异大，需按能力分配负载
  一致性哈希	节点ID和请求ID哈希后取模	节点增减时数据迁移少（仅影响相邻节点），负载更均匀	需维护虚拟节点，实现复杂	节点动态扩容频繁，需低迁移成本

• 缓存淘汰策略对比

  策略	定义	优势	劣势	适用场景
  LRU（最近最少使用）	移除最近最少访问的缓存项	自动淘汰不常用数据，保留热点数据	可能误淘汰高频数据（如热门广告位）	广告位信息、用户画像（访问频率低，需淘汰旧数据）
  TTL（生存时间）	设置缓存项过期时间	定时自动删除，避免数据过时	需合理设置TTL（过短导致频繁更新，过长导致数据过时）	广告素材、投放策略（数据变化慢，定期更新）

4) 【示例】（广告请求处理流程伪代码）：

用户广告请求 → 请求路由（Nginx）分发到后端服务  
后端服务检查请求去重（Redis布隆过滤器）：  
    若布隆过滤器判断已处理，直接返回失败（避免重复投放）  
    否则，生成唯一请求ID（如Snowflake），存入布隆过滤器（标记为已处理）  
后端服务检查缓存（Redis）：  
    key = "ad_position:#{ad_position_id}"  
    若存在，直接返回广告内容  
    否则，查询数据库（读库，读写分离）：  
        SELECT * FROM ad_position WHERE id = ?  
数据库返回广告位信息后，存入缓存（SET key value EX 3600，随机TTL）  
返回广告内容给用户  
（容错处理：若数据库查询超时，熔断直接返回失败；若缓存雪崩，通过令牌桶限流控制请求速率）  

5) 【面试口播版答案】：
“面试官您好，设计高并发广告投放系统，核心是通过请求路由、缓存、数据库、容错等模块协同，实现低延迟和高可用。首先，请求路由用Nginx做负载均衡，结合一致性哈希算法，确保节点增减时数据迁移少，同时通过健康检查只分发到健康节点。然后，请求去重用Redis布隆过滤器，快速判断用户请求是否已处理，避免重复投放。缓存用Redis存储广告位信息，设置随机TTL防止雪崩，数据更新后异步刷新。数据库采用读写分离，读库分担读压力，按广告位ID哈希分库，按天分表优化查询。容错方面，熔断机制当后端服务超时率超过50%时直接返回失败，降级非核心功能，重试失败请求时用指数退避避免雪崩。各模块协同：用户请求先路由，再检查去重，缓存命中直接返回；未命中则读数据库，数据存入缓存后返回。这样能支撑高并发，保证响应速度和系统稳定性。”

6) 【追问清单】：

• 问：请求去重具体是如何实现的？比如布隆过滤器的误判率如何控制？
  回答要点：布隆过滤器误判率可通过调整位数组和哈希函数数量控制，通常误判率低于1%，适合高并发去重场景。
• 问：负载均衡中一致性哈希和轮询的优劣对比，为什么选择一致性哈希？
  回答要点：一致性哈希在节点动态扩容时数据迁移少（仅影响相邻节点），负载更均匀；轮询简单但节点增减时数据迁移量大，适合节点固定场景。
• 问：如何解决缓存雪崩问题？具体步骤是什么？
  回答要点：设置随机TTL（如TTL在300-3600秒内随机），分片缓存（将缓存数据分片存储到多个Redis实例），预加载热数据（提前加载热门广告数据到缓存）。
• 问：数据库分库分表的具体策略，比如按广告位分库的依据？
  回答要点：按广告位ID哈希分库，每个广告位的数据分散到不同库，避免单广告位数据集中导致查询慢；按时间维度（如按天）分表，减少单表数据量，优化索引查询。
• 问：熔断的阈值如何动态调整？
  回答要点：根据业务指标（如超时率、错误率）动态调整，例如当超时率超过50%或错误率超过20%时触发熔断，阈值可配置为动态阈值。

7) 【常见坑/雷区】：

• 忽略请求去重：未考虑用户重复请求导致资源浪费或计算错误，影响系统正确性。
• 数据库单点：未做读写分离或分库分表，高并发下数据库压力过大，导致系统崩溃。
• 缓存雪崩未防护：缓存全量失效时，数据库压力激增，导致系统不可用。
• 容错机制简单：熔断阈值固定，未动态调整，或重试策略不当导致雪崩。
• 缓存与数据库数据不一致：未采用异步更新或版本号机制，导致数据不一致。