Nginx Master进程不直接处理请求或同步状态，而是创建并管理共享内存zone，供Worker进程零拷贝读写；Worker通过信号、轮询和原子操作自主协作，Master仅负责初始化、约束兼容性及生命周期管理。
Nginx 的 Master 进程本身不直接参与请求处理，也不主动“同步状态”给 Worker；它真正做的是创建、管理并初始化共享内存区域（zone），让所有 Worker 进程能天然、零拷贝地读写同一块物理内存。所谓“状态同步”，其实是 Worker 通过这套机制自主、并发、安全地协作，Master 只负责奠基和守门。
Master 创建共享内存 zone 是关键第一步
Master 在启动阶段调用 mmap()，传入 MAP_SHARED | MAP_ANONYMOUS 标志，分配一块匿名内存——不关联文件、内容清零、由内核统一映射。这块内存的生命周期完全由 Master 控制：
- Worker 进程通过
fork()继承该映射，初始共享同一物理页（COW 机制保障只读高效） - 各 Worker 虚拟地址可能不同，但 Nginx 内部一律用相对于 zone 起始地址的字节偏移量访问数据，避免指针失效
- reload 或退出前，Master 会等待所有 Worker 完成对 zone 的引用，再统一释放；Worker 自行退出不会触发释放
Master 不推送状态，而是让 Worker 主动感知变更
Master 不向 Worker “广播”或“下发”运行时状态，而是通过两种轻量方式触发 Worker 行为：
-
信号驱动：如发送
SIGHUP（重载）、SIGUSR2（平滑升级）时，Worker 收到信号后主动重新读取共享内存中已更新的配置结构（如ngx_cycle_t） -
共享标志位轮询：某些模块（如 upstream 健康检查）会在共享内存中设置状态位（如
upstream_down），Worker 定期读取该字段，无需锁即可判断是否需切换节点
Master 确保 zone 结构一致，Worker 负责安全读写
Master 不干涉具体数据操作，但通过配置约束保证底层兼容性：
- zone 名称与大小必须在 reload 时保持不变，否则新旧 zone 不兼容，旧数据会被丢弃
- 所有 zone 必须显式声明（如
limit_req_zone ... zone=name:size;），不能自动启用 - Master 初始化 zone 内存为 0，并加载初始配置（如 upstream server 列表、SSL session cache 参数），之后交由 Worker 自主维护
共享内存不是万能同步通道，它只提供载体
Master 创建的共享内存本身是一段裸内存，不带协议、不自动序列化、不解决竞态：
- 高频计数（如 stub_status 的连接数）依赖
ngx_atomic_t类型 + CPU 原子指令（如LOCK XADD），Worker 各自原子累加，无锁安全 - 写入较重逻辑（如限流桶刷新、缓存元数据更新）由模块配合
ngx_shmtx_t自旋锁，在共享内存中实现轻量互斥 - Lua 脚本通过
lua_shared_dict操作时，底层已封装原子incr/set，开发者无需手动加锁
本质上，Master 的角色是“内存基建者”和“生命周期管家”，而非“状态分发中心”。真正的协同发生在 Worker 层——它们基于同一块物理内存、同一套偏移规则、同一组原子原语，达成毫秒级、免 IPC 的状态一致性。
