多核Cache一致性与监听目录协议

可视化演示

Cache一致性协议保证多核环境下各核心缓存数据的一致性，监听协议和目录协议是两种主流实现。本文讲解Cache... 切换模式查看不同维度。

问题产生：多核缓存为何冲突

会议室的白板和草稿本大家都熟悉了：白板是共享内存，小草稿本是每个核心的私有 Cache。现在的多核 CPU 里，所有核心都通过总线连接同一块内存，但每个核心访问自己的 Cache 比访问内存快几十倍，于是同一个地址的数据就可能同时出现在白板和多个草稿本上，形成内容一致的多个副本。问题在于：草稿本上的副本是“私有”的，核心 B 根本不知道核心 A 在自己的草稿本上改了什么。只要有人改了白板而其他人仍用旧草稿，大家看到的数值就会相互矛盾。

在计算机体系结构中，这种矛盾被称为“Cache 一致性（Cache Coherence）问题”。它有三个典型症状：一是写后读不一致——小明写进去新值，小红读出来的却是旧值；二是读后写乱序——小红先读到旧值、后读到新值，逻辑顺序颠倒；三是写写冲突——两个核心同时改同一个变量，最后白板上到底是谁的值说不清。简单说，只要多个核心同时缓存同一个地址并允许各自修改，就必然面临这个难题。

要解决它，技术上必须满足一个形式化条件：对同一地址的所有读写操作，让每个核心都观察到一致的顺序，而且一旦某个核心写入了新值，后续其他核心的读操作必须看到这个新值。可以用下面的公式来表达这个“一致性契约”：

这条契约写起来简单，实现起来却大有讲究。正因为草稿本上的副本是多个核心自扫门前雪，才需要一套“通知机制”让大家同步认知。而通知方式的不同，就分化出了接下来要讲的监听协议和目录协议两大门派。房间还是那个房间，白板还是那个白板，区别只在于——你是选择喊一嗓子让所有人听见，还是请一位前台逐一向相关的人发通知。

监听协议：广播让所有人听见

“我把预算改成 7 万了！”办公室里，小明选择最直接的方式——扯着嗓子喊了一声。因为房间不大，这一嗓子所有人都听见了。小红听到后立刻去翻自己的草稿本，发现“预算=5 万”已经作废，于是重新抬头看白板抄了个 7 万。这个方案不需要任何登记记录，唯一的规则就是：谁改白板，谁喊全屋。这就是“监听协议（Snooping Protocol）”的直觉原型。

在真实硬件里，那个“房间”就是系统总线——所有核心和内存都挂在同一条总线这根“晾衣绳”上。总线天然具有广播特性：任何核心在总线上发出一条事务（读、写、失效请求），其他所有核心都能看到。每个核心内部都有一个“监听器”（Snooper），像竖起的耳朵一样持续监视总线流量。当核心 A 发起写操作时，它把请求广播到总线上；核心 B 的监听器发现这条事务与自己缓存的地址相关，就立刻对自己的副本做相应处理（比如标成失效）。

监听协议最大的优点是简洁：不需要额外状态记录“谁存了什么”，因为每个核心自己会竖起耳朵听。但代价也很明显——每次写操作都要向所有核心广播，哪怕只有两个核心真正持有这份数据。如果系统里的核心数为 $N$，每一次写操作都需要发送 $N-1$ 条广播消息：

这样看来，监听协议在小房间（少量核心）里非常高效，因为总线带宽充足、广播成本低。可一旦房间变大，同事变到几十上百号人，每次改数字都要吼一嗓子，再大的房间也会被吵得没法工作。核心数量少时监听协议近乎完美，核心数量一多它就成了瓶颈——这也直接引出了人们对“只通知需要知道的人”的渴望，也就是目录协议登场的理由。

目录协议：台账让通知更精准

会议室请来了一位前台服务员，她手里有一本台账：谁抄了白板上的哪块内容、谁持有哪份草稿的副本，都记得清清楚楚。当小明改掉白板上的预算时，他不用喊话，只需要告诉前台“我改了预算”。前台翻了翻台账，发现只有小红一个人抄了预算，于是只给小红打了个内线电话：“你草稿本上的预算作废了，重新抄一下。”其他人完全不受打扰。这就是“目录协议（Directory Protocol）”的核心思想——用一份集中登记的数据结构来追踪副本位置。

这份台账在硬件中就是“目录（Directory）”，它记录着每个共享内存块被哪些核心的 Cache 缓存了。目录按缓存块逐条建立表项，每个表项含一个“位向量”，每一位对应一个核心，标志该核心是否持有本块的副本。当核心 A 要写某一块数据时，先向目录发送请求；目录查到共享者列表后，只向这些共享者发失效通知，等确认失效后再允许 A 写入，同时把共享者列表更新为只含 A。

