高并发系统设计：我的实战之路
背景介绍
去年，我在一家电商公司参与了一个订单系统的重构项目。这个项目听起来挺常规的——把原本性能堪忧、维护困难的旧系统换成一套更现代、可扩展的新系统。但真正上手之后才发现，这背后隐藏着不少挑战，尤其是在“高并发”这个关键词上。
原来的订单系统是典型的单体应用，部署在几台物理服务器上。一旦到了大促或者秒杀节点，服务器频繁出现雪崩式宕机，数据库也被打挂了，整个流程瘫痪。产品经理天天催我们上线新版本，压力山大。而我们的目标是：支撑至少每秒10万次请求，同时保证数据的一致性和接口的响应时间控制在200ms以内。
说白了，这就是一次从0到1打造高并发系统的尝试。
问题描述：那些让人彻夜难眠的痛点
刚接手这个项目的时候，我大概列了一下我们遇到的主要问题：
1. 数据库瓶颈严重
订单系统对数据库依赖非常重，尤其是写操作密集。原来用的是MySQL主从架构，但由于没有分库分表，热点库存更新时经常导致锁竞争和慢查询。
2. 接口响应慢且不稳定
用户下单、付款、查订单这些接口的平均耗时一度超过800ms，尤其在高峰期会出现大量超时甚至504错误（Gateway Timeout）。
3. 系统不具备横向扩展能力
旧系统没有服务拆分，所有逻辑都在一个服务里跑。CPU、内存都吃满的时候，只能硬扛，扩容成本也非常高。
4. 雪崩效应频发
一旦某个服务或组件崩溃，比如Redis集群故障，就容易引发下游服务连锁反应，导致整条链路全部崩溃。
这些问题交织在一起，根本无法应对即将到来的大促流量。我们必须尽快找到突破口，否则上线就是灾难。
解决方案：一步步构建高并发系统
面对如此多的问题，我们采取了“先稳再扩”的思路：先做容灾保障，再逐步提升系统吞吐能力。整体技术方案如下：
架构层面：服务化 + 异步解耦
我们将原本的单体系统拆分为多个独立服务，包括订单中心、库存中心、支付中心、日志中心等，并通过RPC进行通信。每个服务都可以独立部署、升级、扩容。
为了缓解突发流量冲击，我们在关键路径中引入了消息队列异步处理机制。例如下单流程中的风控校验、库存扣减，不再同步执行，而是通过Kafka异步推送任务，由消费端慢慢处理。
这样做的好处是：
- 减少了主线程等待时间
- 提高了系统的容错能力和伸缩性
- 可以利用批量处理减少对数据库的压力
数据库层面：读写分离 + 分库分表
我们对MySQL做了读写分离，主库只负责写操作，从库用于读取历史订单信息。为了避免大表带来性能问题，我们选择了按order_id哈希分表，将一张表拆成16张物理子表。
另外还引入了Sharding-JDBC作为分片中间件，配合Spring Boot直接使用起来还算平滑。
缓存层：多级缓存组合拳
我们采用了本地缓存 + Redis双缓存策略。本地缓存使用Caffeine，针对高频读取的数据做小范围缓存；Redis则作为全局共享缓存，用来存放热点商品库存、用户积分、优惠券状态等信息。
同时，缓存设置了自动降级机制：当Redis不可用时，可以回退到数据库，虽然速度慢一些，但不至于整个系统瘫痪。
容错机制：断路熔断 + 限流降级
我们引入了Resilience4j来实现断路器模式。当某个下游服务出现连续失败时，立即熔断，避免持续发送无效请求加重负载。
同时，在网关和服务内部使用Sentinel实现了API级别的限流降级。比如“下单”这个接口每秒最多允许处理2万次请求，超出部分会被拒绝并返回友好的提示，而不是堆栈溢出或者超时。
日志和监控：全链路追踪必不可少
我们整合了Zipkin、Prometheus和Grafana，为每个请求加上Trace ID，并记录调用链上的所有操作，方便后期排查问题。特别是压测阶段，这种可观测性帮助我们快速定位瓶颈点。
此外，我们还在生产环境加了Sentry异常上报系统，实时抓取线上异常堆栈，提升了排障效率。
关键代码实践与配置示例
1. Sharding JDBC 分库分表示例（Spring Boot）
spring:
shardingsphere:
rules:
sharding:
tables:
order_info:
actual-data-nodes: ds$->{0..1}.order_info_$->{0..7}
table-strategy:
standard:
sharding-column: order_id
sharding-algorithm-name: order-table-inline
key-generate-strategy:
column: id
key-generator-name: snowflake
sharding-algorithms:
order-table-inline:
type: INLINE
props:
algorithm-expression: order_info_$->{order_id % 8}
key-generators:
snowflake:
type: SNOWFLAKE
2. 使用 Kafka 异步解耦下单核心逻辑
// 下单主流程伪代码
public Order createOrder(User user, Product product) {
// 前置校验...
Order order = new Order(...);
order.setStatus("CREATED");
orderService.save(order); // 写入DB
// 向Kafka发送一条事件消息
kafkaProducer.send(new ProducerRecord<>("order-create",
objectMapper.writeValueAsString(order)));
return order;
}
// 消费者异步处理
@KafkaListener(topics = "order-create")
public void processOrderCreate(String message) {
Order order = objectMapper.readValue(message, Order.class);
inventoryService.reduceInventory(order.getProductId());
notificationService.sendUserEmail(order.getUserId(), "您的订单已创建");
}
3. Sentinel 流控规则配置（代码嵌入式方式）
@Bean
public FilterRegistrationBean<SentinelWebFluxFilter> sentinelFilter() {
FilterRegistrationBean<SentinelWebFluxFilter> registration = new FilterRegistrationBean<>();
registration.setFilter(new SentinelWebFluxFilter());
registration.addUrlPatterns("/*");
return registration;
}
// 初始化限流规则
private void initFlowRules() {
List<FlowRule> rules = new ArrayList<>();
FlowRule rule = new FlowRule();
rule.setResource("/api/order/create");
rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
rule.setCount(20_000); // QPS上限2万
rules.add(rule);
FlowRuleManager.loadRules(rules);
}
踩坑经验分享：那些你不知道会掉进去的坑
高并发系统的设计远不像写个Hello World那样简单，下面这些“坑”，我都一个一个踩过：
1. 乐观锁没加好，导致资金损失！
有一次，在库存扣减环节，我们采用的是基于库存数量的乐观锁机制。然而，由于并发太高，两个线程几乎同时读到同一个库存值并各自扣减了一次，最终导致实际库存变成了负数。
后来我们改成了CAS操作结合分布式锁（Redis Redlock），并且增加了库存预警功能。
教训：不要迷信乐观锁，必须结合幂等+锁机制，确保原子操作安全。
2. Kafka积压数据，消费者崩溃重启后重复消费
当时我们的消费端在处理消息过程中抛了异常，导致事务未提交，消费者自动重连后又重新拉取了那条消息。结果同一笔订单被执行了两次扣库存操作。
解决方法是引入消费幂等机制：每个消息生成唯一ID，记录到DB中，如果发现重复ID就跳过处理。
教训：所有异步任务都要有幂等性设计，防止重复消费或丢失。
3. Redis雪崩：大量Key同时失效，击穿DB
某天凌晨，系统例行刷新了一批促销商品的缓存，TTL设置为一小时，结果在同一时刻全部失效。接下来的几分钟内，数据库承受了巨大的访问压力，差点宕机。
后来我们改为随机过期时间，并在服务端做了缓存预热策略。
教训：永远记得给缓存设不同的有效期，并做好降级预案。
4. 生产环境不配线程池，后果很严重
刚开始为了追求“高性能”，我们所有的IO操作都是阻塞式的，也没有限制线程数量。结果一次大促活动期间，线程被占满，整个应用直接假死。
后来我们统一采用线程池管理，并设置了合理的最大连接数和队列长度。
上线后的效果总结
这次重构上线后，我们在压测环境下进行了多次测试，结果如下：
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 单机QPS | <1000 | >15000 |
| 下单平均响应时间 | ~800ms | <180ms |
| 全链路成功率 | ≈90% | >99.99% |
| 大促期间可用率 | 最低70% | 99.95% |
| DB连接数 | 经常爆满 | 稳定在50以下 |
不仅如此，运维成本也大幅下降，因为我们可以灵活地进行水平扩展和自动恢复。最重要的是，产品经理终于不用再盯着我们要“救火”了，团队信心也大大提升。
我的经验总结与建议
如果你正在设计一个高并发系统，以下几点是我亲身体会下来的关键建议：
✅ 先保稳定，再求性能
高并发从来不是一味地追求快，而是要稳中求胜。先做容灾、限流、熔断、降级，再考虑怎么提升吞吐量。不然哪怕性能再强，一个雪崩就能把你打得满地找牙。
✅ 所有异步操作必须具备幂等能力
无论是MQ、RPC、还是HTTP接口，只要是异步操作就可能重复执行。必须做幂等判断，避免数据混乱。
✅ 不要过度设计，但要预留扩展空间
高并发系统往往会陷入“设计过度”的陷阱，比如一开始就把几十个微服务拆得七零八落。其实初期服务少一点没关系，只要设计合理，未来拆开也很方便。关键是接口边界清晰、职责单一。
✅ 关注每一个细节，哪怕是日志格式
有时候你以为是系统性能问题，其实是日志级别没设好，或者打印了太多冗余内容，导致磁盘IO飙升。日志规范化、结构化输出，能帮你在关键时刻节省大量时间和精力。
结语
高并发系统的设计没有捷径，只有不断踩坑、调试、优化才能摸透它的脾气。这篇文章讲的是我个人的经历，但背后是我们整个后端团队的共同努力。
希望你能从这篇文章中找到一点启发，少走些弯路。毕竟，经历过一场大战的程序员，才知道什么是真正的并发压力。
如果你也有类似经验，欢迎留言交流，让我们一起成长！
评论 0