上周Facebook決定共享其分布式日志管理系統(tǒng)，這可能是由于管理大量日志的系統(tǒng)管理員想要一個新的“朋友”了。其中最讓人印象深刻的是這樣的操作:Facebook聲稱，在失敗后，LogDevice可以重建日志，以“每秒5 Gbps到10 Gbps之間的速度完全恢復(fù)受影響的所有記錄的復(fù)制因子”。

正如《華盛頓郵報》解釋的那樣，日志記錄顯示了在無限制規(guī)模下兩個難以兌現(xiàn)的問題:記錄存儲高度可用且持久，同時保持“這些記錄上的可重復(fù)的全部順序”。

實現(xiàn)這一目標所需的規(guī)范如下:

·LogDevice是記錄導(dǎo)向的，而不是字節(jié)，寫在日志上的最小的不可分割的單元是一個完整的記錄，該公司說它提供了“在出現(xiàn)問題時更好的寫入可用性”;

·日志是附加的，日志記錄不能被修改;

·為了管理日志大小，文件可以根據(jù)基于時間的或基于空間的保留策略來調(diào)整進行修改，然后丟掉最舊的記錄。

要獲得Facebook所需的規(guī)模，關(guān)鍵是將日志序列與記錄本身分離開來：測序器作為一個單獨的進程運行，無論是在存儲節(jié)點上還是在其自身的節(jié)點上。

這些序號本身并不是整數(shù)，而是整數(shù)對。“紀元存儲區(qū)”是一個持久計數(shù)器的存儲庫，每個日志一個，很少遞增，而且保證不會倒退。而在今天，我們使用Apache Zookeeper作為LogDevice的紀元存儲區(qū)。

Facebook的LogDevice

▲LogDevice將排序與對象存儲分開

對于日志對象存儲，LogDevice將一個記錄隨機地分配給一個存儲節(jié)點。那么，假如您沒有將某個特定服務(wù)器上的所有日志登陸到同一磁盤上，而且萬一失敗，您也不會丟失全部日志。

這就是快速重建很重要的地方:如果一個記錄正在等待被恢復(fù)，當?shù)诙问“l(fā)生時怎么辦?沒錯，重建的目的就在于此了。

所有的集中化日志自然都來自于本地日志，因此，LogDevice引入了一個名為LogDB的寫優(yōu)化存儲，它是一種針對寫入優(yōu)化的數(shù)據(jù)存儲區(qū)。它的“設(shè)計目的是保持磁盤的數(shù)量小且可控，而且存儲設(shè)備上的寫和讀取IO模式大多是連續(xù)的”。

Facebook表示，希望今年能實現(xiàn)其最終目標：開源的LogDevice。