Docker容器无直接“并发请求上限”参数，真实限制来自应用层配置（如Nginx的worker_connections、Node.js的server.maxConnections）、文件描述符限制（需--ulimit nofile=65536:65536）、CPU/内存配额（如--cpus=1.5、--memory=1g）及系统级网络参数（如net.core.somaxconn=65535），须协同配置方能生效。
在 Docker 中，容器本身没有“并发请求上限”这个直接参数，真正起作用的是应用层配置、系统资源限制和运行时配额三者的协同。单点设置容易失效，必须分层控制。
应用层限流（最常用且推荐）
这是离业务最近、最可控的一层，不同服务有标准做法：
-
Nginx：在
events块中设worker_connections 4096，再用limit_conn按 IP 或 server_name 限制连接数，例如：limit_conn_zone $binary_remote_addr zone=addr:10m;limit_conn addr 100; -
Node.js：对
http.Server实例设置server.maxConnections = 200，并确保启用keep-alive复用连接，避免频繁建连耗尽 fd -
MySQL：在
my.cnf的[mysqld]下设max_connections = 300；注意若容器内ulimit -n未调高，该值可能被卡死在默认 214 -
Go/Java 等自研服务：使用内置限流器（如 Go 的
golang.org/x/time/rate）或中间件（如 Spring Cloud Gateway 的RequestRateLimiter）按 QPS 或并发数拦截
文件描述符与 socket 限制（底层硬门槛）
每个 TCP 连接至少占用 1 个文件描述符（fd）。Linux 默认单进程最多打开 1024 个 fd，高并发场景下会直接触发 EMFILE 错误，导致新连接失败。
- 启动容器时加参数：
--ulimit nofile=65536:65536 - Docker Compose 写法：
ulimits:nofile:soft: 65536hard: 65536 - 进容器执行
ulimit -n验证是否返回65536 - 宿主机还需调大内核参数（尤其连接数破万时）：
sysctl -w net.core.somaxconn=65535sysctl -w net.ipv4.tcp_max_syn_backlog=65535
CPU 与内存配额（保障限流策略落地）
即使应用层设了 1000 并发，若容器只分配了 0.2 核 CPU 或 128MB 内存，请求照样排队、超时甚至被 OOM Kill。
- CPU 控制：
--cpus="1.5"（更精确可用--cpu-quota=150000 --cpu-period=100000） - 内存控制：
--memory=1g --memory-swap=1g（禁用 swap 防止延迟毛刺） - 进程数限制：
--pids-limit=200（防 fork 炸弹，对 PHP-FPM、Java 类应用特别关键）
网络与调度协同（进阶但必要）
当并发规模持续上万，还需考虑网络栈和编排层配合：
- 反向代理前置：用 Nginx 或 Envoy 做统一入口限流，比每个容器单独配置更集中、易维护
- 避免盲目堆容器：通过
docker info | grep Containers监控宿主机容器总数，结合/proc/sys/kernel/pid_max预估上限 - Kubernetes 用户应设
resources.requests和limits，并启用LimitRange统一约束命名空间行为 - 不建议为限流目的启用
--network=host，除非低延迟刚需；桥接模式下内核参数调优效果有限
