Hadoop——HDFS读写流程
HDFS写流程（也就是client上传文件到HDFS的流程）：
- Client和NN连接创建文件元数据
- NN判定元数据是否有效，比如判定client有没有权限创建文件，当前HDFS里有没有相同的同级同名文件
- NN触发副本放置策略，返回一个有序的DN列表
- Client和DN建立Pipeline连接（为降低带宽消耗和上传延时，client会根据距离，挑选一个与自己最近的DN建立连接）
- Client将block以更小的packet（64KB）的形式发送，并使用更小的数据chunk（512B）+ chucksum（校验和，4B）（每一个chuck对应一个chucksum）填充这个packet，每填充满一个packet，就发送这个packet
- Client将packet放入发送队列dataqueue中，并向第一个DN发送
- 第一个DN收到packet后本地保存并发送给第二个DN
- 第二个DN收到packet后本地保存并发送给第三个DN，这一个过程中，上游节点同时发送下一个packet，也就是第一个DN给第二个DN发送packet时，client可以同时并行地给第一个DN发第二个packet。这种形式就是流水线的形式，并且各个DN的传输过程是并行的。
- Hdfs使用这种传输方式，副本数对于client是透明的，也就是client并不需要管要发多少副本，只需要给跟它连接的那个DN发送就行
- 当block传输完成，DN们各自向NN汇报block状态，汇报的同时client也还在传输下一个block
所以，client的传输和block的汇报也是并行的
注意：1.client只和第一个DN连接，并不和其他DN连接，所以整个传输的形式是pipeline的而不是client与所有DN分发式的连接。2.所有连接都是TCP连接。3.可能会有DN宕机的现象，如果是最后一个DN宕机影响不大，如果是第一个DN宕机，则client会立刻跟第二个DN建立连接，如果是第二个DN宕机，第一个DN会立刻跟第三个DN建立连接。在这个过程中因为宕机会出现副本数目不足的情况，所以在最后DN跟NN汇报block状态时，NN会通知某一个不太忙的DN在本机再复制一个副本，保证副本数目的可靠性。
HDFS读流程（也就是client从HDFS下载文件的流程）
- 为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。
- 如果在读取程序的同一个机架上有一个副本，那么就读取该副本。
- 如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本。
- Client和NN交互文件元数据获取fileBlockLocation
- NN会按距离策略排序返回给client
- Client尝试下载block并校验数据完整性
重点：下载一个文件其实是获取文件的所有的block元数据。由此引发一个思考：既然有了所有block的location信息，那么获取某些block而不获取整个文件也是可以成立的。
HDFS支持client给出文件的offset，自定义连接想要获取的那个block的DN，自定义获取数据。（联想Java的randomAccess，client并不需要从头开始读一个文件，而是可以任意读取文件的任何block）
这个正是HDFS支持计算层的分治、并行计算的核心，client可以对任意位置的block进行计算，也正是为什么Hadoop要自己写一个文件系统的本质核心原因。