HDFS中的Append/Hflush/Read规范文档（HDFS-265：Revisit append / Append&Hflush&Read Specification）

转帖请注明来自本空间地址：

http://blog.csdn.net/chenpingbupt

chenpingbupt@gmail.com

原文请参：

https://issues.apache.org/jira/secure/attachment/12406399/AppendSpec.pdf

https://issues.apache.org/jira/browse/HDFS-265

译文如下：

本文中将fsync重新定义为hflush，因为从语义上说，fsync这个操作确实是将数据从从buffer中flush出去但是没有sync到磁盘中。fysnc操作可能会在后续中添加

Read/write semantics w/o append/hflush

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

Append

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

Hflush

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

Read

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