一、剧情核心冲突与细节
第三次压力测试结果出炉：模拟国庆高峰期 100 万用户并发访问，首页加载时间 12 秒，预约接口响应时间 4.5 秒，远超 500ms 的目标；更严重的是，Redis 集群在峰值时出现 “缓存击穿”，大量请求直达 MySQL，导致数据库连接池耗尽，服务出现 5 分钟的部分不可用。运维团队紧急扩容服务器，但效果甚微，林悦意识到必须从 “缓存协同、异步优化、SQL 调优” 三个维度进行系统性攻坚。
二、知识点融入与解决路径（深化技术细节）
多级缓存的 “协同与防雪崩” 设计：
缓存层级协同：①浏览器缓存：静态资源（JS、CSS、图片）设置 Cache-Control: max-age=86400（1 天），首页 HTML 设置 ETag，实现协商缓存；②CDN 缓存：阿里云 CDN 加速静态资源，配置 “智能压缩” 和 “防盗链”，热门景区图片设置缓存过期时间 = 7 天；③网关缓存：Gateway 缓存景区基础信息（如名称、地址），TTL=5 分钟，减轻后端服务压力；④本地缓存：服务端用 Caffeine 缓存高频访问的商品库存（TTL=1 分钟，最大容量 = 10000），缓存命中率需≥90%；⑤分布式缓存：Redis 集群缓存用户会话（TTL=2 小时）、实时客流数据（TTL=30 秒）、订单列表（TTL=10 分钟）。
缓存问题综合治理：①穿透防护：布隆过滤器（初始化加载所有景区 ID、商品 ID）部署在 Gateway 层，过滤无效 ID 请求；②雪崩防护：Redis 缓存过期时间添加随机值（±30 秒），避免同一时间大量缓存失效；Redis 集群采用主从 + 哨兵模式，3 主 3 从架构，单个主节点故障时 10 秒内完成主从切换；③一致性防护：采用 “Canal 监听 MySQL binlog” 机制，当商品库存、景区信息更新时，自动触发 Redis 缓存更新，确保缓存与数据库数据最终一致。
异步通信的 “消息队列 + 事件驱动” 模式：将系统中 “非实时、非核心” 流程全部改为异步：①订单通知：预约成功后，预约服务发送消息到 RabbitMQ “order_notice” 队列（交换机类型 = Direct），通知服务消费消息，异步发送短信、推送 APP 通知；②数据统计：订单支付完成后，发送消息到 “data_statistics” 队列（交换机类型 = Topic），数据处理服务消费消息，异步更新景区销售额、游客量统计；③日志采集：各服务通过 Logback 将日志发送到 Kafka “service_log” 主题，ELK 集群消费 Kafka 日志，实现日志异步采集与分析。消息队列配置细节：RabbitMQ 开启 “消息持久化” 和 “死信队列”，死信队列 TTL=24 小时，用于处理消费失败的消息；Kafka 设置副本数 = 3，确保日志不丢失。
SQL 优化的 “执行计划 + 索引优化” 实操：针对慢查询进行专项优化：①慢查询定位：开启 MySQL 慢查询日志（long_query_time=1 秒），通过 pt-query-digest 分析日志，发现 “SELECT * FROM order WHERE user_id=? AND create_time BETWEEN ? AND ?” 查询耗时 2.3 秒；②执行计划分析：explain 显示该查询未使用索引，全表扫描；③索引优化：创建 “user_id+create_time” 组合索引，索引类型为 B-tree，优化后查询耗时缩短至 0.05 秒；④其他优化：禁用 SELECT *，只查询必要字段；将复杂的 “订单表 + 商品表 + 景区表” 三表关联查询，拆分为三次单表查询，通过应用层组装数据；调整 MySQL 参数：innodb_buffer_pool_size = 物理内存的 70%，提升缓存命中率；max_connections=1000，避免连接池耗尽。
三、考点深度关联
本单元深化了 “多级缓存的协同策略”“消息队列的交换机类型与死信队列配置”“SQL 优化的执行计划分析”，这些是案例分析题中 “系统性能瓶颈排查与优化” 的必考内容。例如真题中常给出 “高并发下系统响应慢” 的场景，需从缓存、异步、SQL 三个维度给出优化方案；而缓存防雪崩、消息持久化等细节，也是论文 “性能优化” 章节的关键论据。
