写路径：客户端只发一遍，流水线接力，ack 反向回

动机：三个互相打架的要求。 写要满足单写者（见 writer-lease），要落到 3 个副本上，而 NameNode 又不搬数据。所以 3 份不能由 NameNode 去分发，客户端也不能把同一份数据发 3 遍——那样带宽和时间都浪费 3 倍。

答案是流水线。 客户端只发一遍，节点接力往下传。

步骤。 第一，客户端申请建文件、拿 lease（见 writer-lease）。第二，向 NameNode 要第一块的 3 个节点，机架感知地挑：第一个尽量近写者，第二个放另一机架，第三个放和第二个同机架、不同节点。第三，客户端把数据切成 64KB 包，只发给流水线首节点；首节点落盘并转发给第二，第二落盘转发给第三。第四，ack 反向回：第三 ack 给第二，第二 ack 给第一，第一 ack 给客户端。客户端收到这条链的 ack，才算该包在 3 个副本上写稳。第五，块满 128MB，客户端再问 NameNode 要下一块，重排流水线，继续写。写完，客户端把最后没满的包刷出去、等 ack 齐了，告诉 NameNode 写完了，NameNode 记下最终长度、释放 lease。

出问题怎么办。 中途节点死了，流水线就断了：NameNode 把它从流水线里踢掉，客户端用剩下的节点加一个新节点重建流水线。已 ack 的包不用重写，只重发还没 ack 的包。对写者来说，只是卡一下，不是整个文件重写。

一条硬规矩。 HDFS 文件是一次写、多次读：写完不能在中间随机改，只能追加。这就是 lease 与流水线成立的前提，多个写者随机改写在这个模型里根本管不住。

复盘：流水线省的是什么。 省的第一是客户端带宽：只发一遍，而不是三遍，客户端的出口不会成为瓶颈。省的第二是 NameNode 的事：它只发地址和命令，不参与搬运，所以数据量涨多少都不会先压垮它。代价是确认要走整条链：最慢的那一跳决定了包什么时候算写稳，这正是写 lease 节点里说的背压的来源。机架感知的选址同样是在省：第一副本近写者省网络，第二副本跨机架防机架级故障，第三副本与第二同机架则是在容灾和带宽之间取了个中间点。