网卡中断亲和性调优，本质上就是让网卡中断尽量落在同一个CPU核心或同一组核心上，从而减少缓存抖动和跨核调度，这是高频交易低延迟优化中成本最低、见效最快的一步。
高频交易系统对网络延迟极度敏感,毫秒甚至微秒级别的波动都可能影响交易结果，在服务器硬件配置确定后，网卡中断处理路径往往是最大的隐藏延迟源，如果不做亲和性设置，网卡中断可能随机跑到任意CPU核心上，导致数据包处理缓存频繁失效，延迟抖动明显，业内专家指出，多数情况下，单纯调整中断亲和性就能让包处理延迟的稳定性提升一个量级，但很多量化团队恰恰忽略了这一步。
网卡中断亲和性调优怎么做才能降低高频交易延迟？
先说结论：调优的思路是先确认网卡型号和驱动，再查看当前中断分布，然后把中断绑到指定CPU核心上，最后用压测工具验证延迟曲线，整个过程不复杂，但每一步都需要细心。
第一步：确认网卡和驱动版本
不同网卡的支持方式差异很大,Intel的ixgbe、Mellanox的ConnectX系列、Broadcom的bnx2x等，都有各自的配置工具，查看网卡信息可以用：
ethtool -i eth0查看驱动和固件版本lspci | grep Ethernet确认网卡PCI地址cat /proc/interrupts查看当前每个中断在各CPU上的分布
高频交易常用的Mellanox网卡通常支持mlx5_core驱动，这类网卡对亲和性的要求更高，配置不当会导致严重的延迟抖动，如果是普通Intel千兆网卡，配置方法相对简单。
第二步：了解两种中断处理模式
现代网卡有两种常见模式：
- MSI-X模式：每个队列有独立中断号，可以分别绑定不同CPU，这是高性能场景的首选
- MSI模式：多个队列共享中断，绑定灵活性较差
确认当前模式可以看/proc/interrupts中的中断号数量，如果每个队列都有独立中断号，说明已经是MSI-X模式，如果不是，可能需要调整BIOS或内核参数。
第三步：绑定中断到指定CPU核心
假设我们有一个四队列的网卡,想把这四个中断绑到物理核0-3上，具体操作如下：
# 查看中断号，例如eth0的四个队列对应中断号 62-65 cat /proc/interrupts | grep eth0 # 绑定中断62到CPU0，依次类推 echo 1 > /proc/irq/62/smp_affinity echo 2 > /proc/irq/63/smp_affinity echo 4 > /proc/irq/64/smp_affinity echo 8 > /proc/irq/65/smp_affinity
smp_affinity的值是CPU位图，CPU0对应1，CPU1对应2，CPU2对应4，CPU3对应8，以此类推，如果是多核系统，建议使用printf计算：
printf "%x" $((1 << cpu))
绑定后再次查看/proc/interrupts，确认中断分发已经落在目标CPU上。
第四步：设置RPS与RPS/XPS（如果网卡不支持多队列）
部分网卡只有单队列,或者队列数少于CPU核数，此时需要启用软件层的接收包 steering（RPS），RPS的配置路径在/sys/class/net/eth0/queues/rx-0/rps_cpus。
比如把RPS绑定到CPU0-3，就写入f：
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
同时建议设置rps_flow_cnt和rps_sock_flow_entries来启用流哈希，保证同一连接的数据包始终由同一CPU处理，行业共识认为，RPS在大多数低延迟场景下不如硬件多队列直接，但值得作为备选方案。
高频交易低延迟场景下，RSS与RPS怎么选？
这是许多运维人员纠结的问题,RSS是网卡硬件层面的多队列分流，RPS是内核软件层面的模拟分流，两者的适用场景和成本差异明显。
| 对比维度 | RSS（Receive Side Scaling） | RPS（Receive Packet Steering） |
|---|---|---|
| 分流位置 | 网卡硬件 | 内核软件 |
| 延迟水平 | 极低，硬件直接分发 | 略高，需要经过CPU软件处理 |
| 配置复杂度 | 低，ethtool设置 | 中，需写sysfs参数 |
| 适用硬件 | 支持多队列的高端网卡 | 单队列或队列不足的网卡 |
| 典型场景 | 高频交易专用服务器 | 云主机或低配物理机 |
对于高频交易，首选RSS，因为RSS在网卡内部完成哈希分流，不需要额外占用CPU周期，RPS本质上是把硬件的活交给内核干，多一层处理就多一层延迟。
如何确认网卡支持RSS？
查询网卡是否启用RSS,可以用ethtool -l eth0查看Combined队列数，如果队列数为1，说明硬件RSS未开启或网卡不支持，此时可以尝试：
ethtool -L eth0 combined 4
如果命令报错,说明网卡不支持多队列，这种情况下，RPS是仅有的软件优化手段之一，但要注意，RPS在高并发下可能导致CPU软中断占用不均匀，需要配合irqbalance服务关闭。
中断绑定到哪个CPU核心更合适？深圳量化团队的实测思路
这个问题没有绝对答案,但有一些通用原则，高频交易系统的数据包处理线程通常运行在固定的几个核心上，应该让网卡中断和数据处理线程位于同一NUMA节点，最好在同一物理核心的超线程兄弟上。
如果交易引擎运行在CPU0,那么网卡中断也应该绑定到CPU0或CPU1（同一物理核的另一逻辑核），这样数据包从中断处理到业务逻辑，始终在同一个物理核的缓存范围内，避免跨核访问L2/L3，不少深圳量化团队在调优时采用过类似的"核隔离+中断绑定"组合方案，效果比单纯调整进程绑核明显得多。
具体步骤：
- 用
lscpu确认物理核与逻辑核的映射关系 - 把业务进程绑定到逻辑核A,中断绑定到逻辑核B（与A同物理核）
- 关闭CPU调频服务,避免频率变化引入额外抖动
如果使用的是双路服务器,务必保证网卡所在NUMA节点与业务进程所在NUMA节点一致，可以通过lstopo查看拓扑图，简单直观。
调优效果如何验证？三个关键指标
调优不是改完配置就结束,必须用可量化的数据验证，建议观察以下三个指标：
延迟均值与P99延迟
用ping -f或专业的SockPerf测试工具，比较调优前后的延迟分布，重点看P99和P999，高频交易对尾部延迟更敏感，调优后，P99应明显下降，且抖动幅度收窄。
中断分布均匀度
再次查看/proc/interrupts，确认各队列的中断次数是否均匀落在绑定的CPU上，如果某个CPU出现异常高的中断数，说明哈希策略可能需要调整。
软中断占用比例
用top查看si（软中断）占用率，理想情况下，绑定的CPU核心软中断占用应保持在较低水平，且不会在多个核心间跳动，如果发现softirq分布散乱，多半是亲和性设置被irqbalance覆盖了，需要先停掉该服务：
systemctl stop irqbalance systemctl disable irqbalance
内核参数配合项
除了中断亲和性,以下参数也值得一并检查和调优：
net.core.busy_read
net.core.busy_poll：开启忙轮询模式，减少中断开销net.core.netdev_max_backlog：适当增大，防止突发流量时丢包net.ipv4.tcp_low_latency：对于TCP流，设置为1可优先降低延迟
这些参数可以在/etc/sysctl.conf中统一配置，但注意，busy_read和busy_poll会持续占用CPU，在高频交易专门的收报节点上可能有用，在通用节点上反而增加开销，需要做小范围测试。
相关问答：高频交易中断调优的常见问题
Q：高频交易网卡中断亲和性调优需要花钱吗？
A：不花钱，这是纯软件层面的优化，只需要修改Linux内核参数和系统配置，不涉及额外硬件采购，如果你的网卡本身就支持多队列，那调优成本几乎为零，相比购买更高端的网卡或交换机，中断亲和性调优是性价比最高的延迟优化手段之一。
Q：中断绑定到CPU后，为什么延迟还是不稳定？
A：检车几个方向：一是irqbalance是否还在运行，它会动态调整中断分配，覆盖手动设置；二是是否忽略了NUMA距离，建议用lstopo确认网卡和CPU的物理位置；三是业务线程的绑核是否和中断核冲突，如果它们共享同一个逻辑核，会互相抢占，检查BIOS中是否开启了超线程，超线程对延迟的影响因场景而异，高频交易通常会选择关闭或谨慎使用。
Q：网上有人说中断亲和性应该绑定到偶数编号的CPU核心，这种说法对吗？
A：不完全对，CPU核心编号与延迟没有直接关系，关键是物理位置和缓存结构，绑定到哪个CPU，取决于业务进程运行在哪里、网卡接在哪个NUMA节点上，优先保证"网卡中断、业务进程、内存分配"三者处于同一NUMA节点，比纠结编号奇偶更有意义，部分老运维习惯绑定到非HT核心，是因为避免超线程兄弟核争抢执行单元，但在中断处理场景，逻辑核之间的干扰影响不大，主要还是看整体拓扑。
最后回到核心：网卡中断亲和性调优不需要更换硬件，也不需要改业务代码，它解决的是数据包从网卡到业务进程这条路径上的确定性延迟问题。 先确认网卡队列能力，再绑定中断，最后验证延迟分布，这套流程在任何发行版Linux上都通用，只要把这一步做好，高频交易系统的延迟表现就能获得立竿见影的改善。