worker_processes 不支持按业务差异化配置，它是一个全局参数；实际通过配置拆分、独立 reload、资源限制和 cpu 绑定等策略实现业务级隔离与性能优化。
worker_processes 本身不支持按业务差异化配置——它是一个全局参数，所有业务共享同一组 worker 进程。所谓“为不同业务定制策略”，实际是通过组合配置、部署方式与运行时控制来实现效果上的区分，而非让 API 业务用 4 个进程、后台管理用 2 个进程这类直接拆分。
核心原则：进程数不按业务分，但资源和行为可以隔离
每个 worker 进程加载全部 http 配置，对所有 server 块一视同仁。你无法让某个 server 只由特定 worker 处理。真正影响业务体验的是：
- 单个 worker 的连接承载能力（由 worker_connections 和系统 ulimit 决定）
- CPU 调度效率（是否绑定物理核、是否避免超线程争抢）
- 配置变更的生效范围（reload 是否只影响某业务规则）
- 故障影响面（一个 worker 异常，是否波及全部业务）
面向业务场景的实用策略
高并发读多写少型业务（如静态资源、CDN 边缘节点）
可适度提高 worker_processes 数量（如物理核数 ×1.5），配合 multi_accept on 和 epoll 批量收包，提升短连接吞吐。但需压测验证：若 CPU 利用率长期低于 60% 且请求排队明显，才考虑加进程；否则容易引发 accept 锁争抢。
CPU 密集型业务（如全站 HTTPS、复杂 rewrite/geoip 匹配）
严格设为物理核心数（非逻辑核），禁用超线程调度干扰。启用 worker_cpu_affinity auto; 确保每个 worker 绑定独立物理核，减少 L1/L2 缓存失效。此时增加进程数反而导致上下文切换开销上升，性能下降。
多租户或强隔离需求业务（如 SaaS 平台各客户子域）
不靠调 worker_processes，而用配置文件拆分 + 独立 reload 控制。例如：
– /etc/nginx/conf.d/client-a.conf
– /etc/nginx/conf.d/client-b.conf
修改 client-a 的 upstream 后执行 nginx -t && nginx -s reload，client-b 流量完全不受影响——这是真正的“业务级平滑”。
容器与云环境要主动约束
在 Kubernetes 或 ECS 容器中，auto 可能读取宿主机核数，导致启动过多 worker 进程并争抢资源。应显式设置：
– 若分配 2 核：worker_processes 2;
– 若混合部署（Nginx + Redis 共存）：worker_processes $(nproc --all)-1;
同时配好 worker_rlimit_nofile 和系统级 limits，避免“进程够、句柄不够”的典型瓶颈。
本质上，worker_processes 是基础设施层的并发车道数，不是业务路由开关。业务差异化的落脚点，在于配置组织、reload 粒度、资源限制和监控维度，而不是给每个业务单独设一个进程数。
