请分享一个你在项目中处理高并发请求（如直播间的并发点赞/评论）的经验，包括遇到的挑战、解决方案和结果。

1) 【一句话结论】在处理直播间点赞/评论高并发时，通过**分阶段限流（令牌桶控制入口流量）、缓存击穿防护（分布式锁+数据库异步更新）、异步解耦（消息队列处理评论）**的组合方案，成功将系统QPS提升至5万级，响应时间从1秒降至0.2秒，保障了系统稳定与用户体验。

2) 【原理/概念讲解】
高并发场景下，核心挑战是请求堆积导致服务雪崩。需通过以下机制缓解：

• 限流（令牌桶/漏桶）：控制请求速率。类比“漏桶”：桶有容量，水滴按速率流出，突发流量直接丢弃（漏桶）；“令牌桶”持续生成令牌，请求消耗令牌，可平滑流量（如API限流）。
• 缓存优化（击穿/雪崩防护）：缓存击穿指高并发请求直接穿透缓存查询数据库，需用**分布式锁（如Redis SETNX）**保证查询数据库的原子性，避免多线程同时查询。
• 异步解耦（消息队列）：将评论等非实时性操作放入消息队列（如Kafka），解耦服务，降低实时性要求，提升系统吞吐量。

3) 【对比与适用场景】

策略	定义	特性	适用场景	注意点
令牌桶	持续生成令牌，请求消耗令牌	速率控制，流量平滑	需要平滑流量（如API限流）	令牌生成速率固定，突发流量需等待
漏桶	桶有容量，水滴按速率流出	严格限制最大速率，突发丢弃	需要严格限制最大速率（如网络传输）	突发流量直接丢弃，可能损失数据

4) 【示例】
以直播间点赞为例，请求处理流程（伪代码）：

用户请求点赞：  
1. 令牌桶限流：检查令牌是否足够，不足则拒绝。  
2. 缓存检查：从Redis获取点赞数，若存在则直接返回。  
3. 缓存击穿处理：若缓存为空（空值/过期），则执行Redis SETNX(key, 1, ex=10)（加锁），若成功则查询数据库，更新缓存（Redis SETEX(key, 5, value)），否则返回缓存数据。  
4. 更新数据库：事务处理（如MySQL事务），确保原子性。  
5. 返回结果：返回更新后的点赞数。  

5) 【面试口播版答案】
“在之前的项目中，处理直播间点赞/评论的高并发时，主要遇到请求堆积导致服务雪崩的问题。首先，通过令牌桶限流控制入口流量，避免系统过载；针对缓存击穿，采用Redis分布式锁（SETNX）保证查询数据库的原子性，防止多线程同时查询；同时引入Kafka消息队列处理评论的异步存储，解耦服务。最终，系统QPS从1万提升至5万，响应时间从1秒降到0.2秒，用户满意度提升。”

6) 【追问清单】

• 问题1：为什么选择令牌桶而非漏桶？
  回答要点：令牌桶能平滑流量，适合需要速率控制的场景，而漏桶更严格限制最大速率，突发流量直接丢弃。
• 问题2：缓存击穿时用SETNX而非其他锁？
  回答要点：SETNX是原子操作，保证互斥，防止竞态条件导致数据不一致。
• 问题3：消息队列处理评论时如何保证数据一致性？
  回答要点：通过ACK确认机制，确保消息被成功处理，失败后重试。
• 问题4：分布式锁的过期时间如何设置？
  回答要点：根据业务逻辑，设为请求处理时间+缓冲时间，避免死锁。
• 问题5：如果系统后续遇到更复杂的并发（如同时点赞+评论），如何优化？
  回答要点：引入事务补偿或状态机，确保数据一致性。

7) 【常见坑/雷区】

• 忽略限流策略选择，直接用简单限流导致突发流量时系统崩溃。
• 缓存击穿时未加锁，导致数据库压力过大。
• 消息队列未处理失败消息，导致数据丢失。
• 分布式锁过期时间设置不当，导致死锁或锁释放不及时。
• 未考虑缓存穿透，空值缓存导致所有请求都查询数据库。