硬件选型：CPU架构、NUMA绑定、网卡与内核bypass技术

聊到低延迟交易系统，硬件选型这块，我个人的经验是——选对了硬件，优化就成功了一半。很多人一上来就堆代码优化，结果发现延迟瓶颈其实在硬件层面。今天咱们就掰开揉碎，聊聊CPU架构、NUMA绑定、网卡和内核bypass这几个硬核话题。

一、CPU架构：核心频率 vs 核心数量

做交易系统，你首先要明白一个道理：延迟敏感型任务，核心频率比核心数量重要得多。我在项目中遇到过好几次，团队买了32核的服务器，结果延迟死活降不下来。为什么？因为高频核心才是关键。

我个人习惯选Intel的Xeon W系列或者AMD的Ryzen Threadripper Pro系列。这些CPU的单核频率能跑到4.5GHz以上，而且支持AVX-512指令集——这对一些数学运算很有帮助。

说到超线程，我得提醒一句：关掉它。超线程虽然能提升吞吐量，但对延迟敏感型任务来说，它会引入不可预测的上下文切换。我曾经在一个项目中，关掉超线程后，平均延迟直接降了15%。

二、NUMA绑定：别让数据乱跑

NUMA（非统一内存访问）是现代多路服务器的基础架构。说白了，每个CPU有自己的本地内存，访问本地内存快，访问远端内存慢。你想想看，如果你的线程在CPU0上跑，但数据在CPU1的内存里，那每次访问都要跨总线——延迟直接翻倍。

我建议的做法是：绑定线程到特定CPU核心，同时绑定内存到该CPU的本地NUMA节点。具体怎么做？

# 查看NUMA拓扑
numactl --hardware

# 绑定进程到NUMA节点0，并分配本地内存
numactl --cpunodebind=0 --membind=0 ./trading_engine

# 或者用taskset绑定到具体核心
taskset -c 0-3 ./trading_engine

嗯，这里要注意：不要只绑CPU，不绑内存。我曾经犯过这个错——绑定了核心，但忘了设置--membind，结果内存分配到了远端节点，延迟反而更差了。

三、网卡选型：不只是看带宽

很多人选网卡只看带宽——10G、25G、40G、100G。但做低延迟交易，延迟比带宽重要得多。我推荐Solarflare（现在叫Xilinx）的SFN系列或者Mellanox的ConnectX系列。这些网卡有硬件时间戳和PTP支持，对精确计时很有帮助。

网卡型号	延迟（硬件时间戳）	特点
Solarflare SFN8522	< 1μs	硬件TCP卸载、OpenOnload支持
Mellanox ConnectX-6	< 0.8μs	RDMA、GPUDirect支持
Intel E810	< 1.5μs	ADQ（应用设备队列）技术

我个人习惯用Solarflare的网卡配合OpenOnload——这是一个用户态网络栈，能绕过内核直接访问网卡。说白了，就是内核bypass。

四、内核bypass技术：绕开那个慢吞吞的内核

标准Linux网络栈，数据包从网卡到应用，要经过中断处理、协议栈解析、socket缓冲区拷贝……这一套下来，几十微秒就没了。对于微秒级交易系统，这完全不可接受。

内核bypass的核心思想就是：让应用直接和网卡对话。常见方案有几种：

• DPDK（Data Plane Development Kit）：Intel主导，用户态轮询模式，延迟极低。我做过测试，DPDK的收包延迟可以控制在1μs以内。
• OpenOnload：Solarflare的闭源方案，兼容POSIX socket API，迁移成本低。我建议如果你们用Solarflare网卡，优先考虑这个。
• RDMA（Remote Direct Memory Access）：Mellanox的看家本领，零拷贝网络传输。适合做行情分发和订单路由。

五、知识体系总览

下面这张图，是我整理的本章节核心逻辑。你可以把它当作一个检查清单——做硬件选型时，对着这张图过一遍，基本不会漏掉关键点。

六、实战建议

最后，我总结几条实战经验：

1. 先做硬件选型，再做软件优化——硬件底子不行，软件再怎么优化也白搭。
2. 测试环境要和生产环境一致——我见过太多团队在开发机上跑得好好的，一上生产就崩。因为开发机的NUMA拓扑和生产机不一样。
3. 用perf工具做延迟分析——perf stat -e cycles,instructions,cache-misses 可以帮你定位到底是CPU瓶颈还是内存瓶颈。
4. 不要迷信单一指标——平均延迟低不代表P99延迟也低。我建议关注P99.9甚至P99.99的延迟。

好了，硬件选型这块就聊到这儿。记住一句话：低延迟是设计出来的，不是测试出来的。选对硬件，你的系统就赢在了起跑线上。

---

公众号:蓝海资料掘金营，微信deep3321