控制同时在途的请求数
并发限制控制的是同时在途的请求数，与速率限流互补。网关层可以按来源地址限制连接数，应用网关用信号量或队列上限控制在处理的请求量。关键目标是让超出的部分排队或快速失败，而不是无限堆积把延迟一路推高。
基本信息
| 适用平台 | Nginx 网关与自研应用网关 |
|---|---|
| 实现方式 | 连接数限制、信号量、队列上限 |
| 配置位置 | 紧邻流量入口的网关侧 |
| 目标值 | 略高于引擎实际容量，超出部分快速失败 |
Nginx 连接数限制片段
Nginx 连接数限制片段
limit_conn_zone $binary_remote_addr zone=conn:10m;
location /v1/ {
limit_conn conn 20;
proxy_pass http://127.0.0.1:8000;
}典型使用场景
- 过载保护：引擎容量有限，超出的请求要快速失败
- 多租户隔离：给不同调用方设不同上限，避免一方打满全场
- 压测控量：并发固定后测得的分位数才有意义
- 与速率限流配合：速率控到达速度，并发控同时在处理量
- 故障期收紧：过载时临时调低上限，保住已接收请求的成功率
- 灰度期保护：新版本承接能力未确认时，先给一个较小的上限
手段与控制的量
| 手段 | 控制的量 | 典型位置 |
|---|---|---|
| 连接数限制 | 同一来源同时在连的数量 | 网关 |
| 队列上限 | 允许排队的请求数 | 网关或应用层 |
| 信号量 | 同时处理的请求数 | 应用网关 |
| 超时设置 | 单个请求的最长等待 | 网关与客户端 |
网关并发上限建议略高于引擎容量：多出的部分排队，超过则快速失败，而不是无限等待。
并发上限要与超时一起配：只限并发不设超时，少数长请求仍会把队列占满。
记下每次上限调整的原因与时间：并发上限属于运营参数，改动没有记录时，事后无法解释流量曲线的变化。
被拒绝的请求要有明确错误码与说明：调用方看到限流提示才知道该退避，否则只会盲目重试把压力叠上来。
并发上限与实例数量联动：扩了实例要同步调高上限，否则新实例接不到流量，扩容等于没扩。