描述一个你之前参与的高并发项目，遇到的性能瓶颈（如数据库查询慢、缓存失效），如何分析和优化？
答案
1) 【一句话结论】
在腾讯云订单系统中，因高并发导致数据库锁竞争严重，通过分库分表+读写分离+缓存双写+异步消息队列优化，将数据库QPS提升3倍，响应时间从1.5秒降至0.2秒。
2) 【原理/概念讲解】
老师会解释高并发下数据库瓶颈的核心原因：表数据量过大引发全表扫描（如百万级库存表全表扫描导致锁竞争）、锁竞争加剧（行级锁/表级锁在高并发下频繁争夺资源）；缓存失效分三类：
- 缓存穿透：热点key（如秒杀商品ID）不存在，大量请求直接到数据库；
- 缓存击穿：热点key突然失效（如定时任务误删），瞬间触发大量数据库请求；
- 缓存雪崩：大量key同时过期（如TTL统一为0点），导致缓存服务瞬间崩溃。
优化核心是“分层隔离”：
- 数据库层：通过分库分表（按业务/数据范围拆分实例/表）、读写分离（主库写+从库读）降低单库压力；
- 缓存层：通过布隆过滤器防穿透、TTL+热点key预热防击穿、分布式锁防雪崩；
- 业务层：通过异步解耦（消息队列）减少直接数据库调用。
类比：数据库像“停车场”，高并发时车辆（请求）太多，导致排队（锁竞争）；分库分表是“建多个停车场”（分库），每个停车场容量小，减少排队；缓存像“停车场入口的引导牌”（缓存），先检查引导牌（缓存），没有才去停车场（数据库），引导牌失效时，先放临时标志（布隆过滤器），避免大量车辆直接去停车场。
3) 【对比与适用场景】
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 分库分表 | 按业务/数据范围拆分数据库实例和表 | 需要数据一致性处理（如分布式事务） | 数据量极大（千万级以上），单库无法承载 | 需业务拆分，开发复杂 |
| 读写分离 | 主库写，从库读 | 读库压力分散，主库专注写 | 读多写少场景（如电商商品列表） | 需主从同步延迟控制 |
| 策略 | 定义 | 适用场景 | 优化点 |
|---|---|---|---|
| 缓存穿透 | 热点key不存在，直接请求数据库 | 防恶意攻击 | 布隆过滤器 |
| 缓存击穿 | 热点key突然失效，大量请求 | 热点数据（如秒杀商品） | 热点key预热、分布式锁 |
| 缓存雪崩 | 大量key同时过期 | 高并发场景 | 设置随机TTL、热点key预热 |
4) 【示例】
假设项目是电商订单系统，高并发场景是用户下单时查询库存（库存表）。优化前：10000并发请求，库存表全表扫描，数据库锁竞争，响应时间1.5秒。优化后：
- 添加Redis缓存，库存数据存入Redis，TTL=30秒；
- 布隆过滤器标记库存表数据，避免缓存穿透；
- 下单时先查Redis，无则查布隆过滤器，再查数据库，数据库结果回写Redis；
- 库存表分库分表（按商品ID哈希分表），读写分离（主库写，从库读）。
伪代码示例：
def query_stock(product_id):
# 1. 检查布隆过滤器
if not bloom_filter.has(product_id):
return "库存不存在"
# 2. 检查Redis缓存
stock = redis.get(f"stock:{product_id}")
if stock is not None:
return int(stock)
# 3. 数据库查询（从库）
stock = db.read(f"select stock from inventory where product_id={product_id}")
if stock is not None:
redis.set(f"stock:{product_id}", stock, ex=30)
return stock
5) 【面试口播版答案】
之前参与过腾讯云订单系统的开发，项目是高并发的订单处理，遇到的主要性能瓶颈是数据库查询慢。当时系统上线后，用户下单高峰期（每秒5000+请求），查询库存的SQL（select stock from inventory where product_id=?）在数据库层面出现锁竞争，响应时间从1秒飙升至2.5秒，导致订单超时。分析过程：通过监控工具（Prometheus+Grafana）发现，库存表的行级锁竞争率超过80%，且该表数据量达百万级，全表扫描概率高。优化方案：首先引入Redis作为二级缓存，将库存数据缓存，TTL设为30秒；其次，为防止缓存穿透，添加布隆过滤器，标记库存表存在的商品ID；然后，对库存表进行分库分表（按商品ID哈希分表），并配置读写分离（主库写，从库读）；最后，将库存查询逻辑改为先查Redis，无则查布隆过滤器，再查数据库，数据库结果回写Redis。优化后，数据库QPS提升3倍，响应时间降至0.2秒，订单超时率从5%降至0.1%。
6) 【追问清单】
- 分库分表的具体实现方式？
回答要点：使用ShardingSphere框架，按商品ID哈希分表，配置路由规则。 - 缓存失效的应对中，如何处理缓存雪崩？
回答要点：设置随机TTL（如30-60秒随机），热点key提前预热（如提前将秒杀商品库存存入缓存）。 - 异步处理是否也用了？
回答要点：对于非实时性高的库存更新（如用户下单后异步扣减库存），引入消息队列（如RocketMQ），将库存扣减操作异步化，减少数据库压力。 - 监控指标如何验证优化效果？
回答要点：监控数据库锁竞争率（从80%降至5%）、Redis缓存命中率（从60%提升至95%）、系统响应时间（从2.5秒降至0.2秒）。 - 是否考虑了数据一致性？
回答要点：分库分表后使用分布式事务（如两阶段提交），确保库存扣减和订单创建的一致性。
7) 【常见坑/雷区】
- 只说优化方法，没讲分析过程：比如只说“用了分库分表”，没解释为什么用（因为数据库锁竞争），容易被追问分析细节。
- 缓存策略没区分穿透、击穿、雪崩：比如只说“加了缓存”，没说明针对哪种问题，显得不专业。
- 忽略业务场景：比如分库分表按商品ID分表，但没说明为什么选这个字段（比如商品ID分布均匀），或者没考虑读写分离的延迟问题（比如从库延迟导致数据不一致）。
- 优化方案不具体：比如“优化了数据库”，没说具体优化步骤（如索引优化、SQL优化），显得空洞。
- 忽略监控和测试：比如没提如何验证优化效果，显得优化没效果。