并发数是指同一时间段内，系统能同时处理多少个请求或任务。它和QPS（每秒查询数）常被混用，但说的不是一回事。QPS看的是单位时间内的请求总量，并发数看的是此刻有多少请求还没处理完。两者的换算也很直接：一个接口平均耗时500毫秒，每秒能处理的请求数大约等于并发数除以0.5秒。估算容量时经常用到这个换算。
在阿里云上，并发能力通常同时受几层约束：负载均衡实例、应用服务实例、数据库连接、函数计算的实例并发度、API网关的流控策略，以及账号级的资源配额。哪一层先到顶，整体吞吐就跟着卡住。所以排查时要一层层看，只盯着应用代码，往往找不到问题。
常见产品的并发限制在哪里
各产品的并发限制形式差别不小。下面是最常遇到的几类。具体数值以控制台和官方文档的当前说明为准，配额可能随版本和地域调整。
- 负载均衡（SLB）：关注最大连接数、新建连接速率和带宽上限。规格选小了，连接数可能比CPU先耗尽。
- 云数据库RDS：最大连接数跟实例规格挂钩。应用侧连接池开得太大，高峰时很容易把数据库连接打满。
- 函数计算（FC）：有实例级并发度，单个实例能同时处理多少请求由配置决定，整体还受账号资源配额约束。
- API网关：一般用QPS限流策略控制单个接口或单个租户的请求速率，超出的部分会返回限流错误。
- ECS云服务器：并发主要取决于vCPU、内存和网络带宽。线程数设置不合理时，机器明明有空闲资源，请求也会排队。
案例：一次促销活动前的容量评估
某家做本地生活服务的团队，计划在周末做一次限时抢购。核心链路包括网关、应用服务、缓存和订单库。业务方预计高峰期每分钟有约12000次下单请求，团队先折算成每秒200次的峰值，再按接口平均耗时280毫秒估算，需要的并发大约是56。
接下来逐层核对。应用服务部署了4台ECS，每台开了30个工作线程，理论并发上限是120，看起来绰绰有余。但压测时单台机器的CPU已接近八成，说明可用并发远低于线程数。压测还显示，单机CPU到70%左右时延迟开始明显上升，于是团队把每台的有效并发按25计算，总量约100，仍有余量。
问题出在数据库。订单库的连接池每个应用实例配了50个连接，4台合计200，而RDS实例的最大连接数低于这个值。压测时大量报出“连接数超限”。团队随后把每实例的连接池调到20，在应用侧加了排队机制，并把库存校验从数据库挪到缓存中完成，数据库的实际压力因此降了不少。
活动当天，网关层额外加了接口级限流，防止个别异常客户端占满资源。高峰期订单接口的成功率保持在99.5%以上，超时请求主要集中在被限流的异常流量上，核心用户几乎没有感知。
如何估算自己需要的并发数
可以先用一个简单公式：所需并发约等于峰值QPS乘以平均响应时间（秒）。比如峰值QPS是300，平均响应时间0.2秒，所需并发约为60。这是理想值。实际规划时一般要留30%到50%的余量，给慢请求、GC停顿和网络抖动留出空间。
估算时有两处容易出错。一是平均耗时不能只看正常情况，应当用压测或线上的P95、P99数据，因为长尾请求往往决定线程和连接被占用多久。二是链路上每个依赖都要单独算。最终并发由最弱的那一环决定，其他环节再快也救不了整体。
提升并发能力的几个做法
- 先压测，再扩容：没有数据就先加机器，多半只是把瓶颈挪到别处。
- 连接池要按总量算：连接数不是越大越好。数据库端的连接上限要和应用实例数一起算，不能各自拍脑袋定。
- 用缓存和异步处理削峰：读多写少的数据放进缓存，非核心的写操作交给消息队列，能压低瞬时并发。
- 网关和应用两层分级限流：优先保护下单这类核心接口，异常流量在外层拦住。
- 提前查配额：大促前检查账号级资源配额，需要的话提交工单调整。别等活动当天才发现顶到了上限。
几点注意事项
控制台显示的配额不等于实际可用能力，最终以压测结果为准。自动伸缩有冷启动时间，突发流量来得快时扩容可能跟不上，提前预热或预留实例更稳妥。并发相关参数改动后要验证，先在测试环境跑通，再分批灰度到生产环境。
