HDFS中的Append/Hflush/Read轨范文档（HDFS-265：Revisit append / Append&Hflush&Rea

HDFS中的Append/Hflush/Read规范文档（HDFS-265：Revisit append / Append&Hflush&Read Specification）
转帖请注明来自本空间地址：http://blog.csdn.net/chenpingbuptchenpingbupt@gmail.com原文请参：https://issues.apache.org/jira/secure/attachment/12406399/AppendSpec.pdfhttps://issues.apache.org/jira/browse/HDFS-265译文如下：本文中将fsync重新定义为hflush，因为从语义上说，fsync这个操作确实是将数据从从buffer中flush出去但是没有sync到磁盘中。fysnc操作可能会在后续中添加Read/write semantics w/o append/hflush

DFS为未关闭的文件的数据提供最大努力的持久性
NN持久化文件meta信息，但是不持久block的归属信息，重启NN可能导致数据丢失DFS不会主动管理blk的replica数目，如果一个block没有replica可以被写，那么写会失败
DFS为已关闭文件的数据提供强持久性
NN持久化文件和它的blk元信息，重启NN不会导致数据丢失DFS主动管理每个block的备份数然而文件关闭并不会保证数据sync到磁盘中，如果数据没有到磁盘那么重启DN将导致数据丢失。
Read
如果文件是未关闭，那么只有Complete的block数据能够被reader读取，bbw中的数据是不可见的

一次只有一个write/appender，也就是说client只能在一个已经closed文件进行appendDFS为closed后又打开进行append的数据持久化提供强保障，为新append进来的数据提供最大努力

hflush保证所有经过flush的数据都能够被reader看见。但是hflush不保证数据持久到磁盘中，所以重启DN可能会导致数据丢失DFS为hflush过的数据提供弱的持久化保证。NN会持久化经过hflush的blk的元数据，所以重启NN不会导致hflush过的数据丢失DFS不会主动管理每个blk的备份数是否满足要求在0.20之前，DFS为append之前的数据也仅提供弱的持久性保证。

多个reader可以并发读取一个未关闭文件Hflush的数据可以被一个新reader（flush过后，打开文件的）所读取如果writer/appender不调用hflush，reader仍然可以渐渐的看到之前写入的数据如果一个reader看到了某个数据，那么除非所有的replica失效了，否则这个reader可以一直看到这个数据，这包含：
如果在某个replica看到一个数据，那么在别的replica也应该可以看到这个数据这个数据可以是hflush过的，也可以是没有hflush过的