最近碰到一个问题，事后想想，很适合拿来讲分布式系统里一个很普遍的现象：一个在单节点上简单到不用过脑子的事，放到多节点环境下，复杂度会一层一层地叠上去，每加一层，就多一类你绕不开的问题。
单节点：两个 if 的事
需求是这样的：用户请求来了，需要从 S3 拉一份代码到本地，解压，然后执行。这里的 S3 指兼容 S3 协议的对象存储，简单理解就是一个可以按路径下载文件的远程存储服务。
为了避免同一份代码被反复下载，流程里加了一步：先看本地有没有，有就跳过，没有再拉。
单节点上，这个逻辑简单到不需要设计：
markdown
if (文件不存在) {
下载并解压
}
执行就两个 if，没了。你甚至不会觉得这是个需要讨论的问题。
但这里藏了一个前提：判断和执行发生在同一个进程里，中间没有别人能插一脚。 文件存在，你就跳过；文件不存在，你就下载。检查和执行之间没有间隙。
加共享存储：文件系统不是本地的了
项目是多节点部署的，不能每个节点都存一份代码------几十个节点，一份代码复制几十份，浪费存储不说，版本管理也是灾难。所以用了 CFS，一种基于 NFS 协议的分布式共享文件系统。简单说就是所有节点通过网络挂载同一个存储卷，看起来像本地目录，但实际数据在远端，所有节点共享同一份文件。
现在问题变了。
共享文件系统意味着：节点 A 看到文件不存在，不等于下一秒文件还不存在。 节点 B 可能正在写。你的"检查"和"下载"之间，多了一个时间窗口------在这个窗口里，别人可能抢先动手了。
单节点上，检查→下载这两个动作是连续的，中间没有间隙。换成共享存储后，检查是检查，下载是下载，它们之间没有原子性保证。你检查到文件不存在，正准备开始下载，另一个节点可能已经写到一半了。
这就是经典的 TOCTOU ------ time of check to time of use。检查时的结论，到真正动手的时候已经失效了。
加多节点：谁来做？
文件系统不归你管，你也没法让所有节点排队------请求是并发的，每个节点都独立收到请求，都独立判断。
现在的问题是：多个节点同时检查到文件不存在，都认为自己应该去下载。 这不是"会不会"的问题，是"一定会"。
几十个节点，每个节点独立做判断，只要竞争窗口存在，迟早有一天两个节点会同时踩进去。结果可能是：
- 重复下载（浪费带宽和时间）
- 文件冲突（两个写操作同时往一个路径写，结果不可预期）
你需要的不是让检查更快，也不是让下载更快，而是让"判断该不该下载"这件事，在多节点之间有共识。
单节点上的那个 if，在分布式环境里变成了一道协调题：不是你能不能做，而是大家一致同意让谁来做。
每一层引入的复杂度
单节点 → 共享存储 → 多节点，每一步加的不是硬件，是一类新问题：
单节点到共享存储，把"检查和操作之间没有间隙"这个隐含前提打破了。你需要处理的不是逻辑错了，是时序错了：两个操作之间，外界状态可能会变。
共享存储到多节点，把"谁来做"变成了一个需要协调的问题。单节点上不需要问谁该做，因为只有一个进程。多节点上，每个节点都不知道别人在不在做，也不能假设别人没在做------你假设了，就是竞态条件。
有意思的是，每一步引入的问题，都不是上一层的解法能解决的。
共享文件系统上你可以用文件锁------flock、fcntl------保证同一时刻只有一个进程在写。这在单机多进程场景是标准做法，但在多节点场景下，文件锁依赖的是文件系统本身对锁操作的一致性支持 。CFS 能不能保证 flock 跨节点原子？这取决于 NFS 服务端的锁实现。有些 NFS 实现不支持跨客户端锁，有些支持但延迟很高，有些支持但锁的语义在不同客户端上不一样。
文件锁不靠谱，你就得上分布式锁（Redis、etcd、ZooKeeper）。分布式锁解决了互斥问题，但引入了新的复杂度：锁的超时怎么设？锁服务本身挂了怎么办？锁续期是推还是拉？
关键不在锁，在把窗口缩小到"只争一次"
回头看这个问题，真正让人难受的不是锁选哪个，而是每次新版本被请求时，都要走一遍"检查→抢锁→下载→释放"的流程，几十个节点同时踩进去，大部分在等锁。
换个角度看：真正需要协调的，只有文件不存在的那个瞬间。 文件一旦存在，后面的请求都是读，不需要互斥。
所以工程上的解法通常分两层：
- 先无锁检查------大多数时候文件已经在了，直接跳过，不抢锁
- 检查失败再抢锁------只在文件确实不存在的时候才去争锁，争到了就去下载，争不到就等着读
这样，锁只在"首次写入"时起作用。一旦写完，后续请求全走快路径。竞争窗口从"每个请求都在窗口里"缩小到"只有首次写入的那个瞬间"。
这是一条通用原则：不要把锁放在所有请求的必经之路上。把互斥限定在真正需要互斥的那一小段，其余时间走无锁的快速路径。
再多一层：锁争到了的人，下载完文件，做一个原子标记（比如把文件从临时路径 rename 到正式路径），这个 rename 是文件系统层面的原子操作，优雅地解决了"下载到一半被人读到"的问题。
总结
一个在单节点上只需要两个 if 的操作，放到分布式环境里，被逼着处理了：
- 时序问题（检查和使用之间状态会变）
- 协调问题（谁来做，大家得同意）
- 锁的可靠性问题（文件锁不一定跨节点生效）
- 惊群问题（几十个节点等一把锁）
每一步都不是代码逻辑错了，是假设变了。单节点的代码假设"世界是静止的"，分布式系统的代码要假设"世界随时在变，而且你不知道变成什么样"。
这个差距，就是分布式系统复杂度的来源。