高并发系统设计：从踩坑到奔跑的实战笔记
引言：一次双十一的压力测试让我彻底醒悟
记得那是我刚加入一家电商平台做架构师不久，正值大促季前的压测阶段。我们当时的系统在模拟千万级访问的时候，直接挂了——数据库连接池爆满，Redis频繁超时，服务响应时间飙升到了5秒以上。最夸张的是，连日志都开始丢，监控数据也断断续续。
那一刻我意识到：高并发不是理论题，是生死线。
今天我想和大家分享一下这些年我在高并发系统设计方面踩过的坑、走过的弯路，以及总结下来的一套比较靠谱的设计思路。这篇文章不会给你“标准答案”，但会告诉你，在现实项目中，该怎么一步步扛住百万甚至千万级别的并发请求。
项目背景：我们的系统到底要干嘛？
先说说这个项目的背景。我们是一家电商SaaS平台，主要为中小商家提供建站、订单管理、营销工具等服务。某天，公司接了个大客户，是家头部美妆品牌，他们的年货节活动要全部用我们的系统承载。
他们给的数据预期很震撼：
- 活动当天预计流量峰值约1000万UV
- 核心页面QPS预估超过20w（尤其是限时秒杀）
- 同时有大量订单写入，需保证库存准确性
- 整体可用性目标99.99%以上，故障恢复不能超过3分钟
这意味着，我们的系统必须在高并发下保持高性能、低延迟、高稳定。当时我们原有的架构已经有点撑不住了，必须重新设计。
挑战来了：这些锅我都背过
第一锅：数据库压力太大，扛不住
最典型的问题就是数据库连接池被打满。我们的核心业务都依赖MySQL，而默认的Spring Boot连接池只有几十个连接。在高并发场景下，大量请求排队等待获取DB连接，导致整个系统卡顿。
我记得有个接口，查用户积分，本来只需要10ms，但在高峰时段，直接涨到500ms+，而且失败率暴涨。
第二锅：缓存穿透 & 缓存击穿，Redis崩了不止一次
当时Redis用了默认配置，没有任何限流机制。某个爆款商品信息被疯狂查询，缓存失效的一瞬间，上万个请求全打到DB上，直接把DB拖慢。
更惨的是还有缓存穿透的情况。有个爬虫攻击我们，疯狂查不存在的商品ID，每次都穿透到数据库。DB扛不住就挂了，整个服务直接雪崩。
第三锅：接口设计不考虑幂等性，重复下单炸了库
当时我们的订单创建接口没有做好幂等控制。用户点单时网速慢了点，前端自动重试三次，结果后端每次都会生成新订单。一个用户下了三个同样的订单，后来退款都处理了好久。
这说明我们在接口设计层面，缺乏对高并发下的容错能力和状态一致性保障。
解决方案：稳扎稳打，一步步构建抗压系统
下面我会分几个关键模块来谈我们的解决方案。这些都不是纸上谈兵，而是真实踩过坑之后，反复优化的结果。
一、架构设计：分层+冗余+解耦
首先我们重构了整体架构，采用典型的多层设计：
- 接入层：Nginx + Keepalived 实现负载均衡与故障转移
- 应用层：微服务架构（Spring Cloud），按业务划分多个服务模块
- 缓存层：Redis集群 + Caffeine本地缓存
- 数据库层：主从分离 + 分库分表（ShardingSphere）
- 消息队列：Kafka实现异步解耦和削峰填谷
- 监控报警：Prometheus + Grafana + ELK + 告警系统集成
这套结构的关键是：每一层都要能单独扩容、独立部署，避免出现单点故障影响全局。
二、数据库优化：分库分表 + 读写分离
分库分表：横向拆分是必然
我们采用了基于ShardingSphere的分库分表策略，比如订单表按照用户ID哈希分片，商品库存则按照SKU ID进行水平切分。
这样一来，原本一张几千万条记录的大表被拆成几十个小表，每个节点承受的压力骤降。
读写分离：主从同步缓解压力
对于读多写少的场景，比如商品详情页，我们做了主从复制。通过Spring的AbstractRoutingDataSource实现了简单的读写分离，写操作走主库，读操作随机分配到从库。
效果非常明显。原来一条SQL执行要1秒的，在加上索引、读写分离之后，现在控制在200ms以内。
三、缓存策略：多层防御机制
本地缓存：Caffeine解决高频热点
我们使用Caffeine作为本地缓存层，比如用户登录信息、SKU基本信息这类读取频率极高、更新相对低频的数据。命中本地缓存后，几乎可以做到无延迟响应。
Redis缓存：加锁防击穿，布隆过滤器防穿透
我们针对缓存击穿问题，引入了互斥锁机制（setIfAbsent）。当发现缓存为空时，第一个请求去DB拉数据，并设置锁，其他线程等待一段时间再重试。
同时为了防止缓存穿透，我们引入了布隆过滤器，用于判断数据是否存在。对于明显非法的请求（如不存在的ID），可以在入口处就拦截掉。
缓存更新策略：TTL + 主动刷新结合
为了避免缓存脏数据，我们采用了TTL机制（根据业务不同设为几分钟到几小时），同时结合定时任务主动刷新缓存。例如，库存数据每小时主动同步一次。
四、接口设计：幂等性、限流、熔断一个都不能少
幂等性设计：唯一Key + 状态判断
我们为所有重要的写操作增加了幂等控制。比如在提交订单接口中，除了前端传入的订单ID，还会检查当前用户的该订单是否已存在，防止因网络波动或用户误操作导致的重复请求。
接口限流：令牌桶 + 分布式限流
我们使用Guava的RateLimiter实现本地限流，但更关键的是引入了Redis+Lua脚本的方式实现分布式限流。比如限制用户每分钟只能抢购3次，防刷效果非常好。
熔断机制：Hystrix + Sentinel兜底
早期我们用Hystrix做熔断，后期换成Sentinel，因为后者支持动态规则调整、集群流控等功能更强大。当某个服务异常或响应变慢时，可以自动切换降级策略，不至于影响整体流程。
五、异步解耦：消息队列削峰填谷
我们把一些非实时的操作抽出来，比如发短信、发邮件、通知推送等放到Kafka队列中异步处理。高峰期，Kafka帮我们缓冲了大量请求，让主线业务流程更加轻快。
比如下单操作，只要把订单写入DB并通知MQ即可返回，后续的优惠券发放、物流信息准备都可以通过消费MQ来完成。
另外，Kafka还帮我们做了一些数据聚合的工作，比如实时统计销量排行、点击趋势图等。
六、运维层面：灰度发布 + 监控告警
灰度发布降低风险
上线前我们会先发一部分实例到线上测试环境，通过路由规则把部分用户引流过去观察效果。确认没问题后再逐步扩大范围。
监控+报警闭环机制
我们搭建了完整的监控体系：
- Prometheus采集指标：CPU、内存、QPS、错误率等
- Grafana展示看板：一目了然看到系统运行情况
- ELK收集日志，定位问题更快
- 微信/钉钉/电话三级报警机制，确保重要事件第一时间响应
特别是预警这块，我们设置了多个阈值触发条件，比如连续5分钟TP99超过2s，就会自动发送紧急通知。
实施后的效果：从崩溃边缘到游刃有余
经过几个月的重构与调优，我们的系统在真正的大促中表现相当稳健：
- QPS轻松突破20万，接口平均响应时间控制在300ms以内
- 错误率低于0.1%，用户基本感知不到异常
- 数据一致性得到保障，订单未发生一例重复
- 容灾能力强，即使某个Region出问题，也能快速切换到备用机房
最重要的是，我们团队的底气足了。以前遇到高并发就紧张，现在反而觉得心里更有谱了。
经验分享：写给正在路上的你
如果你也在处理类似的需求，或者正准备接手一个高并发项目，以下几点建议值得参考：
1. 不要一开始追求极致性能，优先做可扩展设计
很多同学一开始就想着要做多少层缓存、怎么分库分表，其实更重要的是结构清晰、可拆可合。先能跑起来，后面慢慢优化。
2. 多用组合拳，不要靠单一手段解决问题
比如缓存设计，不只是Redis就够了，还需要本地缓存、布隆过滤器、锁机制配合使用。接口限流也是，本地限流+分布式限流一起上才稳妥。
3. 代码写得好不如架构设计好，架构设计好不如测试验证充分
一定要做压测！一定要做压测！一定要做压测！
我们早期就是忽略这一点，等到上线才发现各种瓶颈。压测不仅能暴露性能问题，更能让我们提前预判系统的极限在哪里。
4. 日常维护比架构设计更容易决定成败
再牛的架构，如果没有人运维、没人看监控、没人做预案，出了问题照样抓瞎。运维人员和开发人员要形成合力，制定明确的应急预案，关键时刻才能顶得住。
5. 技术趋势要跟，但别盲目追新
现在很多云原生、服务网格的概念确实火，但并不是每个团队都适合。比如我们当时就没用Service Mesh，而是选择了成熟的Spring Cloud生态，落地更平滑，风险更可控。
写在最后：高并发不是终点，而是一种常态
这几年，我们经历了不少大考。双十一、618、跨年促销……每一次都是压力山大，但也正是这些挑战，逼着我们不断成长。
高并发系统的设计从来就不是一蹴而就的事情，它是持续改进、不断迭代的过程。你要做的不是一次性搞定，而是建立一套可持续演进的架构体系。
愿你在自己的项目中，也能像我们一样，从崩溃边缘走到从容应对。
如果你在这条路上遇到了什么难题，欢迎留言，我们可以一起探讨。
共勉。
评论 0