计算机体系结构基础：CPU架构、内存层级、缓存一致性、NUMA架构对吞吐的影响

吞吐优化这件事，说到底就是跟计算机的“物理规律”打交道。你写的代码再漂亮，如果底层硬件不买账，性能照样上不去。今天我们就来聊聊计算机体系结构里那几个最影响吞吐的关键点。

早期的CPU是单核的，那时候优化很简单——把指令排排队，让流水线别闲着就行。但到了多核时代，事情就复杂了。

我个人习惯把CPU架构分成三类：

我在项目中遇到过一个问题：一个8核的服务器，跑一个并行计算任务，按理说应该接近8倍加速。结果呢？只快了不到3倍。查了半天，发现是缓存一致性协议在作祟——核心之间为了维护数据一致性，花了大量时间在“握手”上。

核心观点：多核不是万能的。核心越多，通信开销越大。吞吐优化的第一步，是搞清楚你的瓶颈到底在CPU计算，还是在核心间的数据同步。

你想想看，CPU的主频已经到3GHz甚至更高，而内存的访问延迟还在100纳秒级别。这中间的差距，全靠缓存来填。

典型的缓存层级是这样的：

看到这个延迟差距了吗？L1缓存比主存快了整整两个数量级。说白了，如果你的数据能塞进L1缓存，吞吐就能起飞；如果频繁缺页、缓存未命中，性能就一落千丈。

我曾经优化过一个数据库查询引擎，核心操作就是遍历一个哈希表。原始实现里，哈希表节点是随机分配的，导致每次访问都触发缓存未命中。后来我把节点改成连续内存布局，配合预取指令，吞吐直接翻了3倍。嗯，这就是缓存友好的威力。

优化技巧：写代码时尽量保证数据访问的局部性——时间局部性（重复访问同一块数据）和空间局部性（访问相邻数据）。数组遍历比链表遍历快，就是这个道理。

多核CPU里，每个核心都有自己的L1/L2缓存。如果核心A修改了变量x，核心B读到的还是旧值，那程序就乱套了。所以需要一套协议来保证所有核心看到的数据是一致的。

最常见的协议是MESI（Modified, Exclusive, Shared, Invalid）。每个缓存行有四种状态：

当一个核心要写入一个共享变量时，它必须先通知其他核心把对应的缓存行标记为无效。这个过程叫“缓存一致性协议消息传递”，是有开销的。

我记得有一次排查一个高并发服务的性能抖动，发现每秒有上百万次缓存一致性消息在核心之间传递。原因很简单——多个线程频繁修改同一个锁变量。后来改成读写锁分离，消息量降到了原来的十分之一，吞吐就稳了。

避坑指南：我曾经见过一个团队，为了“性能”把共享变量声明为volatile，结果反而更慢了。为什么？因为volatile强制每次读写都走主存，绕过了缓存。在大多数场景下，用volatile不如用原子操作+内存屏障来得实在。

NUMA（Non-Uniform Memory Access）是现代服务器的主流架构。每个CPU插槽有自己的内存控制器，访问本地内存快，访问远端内存慢。

NUMA架构的典型拓扑：

Node 0: CPU 0-3, 内存 64GB
Node 1: CPU 4-7, 内存 64GB
Node 0 访问 Node 1 的内存：延迟增加 30%-50%

为什么会有NUMA？因为内存带宽不够用了。如果所有核心都挤在同一条内存总线上，带宽很快就饱和了。NUMA把内存分散到各个节点，每个节点有独立的内存通道，总带宽就上去了。

但NUMA也有代价——跨节点访问慢。如果你的线程在Node 0上运行，却频繁访问Node 1的内存，性能就会打折扣。

我优化过一个内存数据库，初始版本把所有数据均匀分布在所有NUMA节点上。结果呢？每个线程有一半的访问是跨节点的，延迟高得离谱。后来改成“线程绑定+数据本地化”——每个线程只处理自己所在节点的数据，吞吐提升了40%。

NUMA优化原则：

下面这张图概括了本章的核心内容，从CPU架构到内存层级，再到缓存一致性和NUMA，它们共同决定了系统的吞吐上限。

这张图把四个核心模块串起来了。CPU架构决定了核心怎么组织，内存层级决定了数据访问的速度，缓存一致性保证了多核协作的正确性，NUMA架构则影响了内存访问的局部性。任何一个环节出问题，吞吐都会受影响。

我的建议：做吞吐优化时，先画一张这样的图，标出你的系统在哪个环节可能成为瓶颈。然后针对性地做实验、调参数。别一上来就改代码，先搞清楚“敌人”在哪。

好了，这一章的内容就到这里。理解这些底层原理，你才能写出真正高性能的代码。下一章我们聊聊具体怎么测量和分析吞吐瓶颈——嗯，到时候见。