描述之前项目中遇到的一个技术挑战（如系统高并发下的性能问题），你是如何分析、定位和解决的？涉及问题复现、根因分析、解决方案和验证过程。

1) 【一句话结论】在之前的项目中，我们通过压测复现、链路分析定位到高并发下数据库查询成为瓶颈，通过加索引+引入Redis缓存优化，成功将响应时间从2秒降至0.2秒，系统吞吐量提升5倍。

2) 【原理/概念讲解】老师会解释高并发性能问题的核心是资源竞争导致的链路瓶颈。当并发请求超过系统处理能力时，请求队列积压，导致延迟爆炸。类比：就像高峰期交通，车辆太多导致拥堵，排队时间变长。关键步骤是分析请求处理链路，找出最耗时的环节（瓶颈）。例如，系统处理流程通常包含“请求接收→缓存检查→数据库查询→返回结果”，若数据库查询耗时占比超50%，则它是瓶颈。

3) 【对比与适用场景】

方法	定义	特性	使用场景	注意点
缓存优化	将热点数据存入内存，减少数据库访问	响应快，但需考虑缓存击穿、雪崩	数据不常变（如商品信息），访问频繁	需设置过期策略，避免数据不一致
数据库优化	优化SQL、索引、分库分表	直接处理数据，但可能慢	数据量小，访问模式简单	需分析查询复杂度，避免全表扫描

4) 【示例】
假设项目是电商商品详情页，高并发时（如秒杀），请求量激增导致数据库查询变慢。伪代码示例：
请求示例（高并发时）：

GET /product/123

系统处理流程：1. 检查缓存（无）；2. 查询数据库（慢，因锁竞争）；3. 返回数据。

5) 【面试口播版答案】
在之前的项目中，我们遇到了系统在高并发场景下响应延迟急剧上升的挑战。具体来说，在模拟的秒杀活动中，并发请求达到1万QPS时，用户请求平均响应时间从正常的0.5秒飙升至2秒以上，系统开始出现超时和错误。首先，我们通过压测工具（如JMeter）复现问题，确认是真实场景下的表现。接着，用链路追踪工具（如Pinpoint）分析请求处理链路，发现所有请求的数据库查询耗时占比超过60%，且SQL语句是“SELECT * FROM goods WHERE id = ?”，没有使用索引。根因分析后，确定是数据库查询成为瓶颈，因为高并发下锁竞争导致查询变慢。解决方案是：1. 为商品ID字段添加索引；2. 引入Redis缓存，缓存商品信息，设置过期时间（如5分钟）。验证过程：再次压测，1万QPS下，响应时间降至0.2秒，错误率降为0，系统吞吐量提升5倍。最终解决了高并发下的性能问题。

6) 【追问清单】

• 问：为什么选择用缓存而不是其他方案？答：因为商品信息变化频率低（每天更新几次），而访问频率高，缓存能显著减少数据库压力，且实现简单。
• 问：有没有考虑过分库分表？答：当时数据量约10万条，分库分表成本高，且查询复杂度低，缓存优化更直接有效。
• 问：缓存击穿或雪崩的应对措施？答：设置了热点数据预热（启动时加载热门商品到缓存），并使用互斥锁解决缓存击穿问题。
• 问：是否影响其他功能？答：优化后，其他功能（如订单查询）未受影响，因为缓存是针对商品详情页的独立模块。

7) 【常见坑/雷区】

• 只描述问题现象，不说明复现过程，显得分析不深入。
• 解决方案不具体，比如只说“优化数据库”，没说具体优化措施（如加索引、改SQL）。
• 忽略验证过程，没说明如何确认问题解决，显得效果不明确。
• 忽视成本或风险，比如没考虑缓存数据不一致的问题，或优化后的系统资源消耗。
• 概念混淆，比如把缓存和CDN混淆，或者锁优化和并发控制搞错。