原文链接：https://www.infoq.cn/article/large-data-processing-ensuring-data-not-lost-when-power-off
在 Hadoop 2.0.2-alpha 之前，HDFS 在机器断电或意外崩溃的情况下，有可能出现正在写的数据丢失的问题。而最近刚发布的 CDH4 中 HDFS 在 Client 端提供了 hsync() 的方法调用 ( HDFS-744 )，从而保证在机器崩溃或意外断电的情况下，数据不会丢失。这篇文件将围绕这个新的接口对其实现细节进行简单的分析，从而希望找出一种合理使用 hsync() 的策略，避免重要数据丢失。
HDFS 中 sync()，hflush() 和 hsync() 的差别
在 hsync() 之前，HDFS 就已经提供了 sync() 和 hflush() 的调用，单从方法的名称上看，很难分辨这三个方法之间的区别。咱们先从这几个方法之间的差别介绍起。
在 HDFS 中，调用 hflush() 会将 Client 端 buffer 中的存放数据更新到 Datanode 端，直到收到所有 Datanode 的 ack 响应时结束调用。这样可保证在 hflush() 调用结束时，所有的 Client 端都可以读到一致的数据。HDFS 中的 sync() 本质也是调用 hflush()。
hsync() 则是除了确保会将 Client 端 buffer 中的存放数据更新到 Datanode 端外，还会确保 Datanode 端的数据更新到物理磁盘上，这样在 hsync() 调用结束后，即使 Datanode 所在的机器意外断电，数据并不会因此丢失。而 hflush() 在机器意外断电的情况下却有可能丢失数据，因为 Client 端传给 Datanode 的数据可能存在于 Datanode 的 cache 中，并未持久化到磁盘上。下图描述了从 Client 发起一次写请求后，在 HDFS 中的数据包传递的流程。
hsync() 的实现本质
hsync() 执行时，实际上会在对应 Datanode 的机器上产生一个 fsync 的系统调用，从而将内存中的相关文件的数据更新到磁盘。
Client 端执行 hsync 时，Datanode 端会识别到 Client 发送过来的数据包中的 syncBlock_ 字段为 true，从而判定需要将内存中的数据更新到磁盘。此时会在 BlockReceiver.java 的 flushOrSync() 中执行如下语句：
((FileOutputStream)cout).getChannel().force(true);
而 FileChannel 的 force(boolean metadata) 方法在 JDK 中，底层为于 FileDispatcherImpl.c 中调用 fsync 或 fdatasync。metadata 为 true 时执行 fsync，为 false 时执行 fdatasync。
Java_sun_nio_ch_FileDispatcherImpl_force0(JNIEnv *env, jobject this,
jobject fdo, jboolean md)
{
jint fd = fdval(env, fdo);
int result = 0;
if (md == JNI_FALSE) {
result = fdatasync(fd);
} else {
result = fsync(fd);
}
return handle(env, result, "Force failed");
}
当 Datanode 将数据持久化到磁盘上后，会发 ack 响应给 Client 端。当收到所有 Datanode 的 ack 响应时，hsync() 的调用结束。
值得注意的是，fsync 或 fdatasync 本身是一个非常耗时的调用，因为磁盘的读写速度远低于内存的读写速度。在不调用 fsync 或 fdatasync 的情况下，数据可能保存在各级 cache 中。
最开始笔者在测 hsync() 的读写性能时，发现不同机器上测试结果 hsync() 耗时差别巨大，有的集群平均调用耗时为 4ms，而有的集群平均调用耗时则需 25ms。后来在公司各位大神的点拨下才意识到是跟 Linux 文件系统的机制有关。在这种情况下，只有一探 Linux 相关部分的源码才能解开心中的疑惑，下面这节就将从更底层的角度来解析与 hsync() 密切相关的系统调用 fsync 及 fdatasync 方法。