目录协议换来的收益是写操作的消息量从“广播给所有人”降为“只通知相关者”。当然天下没有免费的午餐，目录本身需要存储和维护成本，其存储量正比于缓存块数与核心数的乘积，而一次失效通知的成本正比于真正共享者的人数：

前台记账虽然多花了一笔人力，却让大办公室的工作效率显著提升。目录协议的核心价值在于“把广播变成点对点”：当共享者 $N_s \ll N$ 时，省下的总线流量非常可观。不过，这份台账本身也要占用宝贵的内存空间，而且每次写请求都要先问目录、等它确认，引入了一步额外的延迟。索引结构和查询效率于是成了目录协议设计中的关键议题。

写失效与写更新：两种同步策略

前台决定通知小红“你的草稿作废了”，但“通知”这个动作有两种喊法。第一种是只喊一句：“你抄的预算作废了，自己重新来看白板！”——这叫“写失效（Write Invalidate）”。它只发送一条地址级别的失效消息，消息很轻，但小红之后必须重新读一次白板才能拿到新值。第二种是直接把新数字报给她：“预算改成 7 万了，你直接改草稿！”——这叫“写更新（Write Update）”。它把完整的新数据块随消息一起发送，消息很重，但小红不需要再跑一趟白板。

两种策略在通信量上的差异一目了然：写失效每次写操作向每个共享者发送一条小地址消息，写更新则要向每个共享者发送一条包含整个数据块的大消息。如果核心反复写同一个变量，写更新的数据块会反复传输，总线压力骤增；而写失效只需要第一次发一条小消息，后续由读者在需要时按需重新拉取数据。

这一节其实是在为后面的 MESI 状态机做铺垫：绝大多数现代处理器（如 x86 的 MESI 家族、ARM 的 MOESI）都选择了“写失效 + 缓存重新拉取”的路线，因为数据块通常很大，反复传输代价太高。但如果是“共享者很少、数据块很小、写频率低”的特殊场景，写更新反而能让读者立即拿到最新值、减少重读延迟。选谁看场景，就像通知同事一样：关系少就逐个打卡，关系多就贴公告让本人来查。

MESI状态机：草稿本上的四色标签

前台发现，与其每次都费劲通知，不如给办公过程中的每份草稿加一个标签，让所有人一看标签就知道自己这份草稿处于什么状态。于是四个标签被发明了出来，这就是大名鼎鼎的 MESI 协议。M（Modified，修改）：我改了白板上的这块内容，草稿本上是最新值，而且改成只有我一份；E（Exclusive，独占）：白板内容和我草稿本一致，而且这内容只被我一个人抄了；S（Shared，共享）：这份内容被多个同事都抄了，大家都一致；I（Invalid，失效）：我的这份草稿作废了，要看真实内容得重新抄。

这四个标签的精髓在于“状态决定要不要喊话”：如果我的标签是 E，意味着这块内容只在我手上，我改动它根本不用通知任何人，改完直接升级为 M 即可；如果标签是 S，说明别人也有副本，我改动前就必须广播失效消息把别人的副本变成 I。状态定义中的核心关系可以浓缩成一个公式：

MESI 的巧妙之处在于用“状态”换“消息”：独占时少发一次广播，失效时少读一次内存。这就像草稿本上贴标签让每个人心里有数——我知道自己这份是独家的，就放心大胆地改；知道是共享的，就先喊一声让大家作废旧版。不过，MESI 只是一个状态框架，真正落地时它要分别与监听协议和目录协议结合，于是我们能看到两种风格迥异的演绎。

监听模式下的MESI：喊话与标签配合

监听协议配上 MESI 标签，会议室里形成了一套完整的“喊话规则”。所有核心依然靠总线广播感知全局，但不再需要盲目地广播每一次写操作：当核心的缓存行处于 E 状态时，它写本地副本无需任何总线事务，页角标签直接从 E 翻到 M；当缓存行处于 S 状态时，它知道自己不是唯一副本，必须先向总线广播一条“升级请求（Upgrade）”，等总线上的其他核心把各自的 S 副本失效掉，自己才能动笔。这就是“总线嗅探（Bus Sniffing）+ 总线升级”的 MESI 监听实现。

每一次状态转换都对应着是否使用总线的决策。可以数一数总线事务的消耗：E 状态本地写是零总线事务，S 状态升级写是一次总线事务，而如果缓存行是 I 状态，写之前还得从内存或共享者手里把数据“抢”过来，那就要额外的读事务。这正是 MESI 相对朴素写失效协议的精髓——尽可能把缓存行压进 E 状态，用“独占”豁免广播：

监听式 MESI 在小型处理器（2~8 核的桌面 CPU、嵌入式多核）里极为成功，因为它实现直接、延迟低。但这条“喊话”路线天生受限于总线：每个核心都要监听总线上的全部事务，当核心数超过双位数后，总线冲突和广播流量会剧烈恶化系统性能。这是监听模式的硬伤——它注定只为“小房间”设计，而不是为“千人礼堂”准备的。

