Nginx 中 Worker Process 如何维护连接状态数据

Nginx各Worker进程独立维护连接状态数据且不自动同步，因其多进程架构导致内存隔离；stub_status等指标仅反映单个Worker本地状态，全局统计需依赖shared memory zone机制。

Nginx 的每个 Worker Process 独立维护自己的连接状态数据，不与其他 Worker 进程自动同步。这是由其多进程架构决定的——每个 Worker 是一个完全隔离的操作系统进程，拥有独立的内存空间和变量副本。

连接状态数据存储在 Worker 进程本地内存中

像活跃连接数（$connections_active）、读写请求数、接收/发送字节数等指标，底层对应的是每个 Worker 内部的 C 变量（如 ngx_stat_active）。这些变量只反映当前 Worker 正在处理的连接，无法代表全局真实负载。

• 例如，stub_status 模块返回的 Active connections 值，仅来自当前被访问的那个 Worker，不是所有 Worker 的总和
• 日志中的 $request_time、$upstream_response_time 也只记录该 Worker 处理本次请求的耗时，不跨进程聚合
• SSL 会话缓存、gzip 缓冲区、客户端请求体缓冲等资源，同样为每个 Worker 单独分配

不同步是默认行为，不是缺陷

这种设计是为了避免进程间锁竞争，提升并发性能。Nginx 不在 Worker 之间做实时状态同步，因为：

• 共享内存更新有原子开销，高频读写会成为瓶颈
• 连接生命周期短（毫秒级），强一致性对大多数场景并非必需
• Master 进程不参与请求处理，也不维护任何运行时统计

需要全局视图时必须显式使用共享内存 zone

若业务要求准确的全局限流、过载判断或聚合统计，不能依赖单个 Worker 的本地值，而要借助 Nginx 提供的共享内存机制：

• limit_conn_zone：按 IP、URL 等 key 统计并发连接，所有 Worker 共享同一 zone，自动原子增减
• upstream zone：在 upstream 块中声明 zone，使各 Worker 对后端服务器的连接数、失败次数等状态达成一致
• lua_shared_dict：配合 OpenResty，在 Lua 中操作共享字典，支持自定义 key 和复杂逻辑（如按用户 ID 统计）

监控和调试时注意进程视角差异

用 nginx -s reload 或压测验证时，观察到不同 Worker 的 stub_status 输出不一致是正常现象。可通过以下方式确认共享 zone 是否生效：

• 在日志中加入 $pid 字段，对比多个 Worker 日志里同一请求 key 的计数是否一致
• 用 curl http://localhost/stub_status 多次请求，看 Active connections 波动是否符合预期（单 Worker 视角）
• 调用 limit_conn 规则后，故意超限触发 503，验证是否所有 Worker 都遵守同一阈值