多进程架构通过隔离、共享与协同控制提升吞吐，优化重点在于减少争抢与干扰。采用共享内存+原子操作替代锁竞争，启用accept_mutex避免惊群效应，绑定CPU核心降低调度开销，由Master统一管理配置与信号，Worker专注请求处理。
多进程架构本身不靠“协作”取胜，而是靠隔离 + 共享 + 协同控制来降低干扰、提升整体吞吐。优化重点不在让 Worker 主动配合，而在于减少争抢、避免干扰、精准分发。
用共享内存 + 原子操作替代锁竞争
Worker 进程间不共享栈和堆，但可通过 shared memory zone（如 limit_req_zone、ssl_session_cache）交换状态。这类区域被所有 Worker 映射到各自地址空间，读写必须安全：
- 对计数器、连接统计、缓存引用计数等简单整数状态，优先使用 ngx_atomic_t 类型变量，底层调用 LOCK XADD（x86）或 LDREX/STREX（ARM），全程在用户态完成，无上下文切换
- 避免用互斥锁保护高频短临界区（比如每秒数万次的请求计数），锁会引入调度延迟和争用挂起
- 原子操作只适用于单个整数变量，不能用于结构体或跨字段一致性逻辑（如“先查余额再扣减”仍需 CAS 循环或退回到锁）
通过 accept_mutex 控制连接分配节奏
默认所有 Worker 竞争同一个全连接队列，容易引发“惊群效应”。开启 accept_mutex 后：
- 同一时刻仅一个 Worker 尝试从 listen socket 取连接，其余等待下一轮唤醒
- 避免多个进程同时调用 accept() 导致的内核锁争抢和无效唤醒
- 配合 multi_accept on，允许单次事件循环中接收多个新连接，提升吞吐
绑定 CPU 核心减少迁移开销
Worker 是单线程进程，频繁跨核调度会导致 L1/L2 缓存失效、TLB 刷新、上下文切换成本上升：
- 配置 worker_cpu_affinity auto（Nginx 1.9.10+），自动将每个 Worker 绑定到独立物理核心
- 若手动配置，掩码位数需与 worker_processes 数量一致，例如 4 个 Worker 对应
worker_cpu_affinity 1000 0100 0010 0001 - 验证是否生效：用
taskset -cp <pid>查看绑定情况，或检查/proc/<pid>/status中的 Cpus_allowed_list
让 Master 承担管理职责，Worker 专注处理
Master 不参与请求处理，只做三件事：加载配置、响应信号、启停 Worker。这种分工带来稳定性和可维护性：
- 配置重载（
nginx -s reload）时，Master 启动新 Worker 并逐步移交连接，旧 Worker 处理完现存请求后退出，全程服务不中断 - 某个 Worker 异常崩溃，Master 立即拉起新进程，不影响其他 Worker 正常工作
- 日志重开（
nginx -s reopen）、平滑停止（nginx -s quit）均由 Master 统一转发信号，Worker 按需响应
