1. 关闭管线。

2. 将已经发送到管道中，但是还没有确认的数据重新写回到缓冲区，保证数据不会丢失。

3. 所有的namenode重新分配一个版本号

4. 重新选举一个主datanode

5. 计算所有datanode中最小的数据块，重新分配

6. 重建管线，重新写入

7. 宕掉的datanode恢复后由于版本号不同会被剔除掉。

8. 写完文件，namenode发现副本数量不够，会在其他数据节点上再创建一个新的副本。

第一次请求会获取到该文件所有block所有的datanode信息。   获取文件完成之后，向namenode反馈block的状态

对，分块结束后是一个块一个块的上传。一个文件只要上传成功一个块就可以了，副本集群会自动备份的。

如果还有数据块4,里面还会存文件1和2嘛？

这个是因为讲师说了数据块要备份成3份，所有在图例中的情况下，如果还有数据块4的话，不会保存文件1和2了。

因为namenode需要及时更新存储信息，方便记录存储各个datanode存储大小信息

看你集群的大小和备份的数量设置了。 如果你集群有100台  备份数量是3  肯定不会备份到所有的 datanode节点啊。  注意 这里是datanode。  datanode存储数据。

先向namenode发起请求获取该文件所在的datanode的列表，然后通过该列表向各个datanode读取数据

这里是两个例子，分别是写流程和读流程。读流程这里因为篇幅原因没有画更多的节点。这里想表达的意思是同一个文件不同的数据块可能分布在不同的节点之上。client根据客户端提供的数据块的地址找对应的datanode去读取！这里我当时描述的可能不太清楚。

1. 服务器分布在不同的机架（双电源），为了防止某条线路断电导致服务器失效（也解决了部分网络机架网络出问题的情况）

2. 备份的过程（默认3份） 首先，如果client是集群内的节点则将第一份存储在client上否则随机存储到其他节点，第二份节点存储到其他机架节点，第三份存储到本机架节点。（注此处需开启hadoop的机架感知属性，默认是关闭的，如果未开启机架感知 则认为 随机放到了三个节点上，防止某些节点出问题造成数据丢失）

3. 通过zookeeper实现的namenode主备切换，防止因为namenode失效造成的数据无法访问

4. 正常业务集群肯定要部署集群相关的状态监控，出现问题可以及时发现

   如果             这个时候，你的集群还是全部挂掉了。              此乃天灾。。。你需要考虑的不是数据的可用性了，而是千万不要丢失数据！

 在向HDFS的写操作中，不得不提一下“数据流管道”。数据流管道在Google实现他们的分布式文件系统(GFS)时就已引入，其目的是：在写一份数据的多个副本时，可以充分利用集群中每一台机器的带宽，避免网络瓶颈和高延时的连接，最小化推送所有数据的延时。  其实这里我可能表述的不太准确，Client在保存数据的过程当中，将数据发送到第一个数据节点DateNode 1，然后在第一个DateNode节点在本地保存数据的同时，将数据推送到第二个数据节点DateNode 2，同理在第二个节点本地保存数据的同时，也会由第二个数据节点将数据同送给第三个数据节点DateNode 3。  这样啊，每个节点都能承担写数据时的部分网络流量，降低了客户端发送多分数据时对网络的冲击