大促、直播带货、票务开售，这些场景最让人头疼的往往是几万个请求在同一分钟撞进来。不少团队把系统搬上云以后以为问题解决了，结果瓶颈只是换了个地方：数据库连接数打满，网关开始超时，日志量一下子涨上来。所以聊阿里云并发怎么扛之前，得先弄清楚每一层能干什么、该怎么配合。
并发到底在量什么
并发通常看三个数字：QPS（每秒请求数）、同时在线的连接数，以及单个请求的响应耗时。这三个往往一起变坏。QPS 上去了，耗时跟着拉长，连接占着不放，最后整个池子堵死。
本地机房扛并发，主要靠买硬件和加带宽，扩容要等采购、上架，周期按周算。上云后资源可以按需申请、用完释放，好处是快，代价是架构必须能自己伸缩。如果还要靠人盯着监控、手动加机器，等人反应过来，高峰可能已经过去，或者系统已经挂了。
四层各管什么
接入层：负载均衡
负载均衡（SLB）是流量进来的第一道门，把请求分到多台后端服务器上，避免某一台先被压垮。配合健康检查，异常节点会被自动摘掉。上线前要核对的不只是后端数量，还有监听器的连接数上限、带宽峰值和会话保持策略。这几项任何一个先到顶，后端机器再多也用不上。具体规格以阿里云官网文档为准，别凭印象估。
计算层：弹性伸缩
弹性伸缩（ESS）可以根据 CPU 利用率、内存或自定义指标，自动增减 ECS 实例。规则最难调的是节奏。扩得慢，流量已经把服务压垮；缩得太快，波动一下就来回抖。有些团队会从 70% 左右的扩容阈值起步，配一段冷却时间，观察几轮再调。如果业务以容器为主，可以在容器服务 ACK 里用 HPA 按指标调整 Pod 数量，思路一样，只是粒度更细。
数据层：连接池与缓存
很多并发事故最后都落在数据库上。应用层再能扛，如果每个请求都直接连 RDS，连接数很快就见底。有两件事值得先做。一是连接池大小要按数据库能承受的上限来定，别让每个实例随便新建连接。二是把热点数据，比如商品详情、活动页配置这类读多写少的内容，放进 Redis，让大部分读请求在缓存层解决。写入冲突多的场景，可以把下单之类的请求先放进消息队列，异步排队处理，避免同一时刻全部砸向库表。
防护层：限流与降级
前面几层都做好了，流量超过设计容量时仍然需要自我保护。API 网关可以按接口、用户或 IP 设置限流，超出的请求直接返回一句能看懂的提示，比整个系统一起卡死强得多。另外，给推荐、评论这类非核心模块加上降级开关，高峰时先关掉，把资源让给下单和支付。降级开关最好提前测过一次，不然真到了那一刻，开关本身可能都打不开。
一个假设的改造过程
设想一家零售品牌准备做秒杀，预计峰值会远超平时。最初的架构是一组 ECS 直连 RDS，压测时连接数很快接近上限，超时开始集中出现。
改造大致分三步。先在 SLB 后面放多可用区的 ECS 集群，开启弹性伸缩，扩容同时看 CPU 和请求队列长度，单看一个指标容易误判。再把商品详情和库存查询迁到 Redis，库存扣减改成预扣减加异步落库，数据库只负责最终写入。最后在网关给秒杀接口做分层限流，把推荐、评价模块的降级开关准备好。
同样的流量再压一次，数据库连接数回到了安全水位，接口响应也稳了不少。这个例子只是为了说明思路，具体数字要以自己的压测结果为准。它想说明的是：每层都动一点，系统才撑得住，只靠其中一层很难扛住整条链路。
上线前可以先做的几件事
- 做一次全链路压测。瓶颈通常不在你以为的地方，压一次比猜十次有用。
- 给弹性伸缩设好最小和最大实例数。最小值太低，突发流量来了扩不过来；最大值不设，账单可能比流量涨得还快。
- 监控至少覆盖 QPS、响应时间、错误率和数据库连接数，并给每项设告警阈值。
- 限流和降级规则要在预发环境演练过，别让大促当天才第一次用。
- 配额和规格变化较快，动手前对照阿里云官网最新文档，架构里留出一些余量。
落到实处，还是三件事：分层扛压、弹性扩容、主动保护。每层的职责划清楚，再用压测和监控把它们串起来，高峰期才不容易手忙脚乱。
