请分享一个你参与过的解决高并发问题的项目经历，具体描述问题、你的解决方案以及结果。

招商银行信息技术类岗位难度：简单

答案

1) 【一句话结论】通过引入限流（令牌桶算法）、异步消息队列、缓存预热及数据库优化等组合方案，成功将系统QPS从2000提升至8000，响应时间从2秒降至0.5秒，超时率从50%降至5%以下，保障了业务高并发稳定性。

2) 【原理/概念讲解】高并发问题核心是系统资源（CPU、内存、IO、网络）被大量请求同时占用，导致性能下降甚至崩溃。常见解决方案包括：

限流：控制请求进入速率，防止系统过载。原理类似“漏桶”或“令牌桶”：漏桶算法是请求先进入漏桶，按固定速率流出；令牌桶算法是每秒生成固定数目的“令牌”，请求需消耗令牌才能执行，无令牌则丢弃。类比：装水的桶，漏桶每秒漏1升水，新水只能等漏出后才能进；令牌桶每秒生成10个令牌，每次请求消耗1个令牌，超过10个/秒的请求会被丢弃。
熔断：当服务故障时快速失败，避免级联故障。原理是设置失败次数阈值，当请求失败次数超过阈值时，断路器“打开”，后续请求直接失败（返回错误），待服务恢复后“合上”。类比：电路保险丝，电流过大时保险丝熔断，切断电路，防止设备损坏。
异步处理：将同步请求转为异步，通过消息队列（如Kafka、RabbitMQ）暂存请求，后端消费者异步处理，减少系统实时压力。类比：快递分拣中心，快递员先把包裹放入分拣机（消息队列），再分拣，而不是每个快递员直接处理所有包裹（同步处理）。
缓存：将热点数据提前加载到缓存（如Redis），减少数据库访问。原理是利用缓存的高效读写（内存访问），降低对数据库的压力。类比：图书馆的借阅系统，热门书籍提前放在阅览室（缓存），减少去书库（数据库）的次数。

3) 【对比与适用场景】以限流和熔断为例，对比如下：

方案	定义	原理	适用场景	注意点
限流（令牌桶）	控制请求进入系统的速率，防止系统过载	每秒生成固定数目的“令牌”，请求需消耗令牌才能执行，无令牌则丢弃	高并发场景下的流量控制（如API网关、秒杀系统）	需精确计算令牌速率，避免过度限制正常请求
熔断（断路器）	当服务故障时快速失败，避免级联故障	设置失败次数阈值，超过则断路器“打开”，后续请求直接失败	服务依赖场景（如调用第三方接口、微服务间调用）	需合理设置断路器恢复策略（如延迟、重试）

4) 【示例】假设一个电商“秒杀”API（/api/seckill），原本是同步调用数据库查询商品库存并扣减，高并发时数据库压力过大。解决方案：

限流：网关层用令牌桶算法，每秒允许8000个请求进入。
异步处理：将请求放入Kafka队列，消费者（后端服务）异步处理，将库存扣减操作放入数据库事务。
缓存预热：提前通过定时任务将所有秒杀商品信息加载到Redis（key: seckill_goods, value: 商品JSON），减少数据库查询。

伪代码示例（网关限流）：

class TokenBucket:
    def __init__(self, capacity, rate):
        self.capacity = capacity
        self.rate = rate  # 每秒生成令牌数
        self.tokens = capacity
        self.last_time = time.time()
    
    def consume(self, n=1):
        current_time = time.time()
        elapsed = current_time - self.last_time
        self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
        self.last_time = current_time
        if self.tokens >= n:
            self.tokens -= n
            return True
        return False

请求示例（秒杀请求）：

POST /api/seckill
{
  "goods_id": 123,
  "user_id": 1001
}

5) 【面试口播版答案】我之前参与过一个电商平台的秒杀系统优化项目，当时系统在双十一秒杀高峰期出现高并发问题，具体表现为API响应超时率超过50%，系统CPU利用率飙升至90%，用户投诉增多。我的解决方案是分三步：首先，在网关层引入令牌桶限流，将QPS限制在8000以内，避免请求直接冲击后端；其次，将原本同步的数据库查询改为异步处理，通过Kafka消息队列将请求放入队列，后端消费者异步处理，减少数据库压力；最后，对热点商品信息进行缓存预热，提前将商品数据加载到Redis，减少数据库访问。实施后，系统QPS从2000提升至8000，响应时间从2秒降至0.5秒，超时率降到5%以下，成功保障了业务稳定。

6) 【追问清单】

问题1：你提到的限流算法具体用了哪种？为什么选择它？
- 回答要点：我用了令牌桶算法，因为它能平滑控制流量，适合持续请求场景，相比漏桶算法更灵活（可调整令牌生成速率）。
问题2：异步处理中，消息队列的容量如何设计的？有没有考虑消息积压？
- 回答要点：根据历史秒杀峰值（约10000 QPS）和消费者处理能力（每秒500条），设置了Kafka队列容量为10万条，并配置了重试机制，避免消息积压导致请求丢失。
问题3：缓存预热的数据量有多大？如何保证数据一致性？
- 回答要点：缓存预热覆盖了所有秒杀商品（约1000种），通过定时任务（每分钟更新一次）和实时更新（当商品库存变化时同步更新Redis），保证数据一致性。
问题4：如果系统后续遇到更极端的高并发（比如QPS超过10000），你会怎么进一步优化？
- 回答要点：会考虑数据库分库分表（将商品表拆分到多个数据库实例），增加缓存层（如Redis集群），并引入CDN加速静态资源，从架构层面提升系统容量。

7) 【常见坑/雷区】

只说问题没说解决方案：面试官想知道你的解决思路，只描述问题无法体现能力。
技术细节不清晰：比如“用了限流”但没解释限流算法原理，显得不专业。
忽略系统整体架构：只关注单一组件（如数据库），没考虑网关、缓存、消息队列等整体优化。
结果不量化：只说“提升了”，没给出具体指标（如QPS、响应时间），无法证明效果。
回答过于笼统：比如“用了限流和异步”，没说明具体实现方式（如限流在网关层，异步用Kafka），显得不具体。