在之前的项目中，遇到过投放系统因高并发导致的性能瓶颈，你是如何分析和解决的？请详细说明技术方案和实施过程。

1) 【一句话结论】：通过分阶段分析（压力测试定位瓶颈→数据库/缓存/代码逻辑优化→异步处理+限流降级），最终通过多维度优化（数据库索引、缓存预热、异步任务、限流策略）解决了高并发下的性能问题，系统QPS从1万提升至2万，响应时间从500ms降至100ms以内。

2) 【原理/概念讲解】：高并发性能瓶颈通常源于“资源竞争”或“处理逻辑瓶颈”。以数据库为例，高并发下大量请求同时查询同一数据，会导致锁竞争、全表扫描，像交通枢纽的车辆拥堵，导致整体效率下降。缓存的作用是“预存热点数据”，减少对数据库的访问，像仓库提前备货，降低生产线的压力。异步处理则是将耗时操作从请求路径中剥离，通过消息队列解耦，提高系统吞吐量，类似流水线作业，避免单点阻塞。

3) 【对比与适用场景】：以“数据库优化”与“缓存优化”为例，对比如下：

方向	定义	特性	使用场景	注意点
数据库优化	通过SQL优化、索引、分库分表等手段提升数据库读写性能	直接作用于数据存储层，解决数据查询/写入瓶颈	数据库是核心存储，高并发下查询/写入慢（如慢查询、锁等待）	需要业务理解，避免过度索引导致存储膨胀
缓存优化	使用Redis等缓存组件，将热点数据存入内存，减少数据库访问	响应快（毫秒级），显著降低数据库负载	读多写少场景（如投放系统查询用户/广告信息），或热点数据频繁访问	需考虑缓存击穿（热点数据失效）、雪崩（大量缓存失效）

4) 【示例】：假设投放请求需查询用户信息、广告数据并计算投放逻辑，高并发时数据库查询慢。优化步骤及伪代码：

• 数据库优化：为users表（字段：user_id, ad_id, status）和ads表（字段：ad_id, config）添加联合索引（user_id, ad_id、ad_id），减少全表扫描。
• 缓存优化：用Redis缓存用户信息（user:userId）和广告配置（ad:adId），设置过期时间（如5分钟），减少数据库查询。
• 异步处理：对于复杂计算（如投放规则计算），通过Kafka发送任务，消费者异步处理，结果存入数据库并更新Redis。
• 请求流程（优化后）：

  POST /api/submit?userId=1001&adId=2001&amount=10
  1. 检查Redis缓存（`user:1001`、`ad:2001`），若存在则直接返回。  
  2. 若缓存不存在，查询数据库（带索引的SQL），结果存入Redis（带过期时间）。  
  3. 发送Kafka消息（`topic:投放计算`，参数：用户/广告信息），消费者处理计算后，更新数据库和Redis。  
  4. 返回结果（从Redis获取计算结果）。  
  

5) 【面试口播版答案】：之前项目中，投放系统在高并发下（秒级QPS过万）出现响应超时，我通过压力测试定位到数据库查询慢（慢查询日志显示某SQL耗时100ms）。解决思路分三步：1. 数据库优化：为用户表和广告表添加联合索引，减少全表扫描；2. 缓存优化：用Redis缓存热点数据（用户信息、广告配置），设置过期时间，减少数据库压力；3. 异步处理：对于计算逻辑复杂的投放规则，通过Kafka异步处理，避免阻塞请求。实施后，系统QPS提升至2万，响应时间从500ms降至100ms以内。

6) 【追问清单】：

• 问题1：异步处理中，若消息队列延迟，会不会影响投放结果？
  回答：通过设置消息重试和死信队列，确保数据最终一致性，延迟控制在秒级内，不影响核心投放逻辑。
• 问题2：限流和降级策略是如何设计的？
  回答：使用Nginx的限流模块，设置QPS阈值（如1万），当超过时返回429，同时降级缓存默认值，保证核心功能可用。
• 问题3：分库分表是否考虑过？
  回答：当时业务量未达到分库分表阈值，用缓存+索引优化即可，若后续增长，会评估分库分表方案。
• 问题4：缓存击穿如何应对？
  回答：使用布隆过滤器预判缓存不存在的情况，避免大量请求冲击数据库。
• 问题5：线程池配置是否调整过？
  回答：根据请求量调整线程池大小（如核心线程数=CPU核心数×2，最大线程数=核心线程数×2），避免线程池爆满导致OOM。

7) 【常见坑/雷区】：

• 坑1：只说优化了数据库，未提缓存或异步，显得方案不全面。
• 坑2：优化措施无具体细节（如只说“加索引”，未说明具体索引字段），显得不专业。
• 坑3：忽略限流降级，导致系统在极端情况下崩溃。
• 坑4：未说明优化前后的性能对比，无法证明方案有效性。
• 坑5：分库分表等方案未结合业务场景，盲目引入导致复杂度增加。