分布式檔案系統應用（上篇 理論）

自從6月份出山以來 就一直琢磨着搞一套通用的服務化平台。在設計使用者行為分析以及使用者推廣的時候,發現自己的構架裡對海量檔案的存儲沒有一個合理的方案。起初打算用windows2003中dfs系統開發一套新的檔案系統，後來發現win下的dfs是個大坑，未遂。然後考慮到win平台與linux系統之間關于檔案處理的優劣與穩定性，最終選擇linux下fastdfs。

下面先簡單介紹下分布式檔案系統然後結合我的實際case給大家圖文示範，在這之前先感謝下fishman、咕咚、以及菲雪同學的大力支援。你們是最棒的！！

Tracker Server：跟蹤伺服器，主要做排程工作，在通路上起負載均衡的作用。在記憶體中記錄叢集中group和storage server的狀态資訊，是連接配接Client和Storage server的樞紐。

Storage Server：存儲伺服器，檔案和檔案屬性（meta data）都儲存到存儲伺服器上

架構解讀：

隻有兩個角色，tracker server和storage server，不需要存儲檔案索引資訊

所有伺服器都是對等的，不存在Master-Slave關系

存儲伺服器采用分組方式，同組記憶體儲伺服器上的檔案完全相同（RAID 1）

不同組的storage server之間不會互相通信

由storage server主動向tracker server報告狀态資訊，tracker server之間通常不會互相通信

上傳檔案流程圖：

1.client詢問tracker上傳到的storage；

2.tracker傳回一台可用的storage；

3.client直接和storage通信完成檔案上傳，storage傳回檔案ID

下載下傳檔案流程圖：

1. client詢問tracker可以下載下傳指定檔案的storage，參數為檔案ID（組名和檔案名）；

2. tracker傳回一台可用的storage；

3. client直接和storage通信完成檔案下載下傳。

同步機制：

采用binlog檔案記錄檔案上傳、删除等操作，根據binlog進行檔案同步

binlog中隻記錄檔案名，不記錄檔案内容

記錄已同步的位置到.mark檔案中

同組内的storage server之間是對等的，檔案上傳、删除等操作可以在任意一台storage server上進行

檔案同步隻在同組内的storage server之間進行，采用push方式，即源頭伺服器同步給目标伺服器

同步延遲問題：

storage生成的檔案名中，包含源頭storage IP位址和檔案建立時間戳

源頭storage定時向tracker報告同步情況，包括向目标伺服器同步到的檔案時間戳

tracker收到storage的同步報告後，找出該組内每台storage被同步到的時間戳（取最小值），作為storage屬性儲存到記憶體中

通信協定：

二進制通信協定 

協定包由兩部分組成：header和body

 header共10位元組，格式如下：

  8 bytes body length

  1 byte command

  1 byte status

 body資料包格式由取決于具體的指令，  body可以為空

IO模型：

本文轉自 熬夜的蟲子  51CTO部落格，原文連結:http://blog.51cto.com/dubing/712425