单核时代，缓存一致性几乎不是问题：一个核独占一份缓存，写回主存之前谁也看不到中间状态。多核一来，麻烦就来了：每个核都有自己的L1、L2，同一块内存可能同时躺在几十个核的缓存里。一个核改了数据，其他核手里的旧副本必须失效或者更新，否则程序读到的就是过期值。保证“大家看到的是同一份内存”，就是缓存一致性协议要干的活，而这份保证的代价，正随着核数一路上涨。

最经典的协议是MESI：每个缓存行有四种状态，修改态、独占态、共享态、无效态。读一个共享行，核要先广播“我要读”；写一个共享行，要先发失效消息，让其他核把副本作废。小规模系统里这套机制简单可靠，因为总线本身就是天然的广播通道，所有核都能在同一个时刻听到同一条消息，顺序问题由总线仲裁兜底。

但广播的代价是随核数平方级增长的。核数翻倍，失效消息和监听流量不止翻倍，因为每个写操作都要打扰所有核，哪怕其中大多数根本不关心这块数据。更要命的是，总线带宽和监听端口成了瓶颈：每个核的缓存控制器都要时刻监听总线，判断每条消息与自己有没有关系，监听本身就要消耗功耗和面积。核数到几十个时，监听式协议的流量和功耗就先撑不住了。

于是大规模系统转向目录协议：不再广播，改由一个目录记录“这块数据现在在哪些核手里”。写操作只通知目录里登记的持有者，流量从广播变成了点对点。代价是目录本身要存状态、要处理并发请求，还要处理目录与缓存之间往返的延迟：一次写失效可能要经过目录中转，延迟比总线广播更高，目录还可能成为热点和单点瓶颈。目录协议省带宽、花延迟，监听协议省延迟、花带宽，这是第一层取舍。

MOESI在MESI基础上加了一个Owned态：允许一个核以“脏共享”的状态把修改过的数据直接转发给其他核，而不必先写回主存。这对生产者—消费者模式很友好，数据可以在核间直接传递，少跑一趟内存。但状态机更复杂了，验证和调试的难度也随之上升：多一个状态，状态组合和竞争窗口就多一截，形式化验证的工作量明显变大。工程上没有免费的状态，每加一个状态都要问一句：这条转发路径在真实负载里到底能省多少访存。

更深一层，协议的选择还要看访存模式。共享读多、写少的负载，广播协议的失效风暴本来就不频繁，简单就是美；写共享数据频繁的负载，目录协议的精确通知才能把无效流量压下来。还有伪共享这个老对手：两个核各写同一个缓存行的不同字段，协议层面看是同一行在来回失效，性能塌下来，根因却在数据布局。很多时候先调数据结构、把热点字段拆到不同缓存行，比换协议见效更快。

实操上建议三条。第一，先用性能计数器确认一致性流量是不是真瓶颈：失效次数、跨核转发、目录未命中率，先有数据再谈换协议。第二，评估核数天花板：十几个核以内监听协议往往够用，几十核以上目录几乎是必选项。第三，别把一致性当成纯硬件问题：线程亲和性、数据分片、减少共享写，这些软件层面的改动，经常比协议选型省下更多开销。一致性协议越来越贵，本质是“共享”本身越来越贵，好的设计是先少共享，再谈怎么一致。