4、目录式一致性协议：基于目录的缓存一致性（Directory-based Coherence），适用于大规模系统的设计思路
大家好，我是你们的老朋友。今天我们来聊聊大规模系统里的缓存一致性方案——目录式协议。
说实话，我刚开始接触分布式存储的时候，对缓存一致性的理解还停留在“广播”阶段。那时候觉得，只要我把所有节点的缓存都通知一遍，不就完事了吗？后来在真实项目中碰了壁，才明白事情没那么简单。
你想想看，一个几百个节点的大集群，每次写操作都要广播给所有人？那网络带宽早就被撑爆了。嗯，这就是目录式协议要解决的核心问题。
4.1 为什么需要目录？
我们先看一个场景。假设你有 64 个节点，每个节点都缓存了同一份数据块。现在节点 0 要写这个块。按照传统的监听式协议（Snooping），节点 0 得在总线上吼一嗓子：“我要写这个块了，你们谁有缓存都给我失效掉！”
这在 4 个、8 个节点的小系统里还行。但到了 64 个、128 个节点呢？总线上的广播风暴会直接让系统瘫痪。我在一个项目中就遇到过这种情况——节点数一超过 32，写操作的延迟直接飙升到不可接受的程度。
目录式协议的核心思路很简单：我不问所有人，我只问需要知道的人。
怎么做到的呢？就是给每个缓存块配一个“目录项”。这个目录项记录了：
- 当前哪些节点缓存了这个块
- 每个缓存的状态是什么（共享、独占、修改等）
- 哪个节点拥有最新版本
核心思想：目录就是一张“谁有谁没有”的清单。写操作时，只通知清单上的人，而不是广播给所有人。
4.2 目录的结构与存储
目录本身也是要占内存的。我习惯把目录分为两种：
| 类型 | 描述 | 适用场景 |
|---|---|---|
| 全映射目录 | 每个目录项记录所有节点的缓存状态 | 节点数较少（< 64） |
| 有限指针目录 | 每个目录项只记录有限个共享者（如 4 个指针） | 大规模集群（> 64 节点） |
全映射目录好理解，但开销大。每个目录项需要 N 个 bit（N 是节点数）。64 个节点就是 64 bit，还行。但 1024 个节点呢？每个目录项 1024 bit，128 字节。如果缓存块大小是 64 字节，目录开销就是数据本身的 2 倍。这谁受得了？
所以在大规模系统里，我建议用有限指针目录。每个目录项只记录 4 个或 8 个共享者。如果超过这个数，就退化为“广播模式”或者用位图来兜底。
我的经验：在 128 节点以下的集群，用全映射目录比较省心。超过这个规模，一定要用有限指针。我曾经在一个 256 节点的项目里硬上全映射，结果目录内存占用了总内存的 15%，被老板骂了一顿。
4.3 目录协议的状态机
目录式协议的状态机比监听式复杂一些。我以经典的 MSI 协议为例，加上目录后，每个缓存块的状态变成了：
- M（Modified）：当前节点独占且已修改，目录中记录该节点为拥有者
- S（Shared）：多个节点共享，目录中记录所有共享者列表
- I（Invalid）：当前节点没有缓存，目录中不记录该节点
但这里多了一个角色——目录控制器（Directory Controller）。它负责：
- 接收来自缓存节点的请求（读、写、失效）
- 查询目录项，确定需要通知哪些节点
- 发送消息给目标节点
- 等待响应，更新目录状态
说白了，目录控制器就是个“消息路由器”。它不存数据，只存元数据。
4.4 一个完整的读写流程
我们走一遍流程，你就明白了。
场景：节点 0 要写一个缓存块，该块当前被节点 1、节点 2、节点 3 共享。
- 节点 0 发送“写请求”给目录控制器
- 目录控制器查目录，发现共享者列表是 [1, 2, 3]
- 目录控制器发送“失效消息”给节点 1、2、3
- 节点 1、2、3 收到消息，将本地缓存置为 Invalid，并回复 ACK
- 目录控制器收到所有 ACK 后，更新目录：拥有者 = 节点 0，状态 = Modified
- 目录控制器回复节点 0：“你可以写了”
- 节点 0 开始写操作
你看，整个过程只涉及 4 个节点（节点 0 + 3 个共享者），而不是全部 64 个节点。这就是目录式协议的优势。
注意：这里有一个常见的坑。如果某个共享者节点已经挂了或者网络分区了，目录控制器收不到 ACK，就会一直等下去。我曾经在一个项目中遇到过这种情况，最后不得不引入超时机制和重试逻辑。嗯，分布式系统里，超时永远是你的好朋友。
4.5 目录协议的优化变种
在实际工程中，我们不会直接用最朴素的目录协议。太慢了。我常用的优化手段有：
- 目录缓存：把热点数据的目录项缓存在本地，减少远程目录查询
- 目录分片：把目录按哈希分到多个节点上，避免单点瓶颈
- 惰性更新：不是每次写操作都立即更新目录，而是批量处理
举个例子，我在做分布式缓存系统时，把目录分成了 16 个分片，每个分片由一个独立的线程处理。这样目录控制器的吞吐量提升了 8 倍左右。
4.6 目录 vs 监听：怎么选？
很多同学问我：“到底用目录还是用监听？”我的回答是：看规模。
| 维度 | 监听式（Snooping） | 目录式（Directory） |
|---|---|---|
| 节点数 | 适合 2-16 节点 | 适合 16-1024+ 节点 |
| 通信方式 | 广播 | 点对点 |
| 延迟 | 低（总线快） | 中等（需要查目录） |
| 扩展性 | 差 | 好 |
| 实现复杂度 | 简单 | 复杂 |
我个人习惯是：8 节点以下用监听，8-32 节点看情况，32 节点以上直接上目录。别犹豫。
4.7 核心知识体系
下面这张图是我自己画的，帮你理清目录式协议的核心逻辑：
从这张图你可以看到，整个流程是“请求→查目录→定向通知→收ACK→授权”。每一步都是点对点通信，没有广播。这就是目录式协议能支撑大规模系统的根本原因。
4.8 避坑指南
最后，分享几个我在项目中踩过的坑：
- 目录一致性本身也需要一致性：目录控制器如果挂了，整个系统就失去了缓存一致性的保障。一定要做目录控制器的冗余或主备切换。
- 目录更新延迟：如果目录更新不及时，可能会出现“脏读”。我建议用版本号或时间戳来检测冲突。
- 不要忽略目录的存储开销：尤其是全映射目录，在节点数多的时候，目录内存可能比数据本身还大。提前做好容量规划。
我的建议：如果你刚开始接触目录式协议，先从 16 节点的全映射目录开始练手。等理解了状态机和消息流程，再尝试有限指针和分片优化。别一上来就搞复杂的变种，容易把自己绕晕。
好了，目录式一致性协议就讲到这里。记住一句话：目录的本质，是用元数据换带宽。你多花一点内存存目录，就能省下大量的广播流量。在大规模系统里，这笔买卖是划算的。
公众号:蓝海资料掘金营，微信deep3321