3. 硬件架构基础：CPU缓存层级、NUMA架构、内存带宽、分支预测与流水线
做高频交易的朋友，咱们打交道最多的就是CPU和内存。你策略写得再漂亮，如果不懂硬件怎么干活，那性能天花板一碰就到。今天我就把这块硬骨头啃一啃，聊聊CPU缓存、NUMA、内存带宽，还有分支预测和流水线。
3.1 CPU缓存层级：L1/L2/L3 到底在干嘛？
先问个问题：为什么CPU要搞三级缓存？直接访问内存不行吗？
答案很简单——内存太慢了。CPU主频动辄3-4GHz，而内存访问延迟在100纳秒级别。你想想看，CPU等一次内存访问，相当于你等外卖等了100个时钟周期。这谁受得了？
所以缓存就来了。它是个小容量、高速度的存储，专门放CPU最近要用到的数据。
| 缓存层级 | 典型大小 | 延迟（时钟周期） | 特点 |
|---|---|---|---|
| L1 | 32KB - 64KB | 3-5 | 每个核心独享，分指令和数据 |
| L2 | 256KB - 1MB | 10-15 | 每个核心独享 |
| L3 | 8MB - 32MB | 30-50 | 所有核心共享 |
我个人习惯，在写高频交易代码时，会刻意把热数据控制在L1缓存大小内。比如一个订单簿的深度快照，如果超过32KB，我就会考虑拆分结构。为什么？因为L1 miss一次，代价是L1 hit的3-5倍。你想想看，一个高频策略每秒处理几万笔行情，每次多等几个周期，累积下来就是灾难。
核心原则：高频交易代码中，热数据要尽量塞进L1缓存。如果塞不进，至少保证L2能命中。L3 miss意味着你要去内存里拿数据，那延迟直接飙到100ns以上，基本告别低延迟了。
3.2 NUMA架构：别让你的数据跑错地方
NUMA，全称Non-Uniform Memory Access。说白了就是：CPU访问自己附近的内存快，访问远端内存慢。
现代服务器通常有2-4个CPU插槽，每个插槽有自己的内存控制器。如果你在CPU0上跑线程，却去访问CPU1上的内存，那延迟会多出30%-50%。
我在项目中遇到过一件事：一个同事把行情网关和策略线程绑在不同的NUMA节点上，结果延迟从5微秒飙到了8微秒。排查了半天，才发现是NUMA亲和性问题。
避坑指南：我曾经在部署时忘记设置NUMA绑定，结果同一台机器上两个进程互相抢远端内存，性能直接腰斩。现在我的习惯是：每个高频交易进程都明确绑定到某个NUMA节点，并且把它的内存也分配在同一节点上。
怎么绑定？Linux下用numactl命令：
# 绑定到NUMA节点0，并分配内存
numactl --cpunodebind=0 --membind=0 ./trading_engine或者用C++代码设置亲和性：
#include <pthread.h>
#include <numa.h>
void bind_to_numa_node(int node_id) {
struct bitmask *mask = numa_allocate_cpumask();
numa_node_to_cpus(node_id, mask);
pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t),
reinterpret_cast<cpu_set_t*>(mask));
numa_free_cpumask(mask);
}3.3 内存带宽：别让数据堵在路上
内存带宽，就是CPU和内存之间的数据传输速率。现代DDR5内存带宽能到50GB/s以上，听起来很吓人，但实际用起来很容易就满了。
为什么？因为高频交易场景下，数据是流式的。行情数据每秒几百万笔，每笔都要从内存读到CPU。如果你不小心把数据结构设计得太大，或者频繁做内存拷贝，带宽很快就吃光了。
我记得有一次优化一个行情解码模块，发现内存带宽利用率到了80%。排查下来，是因为用了std::vector做动态扩容，每次扩容都要拷贝整个数组。换成固定大小的环形缓冲区后，带宽直接降到20%。
注意：内存带宽是共享资源。同一个NUMA节点内的所有核心共享带宽。如果你在一个节点上跑太多线程，带宽会成为瓶颈。我建议每个NUMA节点最多跑4-6个高频交易线程。
3.4 分支预测与流水线：CPU的“猜谜游戏”
现代CPU都是流水线架构。一条指令的执行被拆成取指、译码、执行、写回等多个阶段。理想情况下，每个时钟周期都能完成一条指令。
但问题来了——遇到分支指令（比如if、switch）怎么办？CPU不知道下一步该取哪条指令。于是它开始猜。猜对了，流水线继续跑。猜错了，流水线要清空重来，浪费十几个时钟周期。
这就是分支预测。CPU内部有个分支预测器，根据历史记录猜分支走向。猜对了万事大吉，猜错了代价惨重。
我举个例子：
// 坏代码：分支难以预测
for (int i = 0; i < N; ++i) {
if (data[i] > threshold) {
// 处理
}
}
// 好代码：分支可预测
for (int i = 0; i < N; ++i) {
// 用位运算代替分支
int mask = (data[i] > threshold) - 1;
result[i] = data[i] & mask;
}第一个例子中，如果threshold是随机值，分支预测器猜对的概率只有50%。每次猜错浪费15个周期，性能直接打对折。
第二个例子用位运算消除了分支，虽然代码可读性差了点，但性能提升是实打实的。
实战建议：在高频交易的核心路径上，尽量用无分支代码。比如用std::min/std::max代替if判断，用查表代替switch。我见过一个策略，把核心循环里的分支去掉后，延迟从12微秒降到了7微秒。
3.5 知识体系总览
下面这张图把本章的核心逻辑串起来了。你可以看到，从CPU到内存，每一层都有性能陷阱。理解这些，你才能写出真正低延迟的代码。
嗯，这张图把今天讲的内容都串起来了。从CPU核心到L1/L2/L3缓存，再到主内存，每一层都有明确的延迟数字。NUMA架构告诉我们，跨节点访问要付出额外代价。分支预测和流水线则提醒我们，代码里的每个if都可能成为性能杀手。
我个人觉得，理解这些硬件细节，是写出高性能高频交易代码的第一步。你不需要成为硬件专家，但至少要知道：你的代码在硬件上是怎么跑的，瓶颈可能在哪里。
最后一个小建议：每次写完核心代码，用perf stat看看缓存命中率和分支预测失败率。如果L1 miss率超过5%，或者分支预测失败率超过2%，那就要认真优化了。我曾经靠这个办法，把一个策略的延迟从15微秒降到了6微秒。
公众号:蓝海资料掘金营，微信deep3321