在之前的项目中，你遇到一个高并发场景（如秒杀活动），导致系统响应延迟或崩溃。请描述你如何定位问题（如通过监控指标、日志分析），并采取的优化措施（如缓存、数据库优化、架构调整）。
答案
1) 【一句话结论】
在秒杀高并发场景中，通过监控定位到数据库慢查询是核心瓶颈，通过分布式缓存（解决缓存穿透）、数据库索引与分库分表（提升读写性能）、消息队列异步处理（解耦请求与库存扣减）、限流策略（控制流量）的组合优化，将P99响应时间从2秒降至50ms，系统错误率从5%降至0.1%。
2) 【原理/概念讲解】
老师：“高并发场景下系统易出现‘请求风暴’——大量请求瞬间涌入，导致资源（如数据库、缓存）争抢，响应延迟或服务崩溃。定位问题需从监控指标（如QPS、P99/P95响应时间、错误率、数据库慢查询数）和日志分析（慢日志、错误日志）入手。优化措施需针对瓶颈：若瓶颈在数据库，可优化索引、分库分表；若在缓存，需解决穿透/雪崩/击穿；若整体压力过大，需架构调整（如微服务拆分、消息队列异步处理）。类比：就像交通拥堵，先看哪个路口（监控指标）堵得最严重（数据库慢查询），再修路（优化）或分流（架构调整）。”
3) 【对比与适用场景】
| 缓存问题 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 缓存穿透 | 请求不存在的数据，查询数据库无结果，未缓存 | 请求直接到数据库，无缓存命中 | 高并发下查询不存在的数据（如恶意攻击） | 设置空值缓存（如Redis SETNX key "" 10，过期10秒） |
| 缓存击穿 | 高频热点数据缓存过期，大量请求同时查询 | 请求瞬间集中到数据库 | 高频访问的缓存数据 | 设置TTL+互斥锁（如Redis SET key value EX 60 NX，加锁防止并发过期） |
| 缓存雪崩 | 大量缓存同时过期，请求全部到数据库 | 数据库瞬间压力激增 | 缓存统一过期时间 | 分散过期时间（如TTL+10%随机偏移，避免同时过期） |
4) 【示例】
秒杀库存扣减流程（优化前 vs 优化后）：
- 优化前流程：
- 检查缓存（
redis.get(skuId)）→ 无 - 查数据库库存（
select stock from product where id=123）→ 10 - 扣库存（
update product set stock=9 where id=123）→ 成功 - 返回结果
- 检查缓存（
- 优化后流程：
- 检查缓存（
redis.get(skuId)）→ 有（库存10） - 直接返回
- 扣库存（同上）
- 更新缓存（
redis.set(skuId, 9)，TTL=60s+10%随机偏移）
- 检查缓存（
- 数据库优化：为
stock字段加B树索引（CREATE INDEX idx_stock ON product(stock)），分库分表（按SKU分区，如product_sku表分区键为sku_id）。 - 消息队列异步处理：请求发送至Kafka，消费者线程处理扣库存，消息格式为
{"skuId":123, "stock":10}，失败重试3次后记录错误。 - 限流策略：入口层设置令牌桶（令牌生成速率1000/s，桶大小1000），超过则返回429错误。
5) 【面试口播版答案】
“在之前的项目中，我们遇到了秒杀活动的秒级高并发场景，系统响应延迟严重甚至崩溃。首先，通过监控发现P99响应时间从2秒飙升至5秒，错误率从0.1%升至5%，定位到数据库慢查询占比超80%。接着通过日志分析，发现大量请求命中了未缓存的库存查询。优化措施上，我们引入Redis分布式缓存解决缓存穿透（设置空值缓存，命令SETNX key "" 10，过期10秒），针对高频SKU分散缓存过期时间（TTL+10%随机偏移），同时为数据库stock字段加索引并分库分表（按SKU分区）。此外，架构上通过Kafka消息队列解耦请求和库存扣减，实现异步处理，并设置令牌桶限流（每秒1000个令牌，桶大小1000），防止请求过载。最终，P99响应时间降至50ms以内，系统错误率从5%降至0.1%。”
6) 【追问清单】
- 问：监控指标具体选了哪些？
答：主要监控QPS（每秒请求数）、P99/P95响应时间、错误率（4xx/5xx）、数据库慢查询数（>100ms）。 - 问：优化措施的优先级如何排序？
答：先解决缓存问题（穿透/雪崩/击穿），再优化数据库（索引/分库分表），最后架构调整（解耦/限流）。 - 问：消息队列如何处理失败重试？
答：消费者消费失败后，将消息重新入队，设置重试次数（如3次），超过则记录错误。 - 问：限流策略的参数如何设置？
答：令牌桶的令牌生成速率设为每秒1000个，桶大小1000，超过则拒绝请求。 - 问：分库分表后数据同步成本如何处理？
答：通过数据库同步工具（如CDC）实时同步，确保数据一致性。
7) 【常见坑/雷区】
- 坑1：只说“用了缓存优化”，未具体说明是哪种问题（穿透/雪崩/击穿）及应对措施。
- 坑2：只说“数据库优化”，未提及具体手段（如索引、分库分表）或效果（如性能提升多少）。
- 坑3：架构调整不具体，比如说“拆分服务”，未说明拆分的逻辑（如按业务模块拆分）或带来的好处（如解耦）。
- 坑4：未提及监控指标的具体变化，比如只说“监控发现慢”，未说“P99响应时间从2秒降到0.5秒”。
- 坑5：未考虑限流或降级，比如高并发时直接压垮系统，未采取流量控制措施。