请分享你之前参与的一个游戏项目中的高并发优化经历，比如在某个活动期间服务器响应变慢，你如何定位问题并解决？
答案
1) 【一句话结论】在游戏活动期间，通过监控与链路追踪定位到数据库查询成为瓶颈，通过优化SQL并引入Redis缓存，将接口响应时间从2秒降至0.2秒，QPS提升5倍。
2) 【原理/概念讲解】高并发下系统瓶颈通常出现在I/O（如数据库）、缓存未命中或CPU过载。监控工具（如Prometheus+Grafana）可实时观测QPS、延迟分布；链路追踪（如Jaeger）能定位到具体慢SQL或接口。例如，当QPS骤降且延迟分布显示数据库层耗时占比超70%，说明数据库成为瓶颈。类比：交通拥堵时，监控看车流量，链路追踪找堵在哪个路口（数据库查询）。
3) 【对比与适用场景】
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 缓存（如Redis） | 存储热点数据，减少数据库访问 | 低延迟、高并发读写 | 热点数据（如排行榜、用户信息）、频繁访问的静态数据 | 需防缓存击穿/雪崩，设计过期策略 |
| 数据库（如MySQL） | 关系型数据库，持久化存储 | 事务支持、数据一致性 | 业务逻辑复杂、需持久化的数据（如用户订单、游戏记录） | 高并发下I/O瓶颈，需优化索引、分库分表 |
4) 【示例】
假设游戏“每日签到”活动期间，用户请求“获取用户排行榜”的接口，QPS从1000/s降至200/s，延迟从0.5秒涨至2秒。通过Grafana监控发现，该接口的数据库查询（select * from user_rank where activity_id=...）耗时从10ms升至200ms。优化步骤：
- 为
activity_id字段添加索引； - 引入Redis缓存，缓存key为
user_rank:activity_id，过期5分钟； - 代码中先查Redis，若不存在再查数据库并更新缓存。
优化后，延迟降至0.2秒，QPS恢复至1000/s。
5) 【面试口播版答案】
面试官您好，我之前参与一个游戏“每日签到”活动项目，活动期间用户请求量激增，原本响应正常的接口突然变慢，QPS从2000降到500，延迟从0.3秒涨到2秒。首先，我用Grafana看监控，发现请求延迟的分布中，数据库查询占70%以上，具体是查询签到记录的慢SQL。然后，用Jaeger链路追踪定位到该SQL的执行时间从10ms变成200ms。分析后发现，数据库表没有为活动ID建立索引，导致全表扫描。解决方法是：1. 为活动ID字段添加索引；2. 引入Redis缓存，将签到排行榜数据缓存，缓存key为daily_signin_rank:activity_id，过期5分钟。优化后，接口延迟从2秒降到0.2秒，QPS恢复到2000，用户反馈正常。这个经历让我理解了高并发下要优先从I/O瓶颈入手，通过监控+链路追踪定位问题，再结合缓存、索引等手段优化。
6) 【追问清单】
- 问：具体用了什么工具来监控和定位？
回答要点：用了Prometheus+Grafana做监控，Jaeger做链路追踪。 - 问：优化后是否考虑了缓存击穿问题？如何处理的？
回答要点：是的，用了Redis的SETNX（互斥锁）或布隆过滤器，确保缓存数据一致性。 - 问：如果数据库压力还是大，是否考虑过分库分表？
回答要点：若缓存优化后仍不够，会考虑按活动ID分库分表，或采用读写分离。 - 问：优化过程中，是否评估了成本？比如缓存服务器成本？
回答要点：评估了Redis集群成本，与数据库优化相比，缓存提升性能的同时，成本可控，可水平扩展。 - 问：是否考虑过异步处理？比如将部分请求异步处理？
回答要点：对于非实时的数据（如排行榜更新），可异步处理减少数据库压力，但实时性接口仍需同步。
7) 【常见坑/雷区】
- 只说优化了代码，没提监控和定位过程，显得被动；
- 只说加了缓存，没说明缓存预热，导致冷启动时性能下降；
- 优化后没验证效果，缺乏监控数据支撑；
- 忽略缓存雪崩问题，导致所有缓存同时过期；
- 没考虑数据库连接池或查询优化，如索引没加导致全表扫描。