请分享一个你参与过的项目，其中遇到了高并发导致的系统性能问题，你是如何分析问题、定位瓶颈并解决的？请详细说明技术选型、优化措施以及效果。

1) 【一句话结论】在参与“电商订单查询系统”项目时，高并发下接口响应超时，通过压测定位到数据库查询瓶颈，采用缓存+分库分表+异步消息队列优化，性能提升5倍，系统稳定支持峰值流量。

2) 【原理/概念讲解】高并发性能问题的核心是“资源争抢”导致响应延迟。比如，当大量请求同时访问数据库时，数据库成为“瓶颈”（类似交通主干道），导致整个系统吞吐量下降。关键概念包括：

• 并发量：单位时间内的请求数量（如QPS）；
• 响应时间：单请求从发起到返回的总耗时（如100ms）；
• 吞吐量：单位时间处理的请求数量（如1000 QPS）。
  常见瓶颈类型：数据库I/O（最常见）、缓存失效、网络延迟、CPU计算。类比：城市交通，主干道（数据库）车流量大时，整个城市通行效率下降。

3) 【对比与适用场景】

优化手段	定义	特性	使用场景	注意点
缓存（如Redis）	存储热点数据，减少数据库访问	低延迟、高并发读写	热点数据查询（如商品列表、用户信息）	需处理缓存穿透（空数据）、击穿（热点key失效）、雪崩（大量key失效）
分库分表	水平/垂直分割数据库，分散数据	跨库查询复杂、数据一致性	数据量巨大（如百万级订单）	需处理分布式事务、跨库查询
异步处理（消息队列）	将请求放入队列，后台异步处理	解耦、削峰填谷	长耗时操作（如订单通知、数据同步）	需考虑消息丢失、延迟、死信队列

4) 【示例】
假设项目是“电商订单查询接口”，高并发场景（如618大促，每秒1万+请求）。初始问题：接口响应时间从100ms（正常）升至2s（超时）。分析：压测发现数据库查询（select * from orders where user_id=...）占90%耗时，SQL执行计划显示全表扫描。优化步骤：

1. 添加Redis缓存，缓存订单数据（key: order_{id}，value: 订单JSON）；
2. 分库分表，将订单表按user_id分库（如user_id%100=0->db0），按时间分表（如按年分表）；
3. 引入Kafka异步处理订单通知，将通知请求放入队列，后台消费者处理。
   效果：缓存命中后响应时间降至50ms，分库分表后数据库查询量减少90%，异步处理避免接口阻塞，系统支持峰值2万+QPS。

5) 【面试口播版答案】
各位面试官好，我分享的项目是“电商订单查询系统”。项目背景是618大促，系统需支持每秒1万+订单查询请求。遇到的问题是：高并发下接口响应超时，压测发现数据库查询占90%耗时。分析过程：通过JMeter模拟并发，定位到SQL全表扫描。解决措施：首先在Redis中缓存订单数据，缓存穿透用布隆过滤器+互斥锁；然后分库分表，按user_id分库、按时间分表；最后引入Kafka异步处理订单通知，避免接口阻塞。效果：响应时间从2s降至50ms，系统稳定支持峰值2万+QPS，性能提升5倍。

6) 【追问清单】

• 为什么选择Redis而不是Memcached？答：Redis支持数据持久化、更丰富的数据结构（如JSON），适合存储复杂订单数据。
• 分库分表后如何保证数据一致性？答：采用分布式事务（如Seata），或最终一致性（如补偿机制）。
• 异步处理的消息队列如何保证可靠性？答：Kafka的持久化机制+死信队列，确保消息不丢失。
• 缓存击穿如何处理？答：布隆过滤器过滤无效请求，互斥锁保证热点key只被一个线程写入。
• 有没有考虑其他优化方案？比如数据库读写分离？答：读写分离已实现，但主要瓶颈是热点数据查询，所以优先优化缓存和分库分表。

7) 【常见坑/雷区】

• 只说优化了，没量化效果（如“提升了性能”但没说“提升5倍”）；
• 没讲分析过程（如“定位到数据库慢”但没说“通过压测工具”）；
• 技术选型不匹配场景（如用Redis缓存但没提缓存穿透、雪崩的处理）；
• 忽略缓存与数据库的一致性问题（如缓存更新策略）；
• 没考虑异步处理的延迟问题（如消息队列延迟导致通知延迟）。