高并发和海量数据，不只是背几个架构名词

很多系统一开始都很朴素。

一个商品详情页，一个下单接口，一张订单表，再加一个后台列表。访问量不大时，一切都很顺：页面打开很快，订单写入正常，后台报表也能查出来。

后来业务做了一场活动。

活动页被转发，商品详情访问量上来了；下单接口开始排队；订单表越来越大；后台报表一查就是几百万行；支付回调、库存扣减、优惠券核销逐渐拆成不同服务；某天用户说“页面很慢”，团队却不知道到底慢在哪里。

高并发和海量数据，很多时候就是这样来的。不是某天突然需要一套复杂架构，而是一个原本能跑的小系统，在流量、数据、链路和故障面前，一步步暴露出原来的边界。

这个系列想讲的，就是这个过程。

我后来复盘这种系统时，最有感觉的不是架构图，而是活动开始前那几分钟的气氛。

运营在群里盯着转化，客服在等用户反馈，技术这边盯着监控大屏。CPU、连接数、队列堆积、错误率，哪个指标先抬头，基本就能看出系统最薄的那一层在哪里。

这时候再去背“缓存、分库分表、消息队列”这些名词，已经有点晚了。真正要紧的是，你得知道每个手段到底在替谁挡压力，又会把压力转移到哪里。

系列主线 高并发不是从组件开始的，而是从“系统哪一层先扛不住”开始的。

缓存、MQ、分库分表、限流这些方案，只有放回真实压力链路里，才知道该不该用、什么时候用。

一、先把问题放到一个系统里

我会用一个虚拟但很常见的系统贯穿整个系列：活动商品与订单系统。

它有这些能力：

它一开始可能只是：

Web / App
  -> API 服务
  -> MySQL

后来随着业务增长，它会逐步引入缓存、读写分离、消息队列、服务拆分、报表库、限流、熔断、灰度、监控和容量规划。

这些技术不是为了显得架构很高级，而是因为系统真的走到了某个阶段，不处理就会出问题。

演进路线 一个小系统变复杂，通常不是一步到位，而是一层一层被压力推着走

读压力上来 商品详情、活动配置被反复访问，数据库开始吃紧。

写链路变长 订单、库存、优惠券、支付开始互相牵扯。

数据越堆越多 报表、日志、历史订单逐渐拖慢在线系统。

故障要能收住 限流、降级、回滚、监控开始变成必需品。

这个系列后面的每一篇，都会围绕其中一个压力点展开。

第一种是八股式写法。

比如一上来就列：缓存穿透、缓存击穿、缓存雪崩、热点 Key、大 Key。知识点都对，但读者读完可能还是不知道这些问题为什么会在真实系统里出现。

第二种是组件式写法。

比如 Redis、MQ、分库分表、微服务、多活，每个词都很熟，但如果不知道它解决哪个瓶颈，很容易变成技术堆叠。

我更想把每篇都写成一个问题：

这个系统走到这里，为什么开始扛不住？
哪些方案能缓解？
每个方案又会带来什么新成本？
如果是我，会先做哪一步？

这样读起来会更慢一点，但更接近真实架构设计。

第一篇讲缓存。活动商品详情页访问量上来后，数据库最先感受到压力。缓存不是为了“显得快”，而是为了让数据库活下来。

第二篇讲数据库。订单表从几万到几千万，后台列表和查询开始变慢。这个时候不能只说“优化 SQL”，要看索引、分页、锁、事务和数据拆分。

第三篇讲海量数据。历史订单、日志、报表、文件、时序数据如果都挤在在线库里，系统会越来越钝。

第四篇讲消息队列。活动下单峰值来了，同步链路开始超时，MQ 可以削峰和解耦，但它只是把压力换了一个地方。

第五篇讲分布式一致性。订单、库存、优惠券、支付拆开以后，问题从“一个事务能不能提交”变成“多个系统最后能不能对齐”。

后面还会继续讲服务保护、热点流量、系统可用性、可观测性和架构方法论。

如果只用一句话概括这个系列，我会这样说：

高并发架构不是把技术组件堆满，而是在系统变复杂的每一步，知道该保护什么、拆开什么、延迟什么，以及失败后怎么收回来。

所以读这个系列时，不必急着记住每个方案。更重要的是看见判断顺序：

希望这个系列最后留下的，不是一堆术语，而是一套能在真实项目里慢慢用起来的判断方式。