高并发系统设计：从理论到实战，聊聊我的踩坑经验
去年我在一家电商平台做后端架构优化的时候，经历了一场“惊心动魄”的高并发压测。那是一次大促前的预演，目标是扛住每秒上万订单量的访问压力。结果测试一开始，系统就直接崩了，数据库连接池打满、接口响应延迟爆炸、服务雪崩……那一瞬间，整个人都麻了。
这次事故让我深刻意识到，高并发不是写几个异步接口就能解决的事，它是一个涉及到方方面面的系统工程，需要我们在架构设计、技术选型、开发规范、部署运维等各个环节都做到心中有数。今天我就以我亲身经历的一个项目为例，来讲讲我们是怎么一步步把这个系统撑起来的。
项目背景与挑战
我们团队负责的是平台的订单中心，处理用户下单、支付回调、库存扣减、订单状态更新等核心流程。随着业务增长，订单量暴增，特别是在促销活动期间，QPS经常突破10k+，系统动不动就会出现卡顿甚至宕机的情况。
主要问题集中在以下几个方面：
- 数据库瓶颈明显：MySQL单库承受不了高频写入操作，事务阻塞严重
- 服务之间耦合度高：订单创建依赖商品、库存、优惠券等多个服务，同步调用链路长
- 缺乏限流降级机制：流量突增时，没有有效的流量控制策略，容易引发雪崩效应
- 缓存使用不合理：缓存穿透、击穿、缓存一致性等问题频繁出现
- 日志和监控不完善：问题定位慢，无法实时感知系统负载变化
架构调整与解决方案
1. 分层架构设计 + 服务拆分
我们先把订单中心从原来的“大一统”服务中拆出来，单独作为微服务，同时引入了应用层、服务层、存储层的三层结构：
[网关]
|
[订单入口 API 层]
|
[订单逻辑服务层]
|
[订单存储 + MQ + 第三方服务调用]
这样做的好处是我们可以按层来做流量控制，也能独立部署扩缩容。比如在高峰期，我们可以只扩订单服务而不影响其他模块。
2. 引入异步化与队列削峰
订单创建是一个很典型的核心路径场景，原来的设计是强同步调用，所有数据都要在一次请求中处理完成，导致响应慢且资源占用高。
我们做了两个关键改造：
- 将部分非实时操作（如通知、报表统计）放到MQ中异步处理
- 使用Redis作为临时缓冲池，先收单再慢慢消费入库
举个例子，原本的下单代码大概是这样的：
public Order createOrder(User user, Product product) {
checkStock(product); // 检查库存
deductStock(product); // 扣库存
createOrderInDB(); // 创建订单
sendNotification(); // 发送通知
return order;
}
后来我们改成了：
public String submitOrderRequest(OrderDTO dto) {
String orderId = UUID.randomUUID().toString();
redis.set("order:"+orderId, dto, 60); // 缓存5分钟
mq.send(orderId); // 异步入库
return "Submitted";
}
后台消费者收到消息后再执行实际的创建流程，并通过WebSocket/短信等方式通知用户。
这样一来，接口响应时间从原先的平均800ms降低到了200ms以内，吞吐量大幅提升。
3. 数据库读写分离 + 分库分表
订单数据量上来之后，原来的单库已经扛不住了。我们采用了如下策略：
- 主从复制实现读写分离，把查询类操作分流到从库
- 使用ShardingSphere进行分库分表，按照用户ID hash取模进行水平分片
这里需要注意的一点是，分库分表会带来一些新的问题：
- 关联查询变得复杂，得尽量避免跨分片 join
- 全局唯一主键怎么办？我们选择了雪花算法生成ID
- 事务怎么处理？用了柔性事务方案，补偿机制为主
分表后的效果非常明显：TP99延迟从原来的1s以上降到了200ms以下。
4. 缓存优化与熔断降级
缓存这块我们踩过很多坑。最开始是用了本地缓存加Redis，但遇到缓存穿透的问题：大量请求访问不存在的数据，直接打爆DB。
后来我们引入了空值缓存和布隆过滤器，缓解这一情况。另外也做了热点Key检测，对特别热门的SKU提前进行预热缓存。
关于熔断和限流，我们使用了Sentinel来统一管理：
# application.yml
spring:
cloud:
sentinel:
transport:
dashboard: localhost:8080
同时设置规则：
private void initFlowRules(){
List<FlowRule> rules = new ArrayList<>();
FlowRule rule = new FlowRule();
rule.setResource("createOrder");
rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
rule.setCount(2000); // 每秒最多2000 QPS
rules.add(rule);
FlowRuleManager.loadRules(rules);
}
一旦超过阈值，立即触发限流，返回友好的提示信息。
5. 日志采集 + 监控告警
最后我们也补齐了日志和监控体系。使用ELK收集日志，Prometheus监控服务状态，Grafana可视化展示：
- 系统CPU、内存、网络IO
- 接口TP指标、错误率
- Redis、MQ、数据库状态
- Sentinel熔断状态
同时接入钉钉告警，在异常情况下自动通知值班人员，极大提高了故障响应速度。
踩过的那些坑
说真的，这些方案看起来都挺常见的，但在落地过程中还是遇到了不少问题：
- MQ堆积：初期我们用了RabbitMQ，结果因为消费者处理能力不足，消息越积越多。后来换成Kafka才解决。
- Redis缓存雪崩：大批缓存同时失效，导致数据库压力暴增。我们给缓存设置了随机过期时间，并引入分布式锁。
- 分库分表JOIN问题：某些报表场景确实需要用Join，最终我们采用ETL的方式，把数据导到ClickHouse里统一分析。
- Sentinel规则同步问题：多实例环境下规则不同步，后来接入Nacos做持久化配置管理。
- 服务注册发现抖动：Eureka心跳机制不稳定，后来换成Nacos+HealthCheck组合方案更稳定。
效果和收益
经过一系列优化之后，整个订单系统的稳定性有了质的飞跃：
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 平均响应时间 | 800ms+ | < 250ms |
| 最大QPS | ~3000 | > 15000 |
| DB连接负载 | 频繁打满 | 保持稳定 |
| 异常报警次数 | 每天十几条 | 基本归零 |
| 大促期间稳定性 | 经常挂 | 平稳运行 |
最直观的感受是——再也不怕晚上突然被电话吵醒了 😅
给同行的一些建议
如果你也在搞高并发系统，或者即将面对这种场景，我有些真心话想分享：
- 别一开始就想着分库分表、上分布式架构。先从小处着手，做好性能压测，找出真正的瓶颈点。
- 不要迷信某个中间件或框架，适合自己业务场景的才是最好的。比如你不一定非要上Kafka，如果你的量没那么大，RabbitMQ也够用了。
- 一定要重视运维体系的搭建。一套好的监控和告警系统能帮你省去90%的半夜爬起来修bug的时间。
- 提前做好应急预案。比如服务降级、限流、熔断这些策略要提前演练，不能等到出事的时候才临时救火。
- 定期做全链路压测。很多问题只有真正跑起来才会暴露出来，光看代码是看不出的。
- 多和运维、前端、产品沟通协作。高并发不只是后端的事，前端做一下防重提交、接口聚合，也能减轻很多压力。
结语
高并发系统的设计，本质上就是在有限资源下，做出最优调度和平衡的艺术。这条路没有银弹，也没有标准答案，靠的是不断试错和总结。希望这篇文章能帮你在未来的架构之路上少走些弯路。
如果你也经历过类似的高并发战斗，请留言告诉我你们的故事。我们一起交流学习，共同进步。
评论 0