如何通过listen_reuseport配合权重压榨多核多队列吞吐-Nginx-PHP中文网

reuseport 本身不支持权重，仅通过五元组哈希均衡分发连接；权重需在上层负载均衡器或用户态调度中实现，内核层专注无锁并发与多核释放。

如何通过listen_reuseport配合权重压榨多核多队列吞吐

直接用 listen ... reuseport 本身不支持权重控制——它由内核按五元组哈希分发连接，天然无权重概念。所谓“配合权重压榨多核多队列吞吐”，本质是在 reuseport 基础上叠加调度层干预，而非让 reuseport 本身带权重。真正可行的路径是分层协同：内核层靠 reuseport 消除惊群、释放多核并行能力；用户层或前置层引入有向调度，实现连接入口的粗粒度倾斜。

reuseport 本身没有权重，但可被“包裹”出权重效果

Linux 内核对 SO_REUSEPORT 的实现只做哈希（默认为四元组），不提供权重、优先级或会话保持策略。它的目标是均衡与无锁，不是可控分配。因此：

不能在 listen 80 reuseport 后加 weight=2 或类似语法——Nginx 不识别，内核也不支持
所谓“权重”，只能落在 reuseport 之上一层：比如在负载均衡器（LVS、F5、Envoy）或服务网格（Istio）中配置后端权重，再将流量打到启用 reuseport 的 Nginx 集群
单机内若需 worker 级别倾斜（如预留 1 个 worker 专处理高优健康检查），需绕过 reuseport，改用 listen 80 + accept_mutex off + 自定义进程启动顺序或 cgroup 限频，但这会回归争抢风险，不推荐

真正提升多核多队列吞吐的关键组合

想把多核 CPU、多队列网卡（RSS/RPS）、reuseport 全部拉满，必须三者对齐，缺一不可：

网卡多队列开启且绑定：确认 ethtool -l eth0 显示 TX/RX 队列数 ≥ CPU 核心数；用 echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus（或使用 rps_flow_cnt）将软中断分散到不同 CPU
Nginx worker 与 CPU 核硬绑定：配置 worker_cpu_affinity auto; 或显式写成 worker_cpu_affinity 0001 0010 0100 1000;，确保每个 worker 独占一个物理核，避免跨核缓存失效
reuseport + backlog + 队列参数全开：每条 listen 行带 reuseport，并显式设 backlog=65535；同步调大内核参数：net.core.somaxconn、tcp_max_syn_backlog、netdev_max_backlog
关闭干扰项：禁用 accept_mutex on（reuseport 已替代其作用），禁用 epoll_wait 中不必要的事件广播（如不用 EPOLLEXCLUSIVE 可能引发轻微唤醒竞争）

短连接场景下的“伪权重”实践方案

当业务要求某类请求（如 /health、/metrics）优先获得资源，而其他路径走常规复用时，可借助 Nginx 的流模块或上游分组模拟权重：

用 stream 块监听同一端口但不同目标：例如 listen 80 reuseport 在 stream 层分流，把健康检查 IP 段代理到专用 upstream（仅 1 个 server），其余流量 proxy_pass 到主 reuseport server 组
在 HTTP 层用 map + upstream 实现路径加权：虽然不改变 reuseport 分发，但能让 /health 请求在进入 worker 后更快被 dispatch 到专用 handler，减少排队延迟
结合 cgroup v2 对不同 worker 进程设置 cpu.weight（如主 worker 设为 80，健康检查 worker 设为 20），从调度器层面影响 CPU 时间片分配，形成底层资源权重

验证是否真正压满多队列与多核

仅看 ss -tlnp | grep :80 有多个监听行还不够，要确认数据路径贯通：

执行 cat /proc/interrupts | grep eth0，观察 RX 队列中断是否均匀分布到多个 CPU
运行 perf top -p $(pgrep nginx)，确认热点集中在 tcp_v4_do_rcv、sk_stream_write_queues 等路径，而非 accept 锁或 futex_wait
压测时用 mpstat -P ALL 1 观察各 CPU 核利用率是否均衡（标准差 ≤ 15%），且无单核持续 100%
检查 /proc/net/softnet_stat 第 0 列（processed）和第 1 列（dropped）比值，若 dropped 持续增长，说明软中断处理不过来，需调大 net.core.netdev_max_backlog 或优化 RPS