Nginx多进程同步分场景精准设计：accept锁防惊群（默认fcntl文件锁），共享内存zone用原子操作保关键字段，复杂逻辑靠本地缓存+周期合并；不追求强一致，重性能与安全平衡。
Nginx 多进程模型下，同步与竞态处理不是靠全局锁“一把抓”，而是分场景、分资源、分粒度地精准设计：监听套接字用 accept 锁避免惊群，共享内存 zone 用原子操作保护关键字段，复杂逻辑则靠本地缓存 + 周期合并降低竞争。它不追求强一致，而是在性能与安全之间取得务实平衡。
accept 锁：解决“惊群”的用户态协调
多个 worker 进程监听同一端口时，内核可能同时唤醒全部进程去 accept 新连接，造成无效 CPU 消耗。Nginx 在用户态引入 accept 锁，确保任一时刻仅一个 worker 尝试取连接。
- 默认使用 fcntl 文件锁 实现：基于一个临时文件（如 nginx.pid 所在路径下的 .accept_lock），通过 F_SETLK 尝试非阻塞加锁
- 获得锁的 worker 才执行 accept()；未获锁者继续处理已有连接或进入 epoll_wait 等待
- 锁释放发生在 accept 完成后或连接处理完毕时，不依赖超时，也不阻塞其他 worker
- 若系统支持 SO_REUSEPORT，Nginx 可关闭 accept 锁——由内核直接分发连接，更高效
共享内存 zone：零拷贝 + 原子字段 + 结构约束
zone 是 master 分配、所有 worker 直接映射的同一块物理内存，不是复制多份。它高效但敏感，同步只作用于真正需要并发修改的字段。
- 不存指针：结构体中禁止出现虚拟地址指针（各 worker 地址空间不同），一律改用“基址 + 偏移”方式访问数据
-
原子操作保关键字段：计数器、时间戳等用
ngx_atomic_t类型，支持ngx_atomic_fetch_add、ngx_atomic_cmp_set - 不提供任意结构体的原子读-改-写：比如更新一个含多个字段的 session 记录，需先读、再算、再 CAS 替换整个槽位，或拆解为多个原子字段
- LRU 管理靠原子指针：SSL session 缓存通过原子更新头指针实现无锁淘汰，避免互斥锁开销
互斥锁（ngx_shmtx_t）：跨平台兼容的统一抽象
Nginx 封装了 ngx_shmtx_t，底层根据系统能力自动选择最合适的同步原语，对上层模块透明。
- 有原子指令且支持 POSIX 信号量 → 使用原子变量 + sem_wait/sem_post，长等待时休眠省 CPU
- 仅支持原子指令 → 纯自旋锁，默认尝试 2048 次，失败则让出调度器（yield）
- 无原子指令（极少见）→ 回退到 fcntl 文件锁，靠文件系统语义保证互斥
- 所有锁操作均为非阻塞尝试（trylock），模块需自行处理失败路径，比如重试或降级
典型模块中的协同策略
不同模块面对竞态，采用符合自身语义的弱一致性方案，而非统一加锁。
- limit_req：每个 worker 维护本地滑动窗口；额度不足时才原子扣减共享 zone 配额；失败即拒接，视作瞬时过载
-
lua_shared_dict：提供
incr、set等原子接口，但单次请求多次 incr 可能因本地缓存未及时刷新导致轻微漂移 - upstream 状态：健康检查结果以只读方式映射进 zone；worker 定期轮询，不主动写，避免写冲突
- reload 行为：热重载时，新 worker 启动后旧 worker 逐步退出；zone 内容默认清空（除非配置未变且使用特定 reload 流程）
