轉自：http://coderplay.iteye.com/blog/1067463
在分析HDFS的一致性之前, 我們先得解決HDFS客戶端行爲的幾個問題。
1. 爲什麼HDFS不支持多個writer同時寫一個文件,即不支持併發寫?
首先談一談HDFS產生的歷史。HDFS是根據Google的GFS論文所實現的, 初期時它的主要設計目標是爲了存儲MapReduce所操作的大型數據集。我們知道在Hadoop中, 每道Mapreduce作業的寫操作一般發生在reduce階段(如果是隻含map的作業,則在map階段)。一般情況下,
各個reducer的結果將分別寫入一個HDFS文件當中。此處可能會產生一個疑問: 爲什麼不是所有reducer的結果寫入同一個HDFS文件呢? 顯然, 多個reducer對同一文件執行寫操作,即多個writer同時向HDFS的同一文件執行寫操作, 這需要昂貴的同步機制不說, 最重要的是這種做法將各reducer的寫操作順序化, 不利於各reduce任務的並行。 因此, HDFS沒有必要支持多個writer, 單個writer就可以滿足Hadoop的需要。
2. 爲什麼HDFS在後期加上了對文件追加(append)操作的支持?
我們知道HDFS在0.19.0版以前是不支持文件追加操作的。HDFS設計文檔上寫着: HDFS的應用程序需要對文件實行一次性寫,多次讀的訪問模式。文件一旦建立,然後寫入,關閉, 不需要再更改。這樣的假定簡化了數據一致性問題並使高數據吞吐量成爲可能。MapReduce程序或者網絡爬蟲程序就很適合使用這樣的模型。當然未來計劃支持增量寫。
https://issues.apache.org/jira/browse/HADOOP-1700
http://lucene.472066.n3.nabble.com/HDFS-appending-writes-status-td648274.html#a648274
3. 爲什麼追加操作也只能是單個writer?
社區有人希望HDFS能實現原子追加操作, 因爲GFS實現了原子追加。但Owen O'malley認爲原子追加對於文件系統的設計和文件系統的用戶接口來說,都不是件好事。而且, 他們(指Google)在MapReduce之前就已經給GFS加上了原子追加操作。編寫MapReduce可以比使用原子追加更好地服務於大多數應用程序。Owen
O'malley原文:"My personal inclination is that atomic append does very bad things to both the design of the file system and the user interface to the file system. Clearly they added atomic append to GFS before they had MapReduce. It seems like most applications
would be better served by implementing in MapReduce rather than using atomic append anyways..."
以下是對Google工程師關於GFS2.0設計的一段採訪問內容
http://queue.acm.org/detail.cfm?id=1594206
QUINLAN At the time, [RecordAppend] must have seemed like a good idea, but in retrospect I think the consensus is that it proved to be more painful
than it was worth. It just doesn't meet the expectations people have of a file system, so they end up getting surprised. Then they had to figure out work-arounds.
那時候,記錄追加看上去像是一個不錯的主意, 但是回顧以往,我們達成這樣的一致: 事實證明它帶來的痛苦比帶來的好處多。它不符合文件系統用戶的期望,所以
MCKUSICK In retrospect, how would you handle this differently?
QUINLAN I think it makes more sense to have a single writer per file.
MCKUSICK All right, but what happens when you have multiple people wanting to append to a log?
好的, 那多個用戶需要追加一個日誌怎麼辦?
QUINLAN You serialize the writes through a single process that can ensure the replicas are consistent.
你序列化寫操作至單個進程,此進程可以確保副本是保持一致的。
4. 像HDFS這種應用,在一致性上要保證的是什麼?
HDFS作爲一個文件系統,應當保證文件內容的順序性.
HDFS加上追加操作會給一致性帶來哪些挑戰?
在特定時間裏,文件最末塊的各副本可能會有不同的字節數。HDFS要提供什麼樣的讀一致，以及怎麼保證一致性,即使碰到故障。
HDFS的一致性基礎
當客戶端讀取某DataNode上的副本時，此DataNode並不會讓其所有接收到的字節對客戶端可見。
每個RBW副本維持兩個計數器：
1. BA: 下游DataNode已經應答的字節數。即DataNode使其對任何reader可見的那些字節。以下，我們可以用副本的可見長度代指它。
2. BR: 爲此塊接收到的字節數，包括已經寫入至塊文件的字節以及緩存在DataNode的字節。
假設初始時管線內所有DataNode有(BA, BR) = (a, a)。則客戶端向管線推入一個b字節的包並且在客戶端沒收到此包的應答之前不向管線推入其它包，有：
1. 完成1.a後, DataNode將其(BA, BR)變爲(a, a+b)
2. 完成3.a後, DataNode將其(BA, BR)變爲(a+b, a+b).
3. 當代表操作成功的應答發回客戶端時，管線上的所有DataNode都有(BA, BR) = (a+b, a+b).
一條具有N個DataNode管線，DN0, …, DNi, …,DNN-1。其中DN0代表管線上的第一個DataNode，即最接近writer的那個DataNode，它在任意指定時間t都有如下屬性：
HDFS提供怎麼樣的寫一致性?
HDFS提供怎麼樣的讀一致性?
