该系列总览: Hadoop3.1.1架构体系——设计原理阐述与Client源码图文详解 : 总览
紧接着上一篇文章: Hadoop3.1.1源码Client详解 : Packet入队后消息系统运作之DataStreamer(Packet发送) : 主干
接着我们要介绍第二种情况的流水线架设。也就是流水线恢复。也即下图蓝框部分。
关于这个方法：
这个方法只是检查了一下流水线上是否有节点，而后直接调用橙色部分的方法。橙色部分的方法接收的参数是关于流水线上DataNode的内容
首先要做的是处理掉在流水线上但不能工作的DataNode。
要处理两类DataNode
1.正在重启的DataNode
2.无法正常工作的DataNode
最后要把无法工作的DataNode替换成能工作的DataNode。
1.处理正在重启的DataNode：
判断一个DataNode是否值得等待重启：如果他是流水线上唯一节点或者是和客户端同一主机的节点，那么就值得等待。因为流水线只有一个节点，不等他等谁...只有他能工作。如果是本地节点，那么重启恢复到和客户端通信的速度会比较快。右图（左图方法的下半部分）只有一个sleep，怎么保证一直睡眠呢？上图红框上面有while循环。
2.处理无法正常工作的节点BadNode：
其实做的最主要的事是移除坏（无法正常工作）的节点。
3.替换节点（实际是增加能工作的节点），其实关于新版的客户端设计我是有疑虑的。因为Append和Recovery设置流水线用的都是同一个方法，也就是
结合这一步，就是说，即使没有BadNode，Append操作也需要在流水线上找多一个节点。如果找不到就报错。
关于satisfy:
在dfs.client.block.write.replace-datanode-on-failure.policy不设置的情况下，如果是append文件，总是会满足这个函数
如果设置为NEVER,则返回false
所以Append文件总是会为流水线寻找新节点，而且找不到还会报错...
看一下是怎么添加DataNode的，首先看一下官方注解，如果当前流水线失败正在恢复，需要添加一个新的DataNode，要知道，这个新的DataNode里可没有当前正在写入数据的Block的Replica，因为他是新加入的。所以需要找一个流水线上的DataNode，把Replica复制给新DataNode，但是还是要根据之前的错误发生在哪来决定复制还是不复制。
对于情况2:
对于情况5
向下看:
对不能正常工作的DataNode的处理完毕。接着之前的setupPipelineInternal讲下去。
updateBlockForPipeline会向NameNode申请更新Block的BGS和AccessToken，更新之后的信息返回，但不会在NameNode那边更新Block。
到了下面的updatePipeline才会告诉NameNode去更新，因为此时流水线架设成功。
流水线的架设终于介绍完了