高并发下docker容器必须刚性限制资源、启用host网络、调优共享内存与存储驱动、解耦启动依赖。例如：--cpus="2.5" --memory="2g" --pids-limit=200 --network=host --shm-size=256m，并预热镜像、配置健康检查。
高并发系统对 Docker 容器的配置不是“堆资源”就能解决的，关键在于精准限制、网络直通、调度协同和启动可靠。配得不对，容器跑得越快，系统崩得越脆。
资源限制必须刚性设定
CPU 和内存不设限，等于给单个容器发了一张“无限透支卡”，容易拖垮整台宿主机。 - 用 `--cpus="2.5"` 而非 `--cpu-shares`：前者是硬上限，后者只是权重比，在争抢时无效 - 内存必须双保险：`-m 2g` + 应用内 JVM 的 `-Xmx1800m`（Java）或 Node 的 `--max-old-space-size=1500`，避免 OOM Killer 杀错进程 - 加上 `--pids-limit=200`：防止连接数暴涨导致 fork 爆满，这是很多 Web 服务在 5000+ 并发时静默失败的根源示例命令：
docker run -d \ --cpus="2.5" \ --memory="2g" \ --pids-limit=200 \ --shm-size=256m \ -p 3000:3000 \ myweb:v1
网络模式选 host 而非 bridge
Docker 默认 bridge 模式在 5000 并发下吞吐量比 host 模式低 45%，因为每条连接都要经过 NAT 转换和 conntrack 表查表。 - 高并发 Web/API 服务直接用 `--network=host`，让容器复用宿主机网络栈 - 同时启用 TCP BBR 拥塞控制：`echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf && sysctl -p` - 扩大连接跟踪表：`echo "net.nf_conntrack_max=1048576" >> /etc/sysctl.conf`注意：host 模式下端口冲突需靠应用监听逻辑规避（如统一用 8080），而非靠 Docker 映射。
共享内存和存储驱动要调优
默认 `/dev/shm` 只有 64MB，但 Nginx 缓存、Redis 通信、Node.js worker_threads 共享数据时极易打满。 - 启动时加 `--shm-size=256m`（Web 类）或 `--shm-size=1g`（音视频/ML 推理类） - 存储驱动必须用 `overlay2`（CentOS 7.9 默认已支持），禁用 `devicemapper`——后者在高 IOPS 下延迟抖动剧烈 - 若容器频繁读写日志或临时文件，挂载 `tmpfs` 卷替代磁盘路径：`--tmpfs /app/logs:rw,size=100m`启动链路必须解耦依赖
`depends_on` 不等服务就绪，只等容器创建完成。高并发场景下，应用一启动就疯狂连 DB，连不上就崩溃重启，形成雪崩循环。 - 在应用层做健康等待：比如用 `wait-for-it.sh db:5432 --timeout=60 --strict -- node server.js` - 或用 Docker Compose 的 `healthcheck` + `restart: on-failure` 组合，但探针 `interval` 设为 5s、`timeout` 不超过 2s，避免误判 - 镜像预热：生产环境提前 `docker pull` 所有镜像，杜绝重启时拉取耗时（实测远程拉镜像可使重启从 2s 延至 23s）不复杂但容易忽略
