之前项目中，实验预约系统在高峰期（如开学季）出现响应延迟，你如何分析瓶颈并优化？比如缓存、异步处理、数据库优化？

1) 【一句话结论】
通过分析发现实验预约系统高峰期响应延迟的核心瓶颈是高并发下数据库查询与缓存未命中的双重压力，以及异步任务堆积导致的资源争抢，通过分层优化（缓存预热+热点数据缓存、异步解耦+消息队列、数据库索引+分库分表）有效解决了问题。

2) 【原理/概念讲解】
老师口吻解释关键概念：

• 缓存：基于数据局部性原理，将频繁访问的热点数据（如实验剩余名额）存入内存（如Redis），当用户请求时先查询缓存，若命中则快速返回，若未命中则查询数据库并更新缓存。类比“图书馆借阅卡”：先查快速通道（缓存），没的话再查原始资料（数据库）。
• 异步处理：将用户请求中的非核心逻辑（如发送预约成功通知）从同步流程中剥离，放入消息队列（如RabbitMQ），由后台消费者异步处理，前端快速返回。类比“餐厅点餐”：点餐后先拿号（入队列），服务员（消费者）处理完再通知，不影响点餐速度。
• 数据库优化：通过索引加速查询（如实验ID+预约状态索引）、分库分表降低单库压力（如按实验类型分库），类比“交通疏导”：给热门路段（高频查询表）加索引（快速通道），多开车道（分库分表）减少拥堵。

3) 【对比与适用场景】

技术	定义	特性	使用场景	注意点
缓存	将热点数据存入内存加速访问	读性能提升，写性能略有延迟	高频读低频写场景（如实验剩余名额查询）	需考虑缓存击穿/雪崩防护，热点数据预热
异步处理	将非核心逻辑放入消息队列异步执行	解耦请求，提升并发处理能力	需要快速响应但后续逻辑耗时（如发送通知）	需保证消息可靠性（重试、幂等性）
数据库优化	通过索引、分库分表等提升数据库性能	写/读性能提升，需维护成本	高并发写/读场景（如预约操作）	索引设计需合理，分库分表需考虑数据一致性

4) 【示例】
以实验预约请求为例，流程如下：

1. 用户请求预约某实验，系统先查询Redis缓存（key=实验ID+状态）是否有剩余名额。
2. 若缓存命中（有剩余名额），直接返回“预约成功”。
3. 若缓存未命中，查询MySQL数据库（表：实验预约表，字段：实验ID、剩余名额、状态），更新剩余名额并更新缓存，同时将预约请求（实验ID、用户ID、时间）放入RabbitMQ队列。
4. 后台消费者从队列中取出请求，执行后续逻辑（如发送短信通知用户预约成功）。
   （代码伪代码示例：
   Redis缓存查询：if redis.get("experiment_100_status") == "available": return success
   数据库更新：update experiment_reservation set remaining_slots = remaining_slots - 1 where experiment_id = 100
   消息队列发送：rabbitmq.publish("reservation_queue", { "experiment_id": 100, "user_id": 123 })）

5) 【面试口播版答案】
“面试官您好，针对实验预约系统高峰期响应延迟的问题，我主要从三个层面分析并优化：
首先，通过压力测试发现，高峰期（如开学季）大量用户同时查询实验剩余名额时，数据库查询压力激增，且缓存未命中导致多次数据库访问，形成性能瓶颈。
其次，针对数据库查询慢的问题，我引入了Redis缓存，将实验的剩余名额状态作为热点数据缓存，用户请求时先查缓存，命中则快速返回，未命中则查询数据库并更新缓存，有效降低了数据库压力。
然后，针对高并发下异步任务（如发送预约成功通知）堆积的问题，我使用了RabbitMQ消息队列，将预约请求从同步流程中剥离，前端快速返回，后台消费者异步处理，避免阻塞用户操作。
最后，对数据库进行了优化，为实验预约表添加了实验ID+状态的联合索引，加速了剩余名额查询，同时考虑分库分表方案（假设实验类型多，按类型分库），进一步分散数据库压力。
通过以上优化，系统高峰期响应时间从原来的2秒降低到0.3秒，并发用户数提升了3倍。”

6) 【追问清单】

• 问：具体用了什么缓存工具？为什么选Redis？
  回答要点：用了Redis，因为其内存存储特性适合高频读，且支持数据持久化，适合实验预约这类热点数据。
• 问：异步处理中，消息队列的可靠性如何保障？比如消息丢失或重复消费怎么办？
  回答要点：通过消息队列的持久化存储（如RabbitMQ的持久化队列）和消费端的幂等性处理（如根据请求唯一标识判断是否已处理过），确保消息不丢失且不重复处理。
• 问：数据库优化中，索引设计是否考虑了索引维护成本？比如新增实验类型时索引是否需要重建？
  回答要点：是的，索引设计时考虑了业务场景，比如实验ID+状态索引是高频查询字段，新增实验类型时通过分库分表（按实验类型分库）避免单库索引重建，降低维护成本。
• 问：缓存击穿/雪崩的应对措施有哪些？
  回答要点：缓存击穿用互斥锁+空值缓存（如设置默认值）；缓存雪崩用随机过期时间（避免同一时间大量缓存过期）。

7) 【常见坑/雷区】

• 只说技术而没结合业务场景，比如缓存未考虑实验预约的热点数据（如热门实验），导致缓存命中率低，优化效果差。
• 异步处理没考虑幂等性，导致重复发送通知，影响用户体验。
• 数据库优化中索引设计不合理，比如为非查询字段添加索引，增加写性能开销，或者分库分表后跨库查询复杂，影响业务逻辑。
• 缓存未预热，高峰期时缓存初始为空，导致大量请求直接访问数据库，加剧性能问题。
• 忽略了系统监控，没有通过监控工具（如Prometheus+Grafana）跟踪缓存命中率、数据库查询延迟等指标，无法精准定位瓶颈。