nginx多进程架构本身不按业务类型调度，差异化资源管理依赖配置层策略：通过upstream分组实现路由隔离、worker参数控制资源边界、limit_req与map做限流分级、共享内存协同状态。
nginx 多进程架构本身不按“业务类型”做差异化调度，它面向的是连接和请求的通用处理；真正实现不同业务类型的资源倾斜与隔离，靠的是配置层的组合策略，而不是进程模型本身。
用 upstream 分组实现业务路由隔离
把不同业务（如 API、静态资源、上传服务）拆成独立的 upstream 块，再通过 location 或匹配规则分别 proxy_pass 到对应分组：
- 每个 upstream 可设不同后端、不同负载策略（比如 API 用 least_conn，静态资源用轮询）
- 可为各分组单独配置超时、重试次数、健康检查参数（如上传服务放宽 max_fails，API 要求更严）
- 避免所有业务共用同一套后端池，防止慢接口拖垮快接口
通过 worker 配置控制资源边界
虽然所有 worker 进程逻辑一致，但可通过以下方式间接影响业务承载能力：
- 设置 worker_connections 保证单个进程能承载足够并发，尤其对长连接类业务（如 WebSocket）需调高
- 用 client_max_body_size 和 client_body_buffer_size 限制上传类请求的内存占用，防止单个大文件耗尽 worker 内存
- 对高优先级业务（如登录接口），可在 location 中启用 proxy_buffering off 减少缓冲延迟
借助限流与优先级机制做业务分级
在请求进入阶段就区分业务重要性，避免低优业务挤占资源：
- 用 limit_req 按 location 或 $uri 对不同路径限速（如 /api/v1/report 限 10r/s，/healthz 不限）
- 结合 map 指令提取业务标识（如 header 中的 x-service-type），动态设置限流键或 upstream 名称
- 对关键路径启用 proxy_next_upstream error timeout http_500，提升容错率
利用共享内存支持跨进程状态协同
多个 worker 共享同一份 upstream 状态，是实现业务感知的基础：
- 通过 zone backend_health 64k; 定义共享内存区，让所有 worker 实时同步后端健康状态
- IP Hash 或一致性哈希依赖共享哈希空间，保障会话类业务在任意 worker 上都能路由到同一后端
- least_conn 算法需要汇总各 worker 的当前连接数，也靠共享内存传递统计值
不复杂但容易忽略
