编辑-TL；DR:
是否所有副本节点都必须存储一个文件(其所有块(，然后才能认为写入HDFS成功？如果是，复制因素是否会影响写入延迟？
原始问题：
在Hadoop 2中，我可以通过将dfs.replication属性设置为大于1的值来控制数据块副本的数量(在一些像EMR这样的hadoop分布中，默认值并不总是3(。
我的理解是，HDFS的行为是同步写入第一个副本，而其他副本是流水线式的，复制以异步方式进行。这是正确的吗？
如果上述情况属实，那么如果第一个节点向namenode发送ack，然后在能够完成异步复制之前被陨石击中，那么总是存在数据丢失的风险。
有没有一种方法可以保证在写入被认为成功之前，至少有X个节点写入块？这样做明智吗？我以为我可以通过使用dfs.namenode.replication.min属性来控制它，但我读到它只在"安全模式"下使用，因此在正常操作中没有帮助。
您在哪里发现复制不可靠？来自Cloudera博客：
在写入文件时，数据节点形成一个要写入的管道复制品按顺序排列。数据以数据包的形式通过管道发送(小于一个块(，每一个都必须被确认为成功的写作如果数据节点在块执行期间发生故障写入后，它将从管道中删除。当前块具有已写入，name节点将重新复制它以弥补由于数据节点出现故障而丢失复制副本。后续区块将使用具有所需数量的数据节点的新管道编写
如果复制的块失败，那么写入将失败，HDFS写入操作将返回错误。在成功写入所有副本之前，操作不会被视为完成：
以下是有关HDFS高可用性的具体细节。TL；DR在整个写入操作被认为完成之前，最后一个数据块将在所有复制副本中进行验证。仅仅"失败"也是不够的。取而代之的是自动故障转移，包括查找不同的数据节点并将故障块写入其中。
块复制副本失败的详细信息检测：
http://blog.cloudera.com/blog/2015/02/understanding-hdfs-recovery-processes-part-1/
如果正在写入的文件的最后一个块没有传播到所有管道中的DataNodes，然后写入的数据量当租约恢复发生时，不同的节点可能不同。之前租约恢复导致文件关闭，有必要确保最后一个块的所有副本具有相同的长度；这个过程称为块恢复。块恢复仅在租约恢复过程，并且租约恢复仅触发阻止如果文件的最后一个块未处于COMPLETE状态，则恢复该块状态(在后面的部分中定义(。
块故障的详细信息恢复：
在写管道操作期间，管道中的一些DataNode可能失败当这种情况发生时，底层写操作不能失败相反，HDFS将尝试从错误中恢复，以允许管道继续运行，客户端继续向文件从管道错误中恢复的机制称为管道恢复。
我已经经历了几十次数据节点/块写入失败。但我很少体验到成功的写作是"不真实的"。这些罕见的情况是由于物理磁盘损坏而导致的AFAICR。