背景与压力来源
电商平台的并发压力通常不是均匀到来的，而是集中在活动、上新、支付、库存变化和消息通知这些节点。平时系统看起来很稳定，一到峰值流量，真正的瓶颈才会暴露。
我做这类系统时，最深的感受是：不要只盯接口平均耗时。更要看峰值、长尾、数据库连接、缓存命中率、队列堆积、错误率和恢复时间。
高并发架构的目标不是永远不出问题，而是问题出现时系统能扛住、能降级、能定位、能恢复。
分层保护思路
我们会把系统拆成几层保护，而不是期待某一个组件解决所有压力。
缓存不是越多越好
缓存是高并发系统最常用的手段，但缓存也会制造复杂度。什么时候缓存、缓存多久、失效后怎么办、数据不一致能不能接受，这些都必须先想清楚。
- 商品和配置：适合缓存，更新频率低，读多写少。
- 用户状态：谨慎缓存，必须明确一致性边界。
- 库存和支付：不能只靠缓存判断，必须回到核心交易链路。
缓存设计真正难的是异常场景：缓存失效时数据库能不能承受？热点 key 被打爆怎么办？缓存数据错了如何快速修正？这些比“加一层 Redis”重要得多。
数据库要被保护起来
数据库往往是系统最后的事实源，也最容易成为瓶颈。我的原则是：不要让所有请求都直接冲到数据库，尤其不要让复杂查询出现在高频链路里。
| 问题 | 处理方式 | 收益 |
|---|---|---|
| 高频读 | 缓存 + 读库 + 预聚合 | 降低主库压力 |
| 慢查询 | 索引治理 + SQL 审查 + 分页限制 | 减少连接占用 |
| 大表增长 | 冷热分离 + 归档策略 | 保持核心表轻量 |
| 写入尖峰 | 队列削峰 + 批量处理 | 保护核心事务 |
异步化解决的是峰值，不是偷懒
不是所有动作都需要同步完成。下单后发通知、生成统计、写行为日志、更新部分非核心状态，都可以异步处理。关键是区分哪些是用户必须立即感知的，哪些可以延迟。
异步化后，必须补上幂等、重试、死信队列和补偿机制。否则队列只是把问题从接口耗时转移到了后台积压。
限流和降级要提前设计
很多系统出问题，是因为团队不愿意提前定义“保什么、舍什么”。高并发场景下，必须有明确优先级：核心交易优先，查询可降级，推荐可关闭，非关键统计可延迟。
没有监控就没有高并发
高并发系统必须能实时回答几个问题：现在流量从哪里来？哪个接口慢？数据库是否接近上限？队列是否堆积？错误率从什么时候开始升高？
我会把监控拆成四类：业务指标、接口指标、资源指标、链路追踪。只有这些数据齐全，故障复盘才不是猜测。
总结
高并发架构不是一次性设计完成的，它是在真实流量、故障复盘和持续优化中长出来的。真正可靠的系统，一定有边界、有保护、有监控、有演练。
如果只追求单个接口的性能数字，很容易忽略整体韧性。能承受峰值、能局部降级、能快速恢复，才是电商平台长期稳定的关键。
欢迎通过邮件和我交流：shaoyanyan91@163.com
本文首发于邵炎炎个人博客。转载请注明出处。