nginx多worker绑核与upstream状态一致需协同使用worker_cpu_affinity和upstream zone：前者绑定cpu核心避免缓存竞争，后者通过共享内存同步up/down、连接数、ip_hash等状态，防止因状态隔离导致负载偏斜；单机用zone即可，跨机集群需nginx plus的zone_sync模块。

要让 Nginx 多 worker 进程在多核 CPU 上既实现绑核隔离，又保持 upstream 状态一致、负载均衡不偏斜，关键不是“二选一”，而是把 CPU 绑定 和 zone 共享内存 配合使用——前者管执行位置，后者管数据视图。

为什么绑核后反而容易失衡？

单纯用 worker_cpu_affinity 把每个 worker 固定到不同核心，看似隔离了缓存竞争，但默认 upstream 状态仍是各 worker 独立维护的。比如 worker 0 发现后端 A 失败并标记为 down，worker 1 完全不知情，仍持续转发请求过去，造成局部超时堆积、连接数飙升、真实负载倾斜。这不是性能提升，是故障放大。

zone 是状态同步的唯一基础设施

必须显式配置 zone，才能打破 worker 间的状态墙：

• 在 upstream 块中写：zone backend_zone 128k;（名称自定义，大小按后端节点数预留，64k 起步，百节点建议 1m）
• 搭配 max_fails=3 fail_timeout=30s，否则失败不会触发自动 down 标记
• 所有 worker 通过 mmap 共享同一块物理内存，up/down 状态、当前连接数、ip_hash 映射、slow_start 权重进度全部实时可见

绑核 + zone 的协同要点

CPU 绑定不干扰 zone 生效，但需注意三点：

• worker 进程数 ≤ 物理核心数：避免超线程争抢，例如 8 核 CPU 设 worker_processes 8;，再用 worker_cpu_affinity 00000001 00000010 ... 一一对应
• 不要禁用 worker_reuse_port：保持端口复用，避免因 bind 冲突导致部分 worker 无法接收新连接，破坏负载入口均衡
• 健康检查与 proxy_next_upstream 需依赖 zone 状态：比如设 proxy_next_upstream error timeout http_503;，重试决策由共享内存中的实时 up/down 和失败计数驱动，不是本地缓存值

跨机器集群不能只靠 zone

单机多 worker 的状态同步靠 zone 就够了；但若部署了多台 Nginx 服务器组成集群（如 LB 层横向扩展），仅靠本机 zone 无法互通。此时需：

• 升级至 NGINX Plus 或企业版，启用 ngx_stream_zone_sync_module
• 配置 zone_sync_server 指向其他节点，zone_sync_interval 500ms 控制同步节奏
• 开启 zone_sync_ssl on 并配置证书，保障跨网传输安全