本系列主要是使用Java RMI 實現一個簡單的GFS（谷歌文件系統，google file system），這里介紹GFS背景以及系統的設計相關。
[為了更好的閱讀以及查看其他篇章，請查看原文：https://www.cnblogs.com/maogen/p/gfs_1.html]
🧨 🏮 🧧 🏮
ʰᵅᵖᵖʸ ⁿeᵚ ʸᵉᵅʳ家人閑坐 燈火可親
辭舊迎新 新年可期
系統整體介紹、系統實現、演示視頻以及源代碼：
介紹篇：https://www.cnblogs.com/maogen/p/gfs_0.html
演示與實現篇：https://www.cnblogs.com/maogen/p/gfs_2.html
作者：晨星1032-博客園：https://www.cnblogs.com/maogen/
背景
隨着當代社會信息化程度的持續提升，所產生的數據呈現爆炸式增長趨勢。與此同時，數據對於我們也越來越重要。在這種情況下，如何存儲海量的數據，如何對服務器集群上的海量數據進行有效的管理，如何降低存儲成本，以及如何使存儲海量數據的服務器集群對外提供高效服務並且保證服務不中斷，都是我們必須面對的問題。
分布式文件系統(Distributed File System，DFS)將會很好的解決上述問題。如上圖所示，分布式文件系統采用可擴展的系統結構，可以實現冗余存儲、文件同步，系統容錯、故障恢復等原本需要人工手動才能實現的功能，大大降低維護難度，它不但提高了系統的可靠性、可用性和存取效率，還易於擴展，可以讓我們有效存儲並管理利用海量數據。
GFS(Google File System)是Google公司為了存儲海量搜索數據而設計的專用文件系統。GFS作為一個可擴展的分布式文件系統，用於大型的、分布式的、對大量數據進行訪問的應用。它運行於廉價的普通硬件上，並提供容錯功能，可以根據系統的需要向其中添加任意數目的廉價商用計算機用於滿足數據存儲的需要，實現了減少運營成本的同時能夠對外提供優良的服務。
GFS的系統架構如上圖所示，它包含總控服務器，數據服務器以及客戶端。GFS將文件分割成為若干個大小固定（64MB）的數據塊，同時總控服務器會為這些數據塊創建一個唯一標識。同一文件的所有數據塊會分布於系統中的不同節點之上，為了保證數據的可靠以及可用，通過復制實現系統中包含同一數據塊的多個副本，通常情況下為三個副本。
系統設計
1. 系統功能
如圖所示為MyGFS系統各功能模塊划分的分解圖。系統共有三個核心組件：Master、ChunkServer和Client。Master存儲整個文佳系統的目錄結構和文件元數據，並對文件元數據管理；ChunkServer為存儲具體文件數據的服務器，對數據進行管理；Client是使用GFS功能的客戶端。
2. Master組件
2.1 命名空間
Master命名空間包含：
- 整個文件系統的目錄結構和Chunk的基本信息；
- 文件與Chunk的映射關系；
- 各個Chunk備份（Replicas）的位置信息，默認為3個副本。
2.2 心跳機制
心跳機制是讓Master服務器了解到Chunk服務器的狀態，檢測Chunk服務器是否在線以及獲取相關信息。
如圖所示，實現心跳機制可有兩種方式。方式①是Chunk服務器間隔時間向Master服務器匯報自己在線以及自身信息，若在一定時間內，Master服務器一直未收到Chunk服務器傳來的信息，則認為Chunk服務器掉線並進行后續步驟執行；方式②是Master服務器主動向Chunk服務器發送消息，Chunk服務器收到后將自身信息反饋給Master服務器，若一定時間內Master服務器一直未收到Chunk服務器傳來的信息，則認為Chunk服務器掉線並進行后續步驟執行。
本系統將使用Java RMI的lookup相關函數進行方式②檢測。
2.3 故障恢復和容錯機制
GFS系統是構建在普通的、廉價的機器上，因此故障是常態而不是意外。對發生的故障及時恢復，不能影響操作。
如圖為故障恢復流程，Master根據心跳機制檢測ChunkServer是否掉線，若掉線則需要分配新的服務器負載均衡，並將取出該ChunkServer上對應的Chunk文件，對其進行復制；若在線則繼續將該ChunkServer上的Chunk文件的Hash值對比，檢測是否數據是否一致，若不一致則使用該Chunk文件的副本對其進行替換；若一致，則檢測結束。
3. ChunkServer組件
3.1 本地存儲
ChunkServer中存儲Chunk的具體文件內容。GFS將每個Chunk限制為64Mb, Chunk內部又分為眾多的Block。
3.2 內存命中機制
GFS系統是一次寫入多次讀取，對於讀操作較多，采用內存命中，將一定大小的文件放至內存使得讀取速度更快。
如圖所示為內存命中機制示意圖，Mem工作原理要求它盡量保存最新數據，當從Disk向Mem傳送一個新塊，若Mem中可用位置已被占滿時，則采用最近優先策略進行替換。
3.3 狀態維護
如圖所示，ChunkServer內存上包含Chunk文件的ID和其Hash值，通過一個Thread間隔時間檢測本地Chunk文件將Map更新為實際Hash值，並可以將Hash值發送給Master，由Master進行對比處理。
3.4 副本管理
為保證GFS系統的數據可靠性，系統對於Chunk文件進行主副本（primary-secondary）管理。ChunkServer上的Primary負責對其Secondary進行數據操作管理，保證數據一致性。
4. Client組件
4.1 上傳
客戶端上傳功能是整個GFS系統寫模型的體現。
如圖所示，寫模型是將數據流和控制消息分開，本文采用主從推送方式（非鏈式推送）。Client向Master請求Chunk的副本信息和Primary Replica信息；Master回復Client相關信息；Client將數據首先推送到Primary，再由Primary推送到所有的Secondary；若全部推送成功則Primary副本所在的ChunkServer會采用回調的方式更新Master節點，Master再通知Client是否成功。
4.2 下載
客戶端下載功能是GFS系統讀模型的體現。
如圖所示，讀模型也是將數據流與控制消息分開。Client將需讀取的文件名發送給Master，Master響應Chunk文件所在ChunkServer的相關信息；Client再去請求該ChunkServer的Chunk，獲取Chunk文件流下載到本地。
4.3 追加
GFS系統文件修改僅支持Append追加方式。
如上兩圖所示，GFS系統追加信息，Client首先請求Master該文件的最后一個Chunk的信息以及所在的ChunkServer位置；然后Client將追加數據流發送給ChunkServer；若追加內容大小與該最后一個Chunk剩余空間小時，可直接在后追加內容，若大於剩余空間時，將最后一個Chunk空間填滿，並新建新Chunk繼續上述操作判斷直至追加內容全部添加進去；最后修改成功后向Master通知，確保數據一致性。
4.4 刪除
客戶端刪除相關文件時，首先將需刪除的文件名發送給Master，Master會先刪除命名空間里關於該文件的信息，再通知ChunkServer進行刪除本地信息。
4.5 文件列表
客戶端展示文件列表，是向Master請求GFS系統內的所有文件列表，Master響應后Client端進行展示給用戶。
系統整體介紹、系統實現、演示視頻以及源代碼，盡在其他篇章：
介紹篇：https://www.cnblogs.com/maogen/p/gfs_0.html
演示與實現篇：https://www.cnblogs.com/maogen/p/gfs_2.html
作者：晨星1032-博客園：https://www.cnblogs.com/maogen/