活动刚开始的那几分钟，最能看出系统扛不扛得住。页面转圈，下单接口超时，数据库连接数顶到上限，运营在群里催。很多团队第一反应是加机器，但真去查日志，问题通常出在架构上的几处短板。几个地方同时卡住，就成了事故。这篇文章以一个电商秒杀场景为例，聊聊阿里云高并发该怎么拆开看、想清楚，再一步步落到实处。
先搞清楚，高并发到底在扛什么
说白了，高并发就是同一时间进来的请求超过了系统能处理的量。这个上限由几层能力共同决定：入口能接多少连接，应用同时能处理多少请求，数据库能承受多少读写，缓存能顶住多少热点访问。哪一层先顶不住，后面的链路都会跟着出问题。
所以动手之前，先别急着升配置。把三个数字算出来：峰值 QPS 大概多少，哪些接口是热点，哪些数据必须强一致。这一步跳过的团队很常见，结果是所有请求都压到数据库上，机器再加也只是多撑几秒。
案例：一次限量秒杀的架构拆解
设想一个电商客户要做限量商品秒杀，活动开始前可能有几十万用户同时抢，库存却只有几百件。如果请求一路穿透到订单服务和数据库，几秒钟连接数就会爆掉。思路是分层削峰，尽量让大部分请求在进入核心链路前就被拦下来。
第一层：负载均衡和弹性伸缩兜底入口
前端流量先经过阿里云的负载均衡SLB，分发到多台ECS实例或容器节点上。SLB支持跨可用区部署，某个可用区出问题时流量可以自动切走，大促场景下这个能力很实用。应用层配合弹性伸缩，可以按CPU、连接数或自定义指标触发扩容。但扩容实例需要启动时间，等指标飙高再扩，往往已经晚了。活动前就该配好定时扩容策略，实时指标只用来做补充。
第二层：静态化和限流，先把无效请求挡在门外
活动页、商品详情这类内容基本不变，直接走CDN和对象存储，别占着应用服务器的资源。抢购接口则要在网关层限流，常见做法是按用户ID或设备维度做令牌桶，超过阈值的请求直接返回排队提示。这里要接受一部分用户抢不到，好过所有人都卡住。限流规则可以用开源的Sentinel，和阿里云微服务体系配合比较顺手，规则还能动态调整。
第三层：缓存扛热点，库存预扣减放到Redis
秒杀商品的库存是典型热点数据。每次下单都去数据库执行一次加锁的UPDATE，性能会很差。更稳妥的做法是活动开始前把库存预热到云数据库Redis版，用原子操作完成预扣减。请求先在Redis里判断库存，不够的直接拒绝，只有预扣成功的请求才进入订单流程。大部分无效请求到这里就结束了，根本碰不到数据库。
缓存本身也有风险。缓存节点挂掉时，热点数据会瞬间全部回源到数据库，也就是缓存击穿。热点key要加互斥重建逻辑，避免大量请求同时去回源。另外开启主从或集群版，单点故障就不至于直接拖垮业务。
第四层：下单异步化，用消息队列削峰
预扣成功的订单没必要同步写库。把订单消息投递到消息队列RocketMQ，由消费端按数据库能承受的速度慢慢落库。用户这边先看到“下单处理中”，再通过轮询或推送拿到最终结果。代价是实时性差一点，换来的是数据库写入压力平稳可控。消费端一定要做好幂等，否则消息重复投递就可能超卖。
第五层：读写分离和分库分表
订单、库存最终还是要落到数据库里。ApsaraDB RDS可以挂只读实例，把查询订单、商品列表这类读请求分流出去。单表数据涨到千万甚至亿级，就该考虑分库分表了。阿里云的分布式数据库方案能帮忙处理路由和扩容，前提是分片键事先设计好，比如按用户ID拆分，尽量减少跨库事务。分片键一旦选错，后面改起来代价很大。
落地时容易漏掉的几件事
- 压测要走真实链路：只压单个接口意义不大。用全链路压测模拟真实用户路径，登录、查询、下单、支付都要覆盖。
- 监控分层看：入口 QPS、接口 RT、缓存命中率、数据库连接数、消息堆积量都要配报警。出了问题，监控是定位的第一手依据，没有它就只能靠猜。
- 降级预案提前写好：比如推荐模块超时就返回兜底数据，评论服务不可用就隐藏入口。目标是别让非核心功能拖垮交易链路。
- 容量留余量：压测得出的上限，用于生产规划时通常要打七到八折，给突发流量和没测到的瓶颈留点空间。
小结
阿里云能提供的是工具，效果好不好，还是看分层思路。入口靠负载均衡和弹性伸缩接住流量，网关用限流挡掉无效请求，缓存和预扣减处理热点，消息队列把写入摊平，数据库再做读写分离和分片。每一层都尽量把压力往前推，让核心数据库只处理必须处理的请求。方案定下来之后，还要靠压测和演练验证，真到流量洪峰那天，心里才有底。
