假设你设计的船舶建造管理系统在高峰期（如船舶交付前）面临高并发请求（如1000+用户同时查询生产进度），导致系统响应变慢。请说明如何优化系统性能，包括架构调整、缓存策略、数据库优化等。

1) 【一句话结论】针对高并发生产进度查询场景，需通过负载均衡分散请求、多级缓存减少数据库压力、数据库读写分离与索引优化提升读性能，综合提升系统响应速度与稳定性。

2) 【原理/概念讲解】老师口吻解释：系统在高并发下，数据库因查询量激增成为瓶颈（类似“高速公路堵车，车辆都挤在数据库这一段”）。

• 架构分层：将系统拆分为前端（处理请求）、应用（业务逻辑）、数据库（数据存储），各层解耦后可独立扩展（比如前端加服务器，数据库扩容，不影响其他层）。
• 缓存的作用：像“临时仓库”，存储热点数据（如生产进度），用户查询时先从缓存取，减少数据库访问（类似“超市把热销商品放在货架，顾客直接拿，不用去仓库”）。
• 数据库优化：通过索引、读写分离等，加速数据读取（比如给“ship_id”字段建索引，查询时数据库能快速定位数据）。

3) 【对比与适用场景】

优化手段	定义	特性	使用场景	注意点
负载均衡	将请求分发到多台服务器实例	提供高可用、水平扩展	系统访问量激增时	需考虑会话粘性（用户会话需保持时，需Session共享）
读写分离	主库负责写，从库负责读	分散读压力，提升读性能	读操作远多于写操作	需保证从库数据一致性（同步/异步复制）
缓存策略（Redis）	存储热点数据，快速响应	低延迟、高并发	热点数据（如生产进度）	需处理缓存穿透、雪崩、过期问题

4) 【示例】
以生产进度查询为例，伪代码展示缓存流程：

def get_production_progress(ship_id):
    cache_key = f"progress:{ship_id}"
    # 1. 尝试从缓存获取
    progress = redis.get(cache_key)
    if progress:
        return json.loads(progress)
    # 2. 缓存未命中，从数据库获取
    progress = db.query("SELECT * FROM production_progress WHERE ship_id = ?", ship_id)
    # 3. 更新缓存（设置TTL，避免数据过时）
    redis.setex(cache_key, 3600, json.dumps(progress))  # 缓存1小时
    return progress

5) 【面试口播版答案】
“针对高并发生产进度查询问题，我会从架构、缓存、数据库三方面优化。首先，架构上采用负载均衡，将请求分发到多台应用服务器，避免单点过载。然后，引入Redis作为缓存层，存储生产进度数据，减少数据库压力。对于数据库，采用读写分离，主库写数据，从库读数据，提升读性能。同时，对数据库表添加索引（如ship_id、progress_time字段），加速查询。通过这些措施，系统在高并发下能快速响应，保障用户体验。”

6) 【追问清单】

• 问：如何处理缓存雪崩问题？
  答：设置缓存过期时间随机（如TTL在60-120秒内随机），避免集中过期导致大量请求直接到数据库。
• 问：数据更新频繁时，缓存如何同步？
  答：使用缓存失效策略（如TTL）或发布-订阅机制，更新时同时更新缓存。
• 问：分库分表是否需要？
  答：若数据量超单库容量，需分库分表，但当前场景优先用读写分离+缓存，更简单有效。
• 问：负载均衡算法如何选择？
  答：根据业务选择轮询、加权轮询或IP哈希，比如轮询适合请求均匀分布。
• 问：如何监控系统性能？
  答：用Prometheus/Grafana监控请求延迟、缓存命中率、数据库连接数等指标，及时发现问题。

7) 【常见坑/雷区】

• 只说缓存而不考虑数据库优化，导致数据库仍成为瓶颈。
• 架构调整不明确，比如只说用缓存，但未说明Redis集群部署。
• 忽略缓存穿透问题，大量无效请求访问数据库。
• 没有考虑数据一致性，读写分离后从库数据滞后影响查询结果。
• 缓存策略选择不当，如用内存缓存但未处理热点数据缓存击穿。