worker_processes不参与lvs分发但需与后端nginx的cpu利用模式对齐：须绑定独立物理核、关闭accept_mutex、启用multi_accept和epoll，并协同调优网卡软中断分布以提升多核性能。
worker_processes 本身不参与 LVS 的流量分发，但它必须与 LVS 后端 Nginx 实例的 CPU 利用模式对齐，才能避免成为多核架构下的性能瓶颈。关键不是“让 LVS 把流量分给哪个 worker”，而是确保每个 Nginx worker 能稳定、低开销地承接从 LVS 转发来的连接。
明确角色分工：LVS 负责四层分发，Nginx worker 负责七层并发处理
LVS 工作在内核态，按 IP+端口将客户端请求转发到后端真实服务器（RS），比如把 VIP:80 的 TCP 连接直接送到某台 RS 的 8080 端口；而该 RS 上运行的 Nginx，由其 worker_processes 启动多个 worker 进程来并行处理这些到达的连接。两者之间没有调度协同协议，只有网络层的透明传递。因此：
- LVS 的 DR 或 NAT 模式决定了哪台物理机收到包，不决定该机上哪个 CPU 核或哪个 Nginx worker 处理它
- 真正影响多核利用率的是 Nginx 自身的进程绑定、事件分发和系统软中断分布
- 若 Nginx 只配 worker_processes 1，哪怕 LVS 均匀分发到 4 台 RS，每台也只有一个 worker 在扛全部连接，多核形同虚设
让每个 worker 绑定独立物理核，减少跨核缓存失效
默认情况下，Linux 调度器可能把多个 Nginx worker 随机调度到同一颗 CPU 上，导致 L1/L2 缓存争抢、TLB miss 升高。应显式绑定：
- 先确认物理核心数：lscpu | grep -E "Socket|Core"，例如双路 16 核 → 共 32 物理核
- 配置 worker_processes 32;（非逻辑核数，禁用超线程干扰）
- 启用自动绑定：worker_cpu_affinity auto;（Nginx ≥ 1.9.10）
- 或手动指定掩码（如 8 核）：worker_cpu_affinity 00000001 00000010 00000100 ...;
这样每个 worker 固定运行在专属物理核上，配合 LVS 分发后的长连接复用，可显著提升响应一致性。
消除 accept 锁竞争，允许多个 worker 并发接收连接
即使开了多个 worker，若未关闭 accept_mutex，所有 worker 仍会排队争抢 listen socket，造成“惊群”或空转。尤其在 LVS 高频建连场景下必须调整：
- accept_mutex off;（Nginx ≥ 1.11.3 默认关闭，旧版本务必显式配置）
- multi_accept on;：让每个 worker 一次尽可能多地 accept 就绪连接，降低事件循环轮询开销
- use epoll;：确保使用高效事件模型（Linux 下默认，但建议显式声明）
配合足够大的 worker_connections 65535;，才能把多 worker 的并发潜力真正释放出来。
网卡软中断与 worker 核心对齐（进阶但关键）
LVS 转发来的包最终由网卡队列触发 NET_RX 软中断，若软中断集中在某几个 CPU，而 Nginx worker 分布在其他核上，就会频繁跨核搬运数据。需协同调优：
- 启用网卡多队列：ethtool -L eth0 combined 32（队列数 ≈ 物理核数）
- 开启 RPS（Receive Packet Steering）：echo ff > /sys/class/net/eth0/queues/rx-0/rps_cpus（8 核示例）
- 验证：watch -n 1 'cat /proc/softirqs | grep NET_RX'，各 CPU 列增长速率应接近
- 再结合 worker_cpu_affinity auto，使软中断处理核与 Nginx worker 核尽量重合
这一步能让“数据进来→软中断处理→Nginx worker 执行”全程落在同一 NUMA 节点内，延迟更稳、吞吐更高。
