高并发系统设计：从理论到实践的实战记录
作为一个在互联网公司工作的后端开发，高并发系统的挑战是我日常工作中绕不开的话题。尤其是在我参与的一个电商秒杀项目中，真实地体会到了“高并发”这个词背后的复杂性和紧迫感。
今天想和大家分享这段经历，不仅是技术实现的过程，还有我们踩过的坑、犯过的错，以及从中总结的经验教训。
一、项目背景与问题初现
去年年底，我们接到一个紧急需求：为某次大型促销活动设计并上线一套秒杀系统。这个系统需要支持单个商品瞬时上万人同时抢购，预计峰值QPS要突破5万。
刚看到这个需求的时候，我心里其实有点发虚。因为之前虽然也做过一些并发处理优化，但从未面对如此极端的流量冲击。更关键的是，这个项目时间紧任务重，留给我们的时间只有四周。
最开始，我们搭建了一个基于Spring Boot的基础服务架构，部署在阿里云ECS上，数据库用的是MySQL，缓存用了Redis，整体看起来没什么问题。但在一次内测压测中，系统直接崩了 —— QPS还没达到预期的一半，接口就开始大量超时，甚至出现了数据库连接池打满的异常。
这时候我们才意识到：这不仅仅是一个接口性能的问题，而是一个系统级的设计问题。
二、面临的挑战与思考路径
经过复盘，我们发现了几个严重的问题：
- 请求没有削峰填谷，所有流量直接冲向核心逻辑；
- 库存操作未加锁，导致超卖现象；
- DB压力过大，成为整个系统的瓶颈；
- 缺乏降级容错机制，异常情况下系统失去自愈能力；
- 消息异步处理机制缺失，订单落库存在延迟和丢失风险。
于是，我们决定从架构层面重新梳理系统结构，并逐步引入一系列高并发下常用的解决方案。
三、我们的技术方案与实现思路
1. 架构升级与流量控制
我们采用了经典的漏斗模型对流量进行层层拦截和过滤：
- 最外层使用Nginx做负载均衡 + IP限流（通过
ngx_http_limit_req_module）； - 业务层使用Guava的
RateLimiter做本地限流兜底； - 加入前置队列（RocketMQ），将核心业务流程解耦成两个阶段。
这样做的好处是，既避免了突发流量直接冲击系统，也能保证在高峰期不至于完全挂掉。
2. 缓存预热 + Redis热点降级
在活动前，我们会把即将秒杀的商品库存提前加载进Redis，并设置好过期时间和淘汰策略。为了避免Redis雪崩，我们在预热时对每个key设置了随机的过期时间。
此外，在秒杀高峰期，我们临时关闭了部分非核心接口（如用户详情查询等），让资源优先倾斜给主流程。
// 简化版限流代码示例：
private final RateLimiter rateLimiter = RateLimiter.create(2000); // 每秒2000次
public ResponseDTO trySeckill(Long userId, Long goodsId) {
if (!rateLimiter.tryAcquire()) {
return ResponseDTO.fail("当前访问人数太多，请稍后再试");
}
// 后续业务逻辑...
}
3. 库存扣减 + 防止超卖
为了确保不出现超卖，我们做了多层保障：
- 使用Redis计数器做“令牌桶式”库存限制；
- 在MySQL中采用乐观锁方式更新库存（CAS）；
- 使用Redis Lua脚本实现原子性操作。
比如我们最终选择使用Redis + Lua的方式来进行快速库存扣除：
-- 减库存Lua脚本
local key = KEYS[1]
local decrease = tonumber(ARGV[1])
local stock = redis.call('GET', key)
if not stock then
return -1 -- 不存在
end
if tonumber(stock) < decrease then
return -2 -- 不足
end
redis.call('DECR', key)
return redis.call('GET', key)
Java端调用如下：
Long result = stringRedisTemplate.execute(new DefaultRedisScript<>(SCRIPT_CONTENT, Long.class),
Arrays.asList("seckill_stock_1001"), 1);
switch (result.intValue()) {
case -1: throw new RuntimeException("库存不存在");
case -2: throw new RuntimeException("库存不足");
default: break;
}
4. 异步下单 & 消息队列解耦
考虑到MySQL在高并发下的写入瓶颈，我们将订单创建过程从同步改为异步。
我们采用了RocketMQ作为异步队列，将订单生成的消息发布出去，由专门的消费者服务去落库。
这样做的好处是：
- 主流程耗时大幅下降；
- 避免因订单写入失败导致整体失败；
- 方便后期横向扩展。
5. 多维度降级机制
为了避免系统彻底崩溃，我们加入了以下几个层次的降级措施：
- Redis不可用时切换至本地内存缓存；
- MySQL无法写入时临时存储到本地日志，等待恢复；
- 接口调用链路可随时“剪枝”，关闭非必要环节；
- 前端页面自动识别是否进入排队模式。
四、踩过的坑与应对方法
坑一：Redis连接池被打爆
刚开始测试的时候，Redis的连接池总是爆掉。后来发现是我们没合理配置Jedis的maxTotal参数，同时每次请求都new JedisPool也没释放。
解决方法：统一使用Spring Boot Data Redis封装好的连接池管理，并调整lettuce客户端为默认驱动，提升稳定性和性能。
坑二：MySQL事务死锁频发
高并发下频繁更新库存表导致事务之间相互等待资源，MySQL经常报Deadlock异常。
解决办法：
- 统一操作顺序（如先操作商品再操作订单）；
- 尽量缩小事务粒度；
- 必要时加分布式锁（如Redis分布式锁）来串行化操作；
- 使用分库分表降低锁竞争。
坑三：消息积压 & 重复消费
由于订单服务短暂宕机，导致大量订单消息堆积在MQ中。重启后又面临“重复消费”的问题。
我们最终的做法是：
- 为每个订单ID设置幂等标志位（Redis SetNx）；
- 消费前检查是否已处理过；
- 设置合理的重试策略（指数退避）；
- 监控消息堆积情况，及时人工干预。
五、上线后的效果与收益
这套系统在正式活动中撑住了5万+的QPS，最高瞬间峰值达到了6.7万，系统整体可用率达到了99.5%以上，相比之前的版本有了显著提升。
我们实现了以下几点：
- 接口响应时间从平均800ms降到150ms以内；
- 系统整体吞吐量提升了3倍；
- 整个活动中未发生一起超卖事件；
- 通过监控系统可以实时感知系统状态；
- 运维同学也可以快速介入处理异常情况。
更关键的是，这次经验让我们团队对高并发系统的设计有了一整套成熟的方法论。
六、我的几点建议与心得
如果你也在做类似的高并发系统开发，我可以分享几点实际经验：
- 不要盲目追求极限性能，先搞清楚业务场景的上限到底在哪；
- 每增加一层中间件，就增加了运维成本和潜在故障点；
- 高并发不是单纯靠算法或框架解决的，而是靠整体架构的合理性；
- 测试必须贴近真实环境，本地模拟永远赶不上线上真实流量；
- 预留弹性扩容空间和降级机制，关键时刻能救命；
- 做好监控和报警，早发现早解决；
- 保持敬畏之心，哪怕你做了再多压测，真正上线那一刻，才是真正的考验开始。
写在最后：高并发不止是技术，更是思维方式
回顾那次项目，最大的收获不是学会了几种限流算法或者缓存策略，而是学会了如何站在一个更高的视角看系统、看流量、看稳定性。
高并发系统的建设，从来都不是一件孤立的技术工作，它涉及产品、架构、运维、测试等多方协作。更重要的是，它教会我一种“抗风险”思维 —— 在设计之初就要想到未来可能发生的各种极端情况，并为此做出准备。
希望这篇文章能给你带来一些启发，也欢迎你在评论区留言交流你们团队在做高并发项目中的宝贵经验。
评论 0