nginx多进程协同采用共享内存+自旋锁机制，辅以原子操作和哈希分片：master创建共享内存供worker继承，自旋锁基于cmpxchg实现纳秒级加锁，通过哈希分桶、slot分片和cache line对齐优化锁粒度，accept_mutex则解决accept惊群问题。
Nginx 多进程模型不依赖传统 IPC（如管道、消息队列）来管理共享资源，而是采用更轻量、更贴近内核调度的机制：以 共享内存 + 自旋锁 为核心，辅以原子操作和哈希分片，实现高效、低开销的跨 worker 协同。
共享内存是所有协同的物理基础
master 进程在启动阶段调用 mmap(MAP_SHARED) 或 shmget/shmat 创建一块共享内存区域（如 limit_req_zone 或 ssl_session_cache 所定义的 zone），随后 fork 出的每个 worker 进程自动继承该映射。这意味着：
- 所有 worker 操作的是同一块物理内存页，读操作天然无竞争、零拷贝
- 数据结构必须使用偏移量寻址（不能存指针），避免因进程地址空间不同导致解引用错误
- 共享区内容由模块自行组织，例如限流模块把计数器按 $binary_remote_addr 哈希后存入固定 slot
自旋锁（ngx_shmtx_t）保障写安全
当多个 worker 同时尝试更新共享内存中的状态（如递增限流计数器），必须防止冲突。Nginx 不用系统级互斥锁，而是实现了一个基于原子操作的自旋锁：
- 锁本质是一个 32 位整型变量，位于共享内存头部
- 获取锁时执行
CMPXCHG指令：仅当值为 0 时设为 1，成功即进入临界区 - 失败后执行
PAUSE指令降低 CPU 总线争抢，最多自旋 1024 次，超时则让出 CPU - 释放锁只需原子写回 0，全程无系统调用，延迟在纳秒级
锁粒度优化避免全局瓶颈
全量共享内存共用一把锁会成为性能瓶颈。Nginx 通过三重分片策略缩小竞争范围：
- 哈希分桶：如 limit_req_zone 将客户端地址哈希到数百个 bucket，每个 bucket 独立锁
- slot 分片：SSL 会话缓存按 session_id 哈希后分配到不同 slot，写操作只锁对应 slot
- cache line 对齐：锁变量与相邻数据间隔至少 64 字节，避免 false sharing 导致多核缓存频繁失效
accept_mutex 是特殊场景下的协调机制
虽然不属于严格意义上的“资源管理 IPC”，但 accept_mutex 解决了多 worker 竞争 accept() 系统调用引发的“惊群”问题：
- 启用后，worker 需先获取共享内存中的互斥锁，才能调用 accept()
- 旧版本靠自旋锁实现；新版本（1.9.1+）推荐关闭该选项，直接依赖内核
SO_REUSEPORT - 它不保护业务数据，但保障连接分发这一关键资源的有序性
