← 返回索引 · 2026-02-16 · 0010

剖析C++撮合引擎性能之核：内存布局与缓存行优化（摘要）

原文首发于 TechNova： 剖析C++撮合引擎性能之核：内存布局与缓存行优化

承接页（解决方案）：https://technologynova.org/solution/

1. 你看到的现象：吞吐还行，但延迟“突然变差”

典型症状是：并发上去后平均延迟开始非线性增长，甚至在负载看似平稳时，P99 也会出现不规律的“毛刺”。Profiling 发现撮合逻辑本身并不吃 CPU， 但 perf 一看：stalled cycles 占比很高——CPU 不是在算，而是在等内存。

2. 关键原理：缓存行是物理单位，不是“变量”

• 缓存行（Cache Line）常见是 64B：读一个 int，CPU 往往把所在 64B 整块搬进 L1。
• 空间/时间局部性决定命中率：你的数据布局越“紧凑、连续、可预测”，越容易命中。
• 跨缓存行访问会把一次读变两次读；更糟的是，一旦穿透到 DRAM，代价可能是几百个 CPU 周期。

3. 最容易忽视的坑：伪共享（False Sharing）

工程上的第一反应不是加锁，而是先把数据隔离： 对每线程统计/计数/水位线类字段，使用 alignas(64) 或 C++17 的 hardware_destructive_interference_size， 再用 padding 把结构体尺寸撑到缓存行整数倍。

4. 数据结构策略：冷热分离 + AoS → SoA（或至少“热字段紧凑化”）

• 反模式（AoS）：一个 Order 里塞几十个字段（user_id、timestamp、风控字段……），撮合时却只用 price/qty/side。每次加载都把冷数据带进缓存，污染缓存。
• 推荐做法：把撮合热数据单独放（hot pool），冷数据另放（cold pool）。撮合遍历只碰 hot pool，缓存行更“值钱”。
• 落地诀窍：先用基准测试确认“热字段集合”，再逐步拆；不要一开始就把工程复杂度拉满。

5. 系统级优化：让你写的“缓存友好代码”不被调度打烂

• 内存池（Memory Pool）：撮合里订单创建/销毁高频，直接 new/delete 会引入抖动与碎片，破坏局部性。预分配 + 复用能显著稳定延迟。
• CPU 亲和性（Affinity/Pinning）：线程迁核会导致 L1/L2 缓存瞬间作废，你前面做的布局优化等于白做。
• NUMA 感知：多路 CPU 机器上，跨 NUMA 节点访问远程内存会更慢；要尽量保证撮合线程与订单簿/订单池在同一节点。

6. 适用场景：什么时候这套“硬核内存优化”最值

• 你关心的不是 QPS，而是微秒级延迟与尾延迟稳定性（P99/P999）。
• 系统在多核扩展时“越加核越不线性”，怀疑是缓存一致性/伪共享导致。
• perf / PMU 指标显示 cache-miss、stalled cycles、CPI 异常偏高。
• 撮合核心本身是确定性/单线程或分片模型，能明确界定“谁在写什么数据”。

---