目录模式下的MESI：台账与标签配合

目录 + MESI 的组合则展示了另一种优雅：让前台台账接手“谁持有副本”的追踪。核心的缓存行仍然是 M/E/S/I 四种标签，但“到底哪些核心持有 S 副本”这个信息不再靠大家在总线上侧耳倾听，而是集中在目录的位向量里。每次写操作时，写核心先向目录提交写请求，目录查询共享者位向量，只向真正持有共享副本的核心发送失效消息，让它们把 S 标成 I，然后授予写者修改权，写者再把自己的标签从 S/E 翻到 M。

两者最大的差异可以浓缩成一条失效消息的对比：监听模式下，写者必须向除自己外的所有核心广播失效消息，消息数为 $N-1$；目录模式下，写者只向共享者列表中的核心发失效，消息数为 $N_s$。在共享者远少于总核心数的负载里，目录模式的省流是数量级的：

目录式 MESI 在大型多核服务器、片上网络（NoC）多核系统中成为主流选择。它付出的代价是目录查找多一跳的请求延迟，以及目录存储本身的内存开销，但随着核心数增长，这笔“台账成本”远比“无脑广播”廉价。从架构演变看，现代 CPU 常常采用混合路线：小规模集群用监听、集群之间用目录，形成层级化一致性，这为下一节的权衡取舍埋下了伏笔。

可扩展性权衡：选监听还是目录

现在，会议室的问题终于回到了台面上：到底该喊话还是该记账？答案取决于房间多大、白板多值钱。监听协议的优势是零台账成本、端口延迟低，但每核心分到的有效总线带宽会随核心数的增加而快速耗尽——把总线看成一个共享的传声筒，房子里的每个人都在同时说话，人越多，每个人能分到的“说清一句话”的带宽就越少。当核心数增长到几十上百，广播风暴会让几乎所有总线时间都被一致性消息占满，真正干活的传输微乎其微。

目录协议则用存储换带宽：它放弃一部分内存给目录表，换来的是写操作通信量从 $O(N)$ 降到 $O(N_s)$，可扩展性显著更好。但它也有成本——目录表本身要占内存，目录查询增加一次握手延迟，目录控制器还会成为新的热点。因此，实际系统中出现了“分层选择”的智慧：8 核以内的桌面处理器普遍采用监听式 MESI（如 Intel 消费级 CPU 的核心间组合）；数十核的服务器芯片则使用目录式或混合式协议（如 AMD EPYC 的 CCX 内部用监听、CCX 之间用目录）。衡量指标可以用最朴素的总成本函数表达：

这节讨论其实已经超越了单一处理器：当 AI 工程师部署 GPU 集群、分布式缓存或多节点数据库时，面对的是同一对权衡——是用广播让全网同步（对应监听模式），还是维护一份元数据按订阅者推送（对应目录模式）。选监听的人要控制规模，选目录的人要管理元数据开销，而聪明的架构往往两者并用。会议室的故事告诉我们：没有绝对优劣，只有合不合适。

AI 应用场景

Python 演示

class CacheLine:    def __init__(self, core_id):        self.core_id = core_id        self.state = 'I'        self.value = None  def simulate(actions, use_directory=False, n_cores=4):    caches = [CacheLine(i) for i in range(n_cores)]    sharers = set()    msg_count = 0     for core, op, val in actions:        if op == 'read':            sharers.add(core)            if caches[core].state == 'I':                msg_count += 1                caches[core].state = 'S'            else:                msg_count += 1                caches[core].state = 'S'        else:  # write            if use_directory:                targets = [s for s in sharers if s != core]                msg_count += len(targets)            else:                msg_count += n_cores - 1            for i in sharers:                if i != core:                    caches[i].state = 'I'            caches[core].state = 'M'            caches[core].value = val            sharers = {core}    return msg_count  def main():    actions = [        (0, 'read', None),        (1, 'read', None),        (0, 'write', 7),        (1, 'read', None),        (0, 'write', 9),    ]    snoop_msg = simulate(actions, use_directory=False)    dir_msg = simulate(actions, use_directory=True)    print('监听协议消息数:', snoop_msg)    print('目录协议消息数:', dir_msg)    print('目录比监听节省:', snoop_msg - dir_msg, '条消息')  if __name__ == '__main__':    main()

1. sharers = set()记录当前持有某缓存块副本的核心集合，相当于目录协议中的台账。
2. msg_count += n_cores - 1监听模式下每次写操作都要广播给除自己外的所有核心，消息数与总核心数线性挂钩。
3. targets = [s for s in sharers if s != core]目录模式下只挑选真正共享该块的核心作为失效通知对象，这就是按需通知。
4. caches[i].state = 'I'收到失效消息的核心把对应缓存行置为 I（Invalid），下次读取必须重新拉取。
5. sharers = {core}写完成后写者是唯一持有有效副本的核心，台账同步更新，为后续写操作省下通知成本。

常见误区

面试题