假设系统在门诊高峰期（如周末）出现高并发请求，导致响应延迟（如页面加载超时、查询缓慢），请描述诊断步骤和优化方案（包括负载均衡、缓存、数据库优化等）。

1) 【一句话结论】系统高并发响应延迟需分阶段诊断（从网络、负载均衡、缓存、数据库逐层排查瓶颈），再针对性优化（负载均衡分流、缓存热点数据、数据库索引/分库分表等），从架构层面提升系统吞吐量与响应速度。

2) 【原理/概念讲解】高并发下响应慢的本质是资源（CPU、内存、I/O）争抢。好比城市交通，高峰期道路拥堵（网络延迟）、红绿灯分配不合理（负载均衡）、停车场车位不足（缓存）、修车厂效率低（数据库）。需按“网络→负载均衡→应用→缓存→数据库”顺序排查，找到具体瓶颈点。

3) 【对比与适用场景】

方向	负载均衡（如Nginx）	缓存（如Redis）
核心作用	分发请求到后端服务器，提升可用性与负载均衡	存储热点数据，减少数据库查询压力
适用场景	请求量激增，后端服务器数量增加时	热点数据（如科室列表、医生排班），频繁查询但数据变化少
注意点	算法选择（如轮询、哈希、会话保持），需考虑会话一致性	缓存击穿/雪崩/穿透，需设置过期策略、热点数据预加载

4) 【示例】假设门诊系统查询患者信息接口（/patient/info），高并发时响应超时。

• 诊断：1. 检查Nginx日志，发现请求分发到某台服务器延迟高；2. Redis缓存热点数据（如科室信息）命中率低（<50%）；3. 数据库SQL未加索引（如按ID查询患者信息）。
• 优化：1. 负载均衡用Nginx轮询+会话保持；2. Redis缓存热点数据，设置TTL（如1小时），预加载；3. 数据库为患者表加ID索引，优化SQL。

5) 【面试口播版答案】面试官您好，针对门诊高峰期高并发导致的响应延迟，我的诊断思路是分步骤排查：首先看系统监控（CPU、内存、网络延迟），接着检查负载均衡器（如Nginx）的请求分发是否合理，再分析缓存（如Redis）的热点数据命中率，最后看数据库查询是否因索引缺失导致慢。优化方案包括：1. 负载均衡用Nginx轮询+会话保持，确保请求均匀分发且用户会话一致；2. 对热点数据（如科室列表、医生排班）用Redis缓存，设置合理过期时间；3. 数据库为高频查询字段加索引，优化SQL。通过这些措施，可有效缓解高并发下的响应延迟。

6) 【追问清单】

1. 负载均衡的算法选择（如轮询、哈希、会话保持）如何影响系统？
   • 答：轮询均衡请求，但热点数据可能集中到某台服务器；哈希均衡按请求参数哈希，但会话不一致；会话保持确保用户会话在同一台服务器，适合需要会话状态的应用。
2. 缓存击穿/雪崩/穿透如何处理？
   • 答：击穿用互斥锁+缓存；雪崩用随机过期时间；穿透用布隆过滤器。
3. 数据库分库分表的具体策略？
   • 答：按业务分库（如门诊、康复分库），按时间或ID分表，避免单表数据过大。
4. 监控工具如何辅助诊断？
   • 答：用Prometheus+Grafana监控CPU、内存、网络延迟，结合日志分析请求路径。
5. 优化后的效果如何评估？
   • 答：通过QPS、响应时间、资源利用率等指标，对比优化前后的数据。

7) 【常见坑/雷区】

1. 只优化数据库而忽略缓存，导致缓存命中率低，仍需频繁查询数据库；
2. 负载均衡算法选择不当（如会话保持导致热点不均），反而加剧服务器压力；
3. 缓存未设置过期策略，导致数据不一致（如医生排班更新后，缓存未及时刷新）；
4. 数据库索引设计错误（如过度索引增加写入成本，或索引缺失导致查询慢）；
5. 未考虑网络延迟，直接优化应用层，而网络是实际瓶颈。