第1章：Cache一致性协议——多核系统的“交通规则”

大家好，我是你们这堂课的主讲人。在服务器SoC领域摸爬滚打了十几年，我见过太多因为Cache一致性问题导致系统崩溃的案例。今天咱们就来聊聊这个核心话题——Cache一致性协议。

说白了，多核处理器就像一个大城市，每个核心都有自己的“小仓库”（Cache）。问题来了：当Core 0改了某个数据，Core 1还傻乎乎用着旧版本，那程序就跑飞了。Cache一致性协议，就是给这些核心定下的“交通规则”。

1.1 MESI协议：最经典的“四态”模型

MESI协议，我习惯叫它“四兄弟协议”。每个Cache Line有四种状态：

状态	全称	含义
M	Modified	数据被修改，且与主存不一致
E	Exclusive	数据干净，仅本核心持有
S	Shared	数据干净，多个核心共享
I	Invalid	数据无效，需要重新加载

我在项目中遇到过一个问题：某个核心频繁读写同一块数据，导致总线上的“Invalid”消息满天飞。你想想看，每次写操作都要通知其他核心，这性能能好吗？

举个实际例子：Core 0要修改变量X，它先发一个“Invalidate”广播。Core 1收到后，把自己Cache里的X标记为I。Core 0确认所有核心都失效了，才放心修改。嗯，这里要注意：如果Core 1恰好也在写X，那就得靠“总线仲裁”来分先后了。

1.2 MOESI协议：多了一个“O”的智慧

MESI有个痛点：当数据在多个核心间共享时，每次修改都要写回主存。MOESI协议加了个“O”（Owned）状态，完美解决了这个问题。

O状态的意思是：数据被修改了，但还没写回主存。其他核心可以读这个“脏数据”，但不能写。我做过一个测试，在16核的服务器上，MOESI比MESI减少了约30%的主存访问量。

为什么会这样？因为“O”状态允许核心间直接传递数据，不用绕道主存。你想想看，这就像几个同事共享一份文件，有人改了之后直接传阅，而不是每次改完都去复印一份放档案室。

1.3 目录协议：告别广播风暴

MESI/MOESI在核心少的时候还行，一旦超过8个核心，广播消息就会把总线堵死。我见过一个32核的服务器，因为一致性广播导致总线利用率飙到95%，CPU都在等消息。

目录协议就是解决方案。它维护一个“目录表”，记录每个Cache Line被哪些核心持有。当Core 0要修改数据时，只给持有该数据的核心发消息，而不是全网广播。

目录协议有三种常见实现：

• 全目录（Full Directory）：每个目录项记录所有核心的位图。简单但存储开销大。
• 稀疏目录（Sparse Directory）：只记录活跃的共享者。省空间，但查找复杂。
• 树形目录（Tree Directory）：用树状结构组织核心。适合大规模系统。

1.4 Snoop过滤器：硬件级的“智能助手”

Snoop过滤器是个好东西。它本质上是一个硬件表，记录每个Cache Line的“可能位置”。当总线出现Snoop请求时，过滤器先查一下：如果数据不在某个核心的Cache里，就直接过滤掉，不用那个核心响应。

我参与过一个项目，用了Snoop过滤器后，无效的Snoop请求减少了70%。但要注意：过滤器本身也有延迟，设计不好反而拖慢速度。

1.5 一致性流量分析与优化

好了，理论讲完了，咱们来点实战。一致性流量分析，说白了就是看总线上的“Invalidate”、“Read”、“Write”这些消息有多少，谁在发，发给谁。

我常用的分析工具是性能计数器。比如：

• 总线事务数：每秒有多少一致性消息
• Snoop命中率：Snoop请求中，目标数据在Cache里的比例
• 目录命中率：目录查询成功的比例

优化方向有三个：

1. 减少写失效：用“写更新”代替“写失效”，但实现复杂，我一般只在特定场景用。
2. 优化数据布局：把经常一起访问的数据放在同一个Cache Line，减少跨核心的共享。
3. 调整协议参数：比如MESI的“写回”阈值，MOESI的“O”状态转换条件。

最后，我画了一张图，帮大家理清这几种协议的关系：

这张图把四种技术的关系理清楚了。MESI是基础，MOESI是优化，目录协议解决扩展性问题，Snoop过滤器是性能加速器。实际项目中，我通常会把目录协议和Snoop过滤器结合使用，效果最好。

---

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