1、故事的起源

還是很多很多年前，做過一個小系統，是一個和支付相關的小系統。因為是一個小系統，所以一切都那么簡單。一臺應用服務器，一臺數據庫服務器；文件、圖片都放在應用服務器上，一切都是那么的平淡，一切都是那么的理所當然。

突然有一天，支付成為一個時髦的話題；突然有一天，這個平臺居然要孕育成為一個新的支付公司的核心系統；于是，系統的訪問就要暴漲了。這一切都很突然……

2、調整后的系統簡易架構

前端使用負載均衡設備統一進行調度，中端對應于服務器進行橫向擴展，后端把數據庫升級。后端文件存儲用了多層NFS架構，但是還是不夠，分布式文件系統成為了必然的選擇。采用分布式文件系統后，服務器之間的數據訪問不再是一對多的關系，而是多對多的關系，這樣一來，性能大幅提升毫無問題。

3、分布式文件系統介紹

使用分布式文件系統可以輕松定位和管理網絡中的共享資源、使用統一的命名路徑完成對所需資源院的訪問、提供可靠的負載平衡、與FRS（文件復制服務）聯合在多臺服務器之間提供冗余、與系統權限集成以保證安全。

在分布式環境中，有太多的意外，數據隨時傳輸錯誤，服務器時刻準備犧牲，很多平常稱為異常的現象，在這里都需要按照平常事來對待。因此，對于分布式文件系統而言，僅僅是滿足了正常狀況下文件系統各項服務還不夠，還需要保證分布式各種意外場景下健康持續的服務，否則，將一無是處。

1、服務器的錯誤恢復

在分布式環境中，哪臺服務器犧牲都是常見的事情，犧牲不可怕，可怕的是你都沒有時刻準備好它們會犧牲。作為一個合格的分布式系統，應用服務器當然時刻準備好了前赴后繼奮勇向前。每一臺應用服務器出錯了，都要有相應的應急策略和處理方法；

客戶端

在分布式文件系統中，最不重要的應用服務器，應該就是客戶端了。畢竟，做為一個文件系統的使用者，在整個文件系統中的地位，難免不高。而作為客戶端，大部分時候，犧牲了就犧牲了，沒人哀悼，無人同情，只有在在辛勤寫入的時候，不幸辭世（機器掛了，或者網絡斷了，諸如此類...），才會引起些恐慌。因為，此時此刻，在主控服務器上對應的文件，正作為可能被構造的節點活著，僅僅為占有它的那個客戶端服務者，做為一個專一的文件，它不允許別的客戶端染指。這樣的話，一旦占有它的客戶端服務者犧牲了，此客戶端會依然占著資源不釋放。這種事情，必須要有辦法解決這個問題，這就是：租約。。。

租約，顧名思義，就是當客戶端需要占用某文件的時候，與主控服務器簽訂的一個短期合同。這個合同有一個期限，在這個期限內，客戶端可以延長合同期限，一旦超過期限，主控服務器會強行終止此租約，將這個文件的享用權，分配給他人。。。

在打開或創建一個文件，準備追加寫之前，與主控服務器在指定的路徑下與此客戶端簽訂一份租約。客戶端會定時輪詢續簽租約。在主控服務器一端，始終在輪詢檢查所有租約，查看是否有到期未續的租約。如果一切正常，該客戶端完成寫操作，會關閉文件，停止租約，一旦有所意外，比如文件被刪除了，客戶端犧牲了，主控服務器都會剝奪此租約，如此，來避免由于客戶端停機帶來的資源被長期霸占的問題。。。

文件服務器

海量的文件服務器是一個更不穩定的因素。一旦某文件服務器掛掉，并且主控服務器還不知道，主控服務器就會變相的欺騙客戶端，給它們無法連接的讀寫服務器列表，導致它們處處碰壁無法工作。因此，為了整個系統的穩定，數據服務器必須時刻向主控服務器匯報，保持主控服務器對其的完全了解，這個機制就是心跳消息。文件服務器必須要不斷向主控服務器匯報自身的狀況。比如：有多少可用空間、用了多大的空間，等等之類。主控服務器會將文件服務器匯報的狀況，作為新的數據塊分配或是負載均衡的依據。

主控服務器

主控服務器是整個分布式文件系統的核心，作為整個系統的核心和單點，主控服務器一旦當機，整個分布式文件服務集群將徹底癱瘓罷工。如何在主控服務器犧牲后，提拔新的主控服務器并迅速使其進入工作角色，就成了系統必須考慮的問題。解決策略是事物日志。

熟悉數據庫的同學一看就知道是從數據庫那里山寨來的。在主控服務器上，所有對文件目錄操作的關鍵步驟（具體文件內容所處的數據服務器，是不會被寫入日志的，因為這些內容是動態建立的...），都會被寫入日志。另外，主控服務器會在某些時刻，將當下的文件目錄完整的序列化到本地，這稱為鏡像。一旦存有鏡像，鏡像前期所寫的日志和其他鏡像，都純屬冗余，其歷史使命已經完成，可以報廢刪除了。在主控服務器不幸犧牲，或者是戰略性的停機修整結束，并重新啟動后，主控服務器會根據最近的鏡像 + 鏡像之后的所有日志，重建整個文件目錄，迅速將服務能力恢復到犧牲前的水準。。。

