在之前项目中，如何优化一个高并发系统的性能，具体采取了哪些技术手段，效果如何？

1) 【一句话结论】针对高并发系统，通过架构解耦（拆分服务）、中间件优化（缓存、消息队列）、数据库优化（读写分离、分库分表）及网络优化（CDN、负载均衡），将系统QPS从1000提升至5000，响应时间从2秒降至0.5秒。

2) 【原理/概念讲解】高并发系统性能优化的核心是“瓶颈识别与资源解耦”。高并发场景下，系统性能瓶颈通常由单点资源（如数据库、API网关）或链路延迟导致，优化本质是通过技术手段分散压力、异步处理、缓存热点数据，从而提升系统整体吞吐量与资源利用率。比如，类似“交通拥堵时，通过分流（如多车道、公交专用道）缓解压力，高并发系统通过解耦服务、异步处理类似分流”。

3) 【对比与适用场景】

优化手段	定义	特性	使用场景	注意点
缓存	存储热点数据，减少数据库访问	高速存储，低延迟	热点数据查询（如商品列表、用户信息）	需要考虑缓存击穿、雪崩问题
异步处理	将请求异步提交，后续处理	解耦请求与响应，提升吞吐	长耗时操作（如订单支付、邮件发送）	需要消息队列保证可靠性
数据库优化	调整数据库架构（读写分离、分库分表）	分散数据库压力	高并发写操作（如秒杀库存扣减）	需要保证数据一致性

4) 【示例】
假设项目是“航空票务系统秒杀模块”，优化步骤：

• 缓存优化：将热门航线价格、用户信息等热点数据存入Redis，缓存查询时间从100ms降至1ms。
• 异步处理：订单扣减库存通过消息队列（Kafka）异步处理，避免阻塞主流程。
• 数据库优化：采用读写分离+分库分表，将库存表拆分到多库，单库QPS从500提升至2000。
• 网络优化：使用负载均衡（Nginx）分发请求，CDN加速静态资源。
  伪代码示例（缓存查询）：

def get_flight_price(flight_id):
    price = redis.get(flight_id)
    if not price:
        price = db.query(flight_price, flight_id)
        redis.setex(flight_id, 3600, price)  # 缓存1小时
    return price

5) 【面试口播版答案】
“在之前负责的航空票务系统秒杀项目中，系统在高并发场景下（如秒杀开始时QPS峰值1000+）响应缓慢。我首先通过压力测试定位到瓶颈：数据库查询占70%时间，且库存扣减操作阻塞主流程。随后采取以下优化措施：
第一，缓存热点数据，将热门航线价格、用户信息存入Redis，缓存命中率提升至90%，查询时间从1秒降至0.1秒；
第二，引入消息队列（Kafka）异步处理订单扣减，将库存扣减操作从同步改为异步，系统QPS提升至5000，响应时间从2秒降至0.5秒；
第三，数据库读写分离+分库分表，将库存表拆分到3个数据库实例，单库QPS从500提升至2000，避免单点数据库压力；
第四，使用负载均衡（Nginx）分发请求，CDN加速静态资源，网络延迟降低30%。
最终，系统在高并发下的QPS提升5倍，响应时间缩短75%，满足业务需求。”

6) 【追问清单】

• 问题1：具体优化步骤中，缓存策略是如何设计的？
  回答要点：采用Redis缓存，设置缓存过期时间（如1小时），并实现缓存穿透（空值缓存）和缓存雪崩（随机过期时间）防护。
• 问题2：效果数据是如何验证的？
  回答要点：通过JMeter压力测试，对比优化前后的QPS、响应时间、错误率等指标，并记录业务监控数据（如用户投诉率下降）。
• 问题3：是否考虑过其他方案，比如微服务拆分？
  回答要点：考虑过微服务拆分，但考虑到业务耦合度低且开发周期长，优先选择中间件优化（缓存、异步）和数据库优化，效果更直接。
• 问题4：异步处理中，消息队列的可靠性如何保障？
  回答要点：使用Kafka的持久化存储，设置消息重试机制，确保未成功处理的订单会重新入队处理。
• 问题5：优化过程中，是否评估了成本？
  回答要点：评估了Redis、Kafka等中间件的成本，通过缓存命中率提升和QPS提升，成本投入合理，ROI（投资回报率）高。”

7) 【常见坑/雷区】

• 坑1：只说技术不提效果，比如只说用了缓存、消息队列，没说具体效果（如“将QPS从1000提升至5000”）。
• 坑2：数据不具体，比如说“提升了性能”，但没给出量化指标。
• 坑3：优化方案不针对问题，比如问题是因为数据库慢，却优化了缓存，没解决核心问题。
• 坑4：忽略业务场景，比如优化方案适用于秒杀场景，但没说明业务背景，显得不贴合。
• 坑5：没考虑边界情况，比如缓存雪崩、消息队列积压等风险，没给出应对措施。