读路径：问 NameNode 要地址，找 DataNode 拿数据

动机：客户端手里只有一个文件名。 文件被切成块、散在 DataNode 上，文件到块、块到机器的地图只在 NameNode 里。所以读的第一步永远是先问账本，再直接找存数据的机器，因为数据永远不经过 NameNode。

步骤。 第一，客户端（DFSClient）向 NameNode 申请打开文件。第二，NameNode 查权限，返回两样东西：文件的块列表（按顺序），以及每块副本所在的 DataNode 列表（按距离排过序：同机优先、同机架次之、更远的靠后）。第三，客户端直连最近的 DataNode 拿第一块，流式读回，一包一包验校验和。第四，按顺序读下一块，直到读完、关闭。

出问题怎么办。 某包校验失败，说明这个副本坏了：客户端立刻换下一副本重读，并把坏副本报给 NameNode，NameNode 之后把它从有效集合里剔掉、再补一个好副本。正在读的 DataNode 死了，换下一副本续读，不用从头来。某块的副本全试遍了还不行，客户端回头再问 NameNode，要一份新的位置清单。

留一句话。 问地址找 NameNode，拿数据找 DataNode。NameNode 只动嘴、不动手。

复盘：读路径为什么是这个形状。 读路径的每一步都可以从“地图和数据分开”这一个前提推出：地图只在 NameNode，所以第一步必须是问；数据在 DataNode，所以第二步必须是直连；副本有多个，所以第三步必须按距离排序、按顺序试；校验和必须每包都验，因为不验就不知道拿到的那份是不是坏的。按距离排序也不是小优化，而是读路径省带宽的主力：同机读不走网络，同机架读不跨机架交换机，跨机架只在不得已时发生。坏副本上报同样重要：客户端是第一个发现副本坏了的人，不报的话，下一个读者还会踩同一个坏副本，而 NameNode 永远不知道。最后，读失败回头再问 NameNode，而不是在原地死磕，同样是分工的体现：位置信息过期了，就回源头刷新，而不是让客户端自己猜。