2、數據的正確性保證

在復雜紛繁的分布式環境中，我們堅定的相信，萬事皆有可能。哪怕各個服務器都在認認真真工作，也可能有各種各樣的情況導致網絡傳輸中的數據丟失或者錯誤。并且在分布式文件系統中，同一份文件的數據，是存在大量冗余備份的，系統必須要維護所有的數據塊內容完全同步，否則，不同客戶端讀同一個文件讀出不同數據，用戶非得瘋了不可。

事實上，在沒有用分布式系統之前，我們的系統就出現過多次數據不一致的情況，嚴重的時候公司領導都親自關注，但是塵歸塵，土歸土，該怎樣還怎么樣，不從整體的視野上權衡，問題就不能徹底解決….

為了保證數據的正確性和同一份數據的一致性，分布式文件系統必須要做大量的工作。首先，每一個數據塊，都有一個版本標識，一旦數據塊上的數據有所變化，此版本號將向前增加。在主控服務器上，保存有此時每個數據塊的版本，一旦出現數據服務器上相關數據塊版本與其不一致，將會觸發相關的恢復流程。這樣的機制保證了各個數據服務器器上的數據塊，在基本大方向上都是一致的。但是，由于網絡的復雜性，簡單的版本信息無法保證具體內容的一致性（因為此版本信息與內容無關，可能會出現版本相同，但內容不同的狀況）。因此，為了保證數據內容上的一致，必須要依照內容，作出簽名。。。

當客戶端向數據服務器追加寫入數據包時，每一個數據包的數據，都會切分成段，作為簽名驗證的基本單位，當數據包傳輸到流水線的最后一級，數據服務器會對其進行驗證，一旦發現當前的傳輸塊簽名與在客戶端中的簽名不一致，整個數據包的寫入被視為無效，整個流程需要重來；

3、分布式文件系統的內部負載均衡

這里說的負載均衡，是寬泛意義上的均衡過程，主要涵蓋兩個階段的事務，一個是在任務初始分配的時候盡可能合理分配，另一個是在事后時刻監督及時調整

負載均衡，是分布式系統中一個永恒的話題，要讓大家各盡其力齊心干活，發揮各自獨特的優勢，不能忙得忙死閑得閑死，影響戰斗力。而且，負載均衡也是一個復雜的問題，什么是均衡，是一個很模糊的概念。比如，在分布式文件系統中，總共三百個數據塊，平均分配到十個數據服務器上，就算均衡了么？其實不一定，因為每一個數據塊需要若干個備份，各個備份的分布應該充分考慮到機架的位置，同一個機架的服務器間通信速度更快，而分布在不同機架讓安全性有了進一步提升；而分布在不同機房的服務器，安全性更加高，但是響應速度，更加難以控制。

4、垃圾回收

丟垃圾，丟是一件簡單的事情，但是什么東西能丟，不是一件容易的事情。我在家搞衛生的時候，總有很多的東西感覺從此以后不再使用，但是我和我媳婦（主控服務器）并不是每次都能達成一致，很多東西我想丟，我媳婦說要放一放，等幾天看看，很多的時候，幾天的幾天又過去了，也許就這樣放了幾年，只能等下次大掃除或者家里沒地方放東西了才行。

在分布式文件系統而言，沒有利用價值的數據塊備份，就是垃圾。基本上，所有的垃圾都可以視為兩類，一類是由系統正常邏輯產生的，比如某個文件被刪除了，所有相關的數據塊都淪為垃圾了，某個數據塊被負載均衡器移動了，原始數據塊也不幸成了垃圾了。此類垃圾最大的特點，就是主控服務器是生成垃圾的罪魁禍首，也就是說主控服務器完全了解有哪些垃圾需要處理。另外還有一類垃圾，是由于系統的一些異常癥狀產生的，比如某個文件服務器停機了一段，重啟之后發現其上的某個數據塊已經在其他服務器上重新增加了此數據塊的備份，它上面的那個備份過期了失去價值了，需要被當作垃圾來處理了。此類垃圾的特點恰恰相反，主控服務器無法直接了解到垃圾狀況，這個時候就需要一些額外的策略來進行處理，比如將出現故障的文件服務器的數據都作為垃圾進行處理，然后按照規則同步這臺文件服務器的全部數據。有可以先緩存起來，過幾天沒人想恢復它了再刪除。

4.、總結

整個分布式文件系統。三類服務器、作為單點存在的核心主控制服務器、基于日志的恢復機制、基于租約的保持聯系機制等等，在分布式計算系統和分布式數據庫中都可以看到類似的影子，分布式文件系統中最大特點，就是文件塊的冗余存儲，它直接導致了較為復雜的寫入流程。

       寫了這么多，看了這么多激動人心的概念，自己做一個分布式文件系統，是一個好主意，但是也是一個挑戰，如果不能下大決心和花費無數的銀子和時間，那么，就在諸多的分布式文件系統中，選擇一個吧。

來自：http://blog.csdn.net/ffm83/article/details/42671841