请分享一个你参与过的项目，其中遇到了高并发场景（如360的某个活动期间，服务请求量激增），请描述当时的问题、你的解决方案以及结果。
360Web服务端开发工程师难度：中等
答案
1) 【一句话结论】在360“安全日”活动期间，通过Nginx滑动窗口限流、Redis缓存优化及异步消息队列解耦，成功应对高并发，系统QPS提升50%，服务稳定性达99.9%。
2) 【原理/概念讲解】高并发场景下，核心问题是请求量超过系统处理能力导致服务崩溃。解决思路是“削峰填谷”：
- 限流（Rate Limiting）：控制瞬时流量，像给水管加阀门，防止突发流量淹没系统。常见算法有固定窗口（简单但易堆积）、滑动窗口（更精准，适配波动流量）、令牌桶（控制速率）、漏桶（限制最大速率）。
- 缓存（Cache）：减少对数据库等核心资源的访问，像中间仓库，加速数据读取。常用Redis，通过缓存热点数据降低数据库压力。
- 异步处理（Asynchronous Processing）：解耦请求与响应，将非核心逻辑（如用户验证）放入消息队列（如RabbitMQ），避免阻塞主线程。
3) 【对比与适用场景】
限流算法对比（滑动窗口 vs 固定窗口）：
| 算法 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 固定窗口 | 每个时间窗口固定计数（如每秒1000请求） | 简单实现，但窗口末尾突发流量易超限 | 流量波动小 | 可能导致瞬时流量堆积，引发服务崩溃 |
| 滑动窗口 | 时间窗口动态滑动，计数累积（如每秒1000请求，窗口每0.1秒滑动） | 更精准，避免固定窗口的“堆积”问题 | 流量波动大（如活动期间） | 实现复杂，需精确时间同步（如Nginx的limit_req模块） |
4) 【示例】
项目：360“安全日”活动，用户请求量激增（QPS从2000→8000+）。解决方案伪代码：
- 请求处理流程：
请求到达 → Nginx（滑动窗口限流，每秒1000请求） → 转发后端 后端处理： 1. 检查Redis（key: user_ip, value: 访问次数） 2. 若缓存存在且次数<5 → 更新缓存（incr）→ 返回数据 3. 若缓存不存在/次数≥5 → 查询数据库（用户信息）→ 缓存结果（setex 60 1）→ 返回数据 - 异步处理示例：用户登录后验证（如短信验证码校验）放入RabbitMQ，消费者异步处理，主线程快速返回。
5) 【面试口播版答案】
面试官您好，我分享一个在360“安全日”活动期间处理高并发项目的经历。当时活动期间用户请求量激增，系统QPS从平时的2000飙升至8000+，导致服务超时、数据库连接池耗尽。我的解决方案是：
- 入口限流：用Nginx的滑动窗口限流模块，限制每秒1000请求，避免突发流量冲击；
- 缓存优化：对用户信息查询等热点数据用Redis缓存，将数据库查询结果缓存60秒，减少数据库压力；
- 异步解耦：将非核心业务逻辑（如用户验证）放入RabbitMQ消息队列，避免阻塞主线程。
实施后，系统QPS稳定在6000左右，服务稳定性从80%提升至99.9%，用户反馈无卡顿。
6) 【追问清单】
- 问：具体用了哪种限流算法？为什么选择滑动窗口？
回答要点：用了Nginx的滑动窗口限流，因为活动期间流量波动大，滑动窗口能更精准控制瞬时流量，避免固定窗口的堆积问题。 - 问：缓存策略中，如何处理缓存击穿或雪崩？
回答要点：用了缓存预热（活动前将热门数据放入缓存）和Redis互斥锁（setnx）防止雪崩，确保数据一致性。 - 问：异步处理中，消息队列的容量如何设计？有没有考虑消息积压？
回答要点：根据历史峰值流量估算队列容量，设置消息堆积阈值（如积压超过1000条触发报警），并动态增加消费者线程数。 - 问：如果系统后续流量继续增长，还会考虑哪些优化？
回答要点：考虑水平扩展（增加服务器实例），数据库分库分表，以及更细粒度的限流（如按用户等级限流）。
7) 【常见坑/雷区】
- 限流策略选择不当：如用固定窗口导致突发流量超限，或漏桶导致请求积压；
- 缓存未考虑一致性：直接从缓存读取未过期数据，导致数据不一致；
- 异步处理延迟：若异步任务处理时间过长，用户等待时间过长；
- 忽略系统监控：未实时监控QPS、缓存命中率、数据库连接数等指标，无法及时发现问题；
- 业务场景理解不足：如限流时未区分正常用户和恶意攻击，导致误限流。