worker_cpu_affinity 本身不直接解决多租户性能干扰，但可通过绑定 CPU 核心隔离 Nginx worker 进程，减少调度争抢、缓存污染和跨 NUMA 访问，为多租户提供资源边界基础；需配合 NUMA 绑定、中断亲和、流量分流及全链路验证才能实现真实隔离。
worker_cpu_affinity 本身不直接解决多租户环境下的性能干扰，但它能成为关键基础手段——通过隔离 Nginx worker 进程的 CPU 资源，减少租户间因调度争抢、缓存污染和跨 NUMA 访问引发的隐性干扰。
明确划分 CPU 核心资源边界
在多租户场景（如 SaaS 网关、API 平台或容器化部署中多个业务共用一台 Nginx 实例），不同租户流量常由不同 server 块或 upstream 分组承载。若所有 worker 共享全部 CPU 核，高流量租户会频繁触发上下文切换，导致低优先级租户响应延迟升高、P99 毛刺明显。
合理做法是：按租户负载等级或 SLA 分配独占核心组。例如：
- 为高保障租户（如金融类）预留 2 个物理核，启动专属 Nginx 实例并配置 worker_cpu_affinity 00000011（绑定 core 0 和 1）
- 为普通租户聚合到另 4 个核，用另一实例配 worker_cpu_affinity 00111100（绑定 core 2–5）
- 避免掩码重叠（如两个实例都写 00000011），否则仍会竞争同一物理资源
配合 NUMA 拓扑与内存亲和性
在多路服务器或启用了 NUMA 的虚拟机中，跨节点访问内存延迟可达 2–3 倍。仅绑 CPU 不够，还需确保：
- 每个租户对应的 Nginx 实例运行在本地 NUMA 节点上（用 numactl --cpunodebind=0 --membind=0 nginx 启动）
- worker_processes 数 ≤ 绑定节点的逻辑核数，防止调度器跨节点迁移
- /proc/sys/kernel/numa_balancing 设为 0（关闭自动 NUMA 迁移），避免内核干扰手动绑定
协同网络中断与租户流量分流
CPU 绑定效果会被网卡软中断（ksoftirqd）破坏：若网卡收包中断跑在 core 0，而租户 A 的 worker 绑在 core 2，数据就得跨核搬运。
必须同步做：
- 用 ethtool -L eth0 combined 8 均匀分配队列数，再用 echo 1 > /proc/irq/*/smp_affinity_list 将每队列中断绑定到对应租户的 CPU 组（如租户 A 队列 → core 0,1）
- 结合 stream 模块或 geo 指令，把租户 IP 段哈希到特定 upstream 组，再配合 cpu_affinity 实现“请求入口→中断→worker→内存”全链路局部化
验证租户级隔离是否真实生效
不能只看单个 Nginx 实例的绑定结果，要交叉比对：
- 对每个租户专用 Nginx 实例，分别执行：ps -eo pid,args,psr | grep 'nginx: worker' | grep -v master，确认 psr 列只落在预定核心范围内
- 检查 cat /proc/interrupts | grep eth0，确认各 RX/TX 队列中断分布与租户 CPU 组匹配
- 用 perf stat -e cycles,instructions,cache-misses -p [worker_pid] 对比不同租户 worker 的 cache-miss ratio，隔离良好时应相差小于 15%
