一、分佈式文件系統fastDFS-設計原理
FastDFS是一個開源的輕量級分佈式文件系統，由跟蹤服務器（tracker server）、存儲服務器（storage server）和客戶端（client）三個部分組成，
主要解決了海量數據存儲問題，特別適合以中小文件（建議範圍：4KB< file_size <500MB）爲載體的在線服務。
1、Storage server
Storage server（後簡稱storage）以組（卷，group或volume）爲單位組織，一個group內包含多臺storage機器，數據互爲備份，存儲空間以group內容量最小的storage爲準，所以建議group內的多個storage儘量配置相同，以免造成存儲空間的浪費。
以group爲單位組織存儲能方便的進行應用隔離、負載均衡、副本數定製（group內storage server數量即爲該group的副本數），比如將不同應用數據存到不同的group就能隔離應用數據，同時還可根據應用的訪問特性來將應用分配到不同的group來做負載均衡；缺點是group的容量受單機存儲容量的限制，同時當group內有機器壞掉時，數據恢復只能依賴group內的其他機器，使得恢復時間會很長。
group內每個storage的存儲依賴於本地文件系統，storage可配置多個數據存儲目錄，比如有10塊磁盤，分別掛載在/data/disk1-/data/disk10，則可將這10個目錄都配置爲storage的數據存儲目錄。
storage接受到寫文件請求時，會根據配置好的規則（後面會介紹），選擇其中一個存儲目錄來存儲文件。爲了避免單個目錄下的文件數太多，在 storage第一次啓動時，會在每個數據存儲目錄裏創建2級子目錄，每級256個，總共65536個文件，新寫的文件會以hash的方式被路由到其中某個子目錄下，然後將文件數據直接作爲一個本地文件存儲到該目錄中。
2、Tracker server
Tracker是FastDFS的協調者，負責管理所有的storage server和group，每個storage在啓動後會連接Tracker，告知自己所屬的group等信息，並保持週期性的心跳，tracker根據 storage的心跳信息，建立group==>[storage server list]的映射表。
Tracker需要管理的元信息很少，會全部存儲在內存中；另外tracker上的元信息都是由storage彙報的信息生成的，本身不需要持久化任何數據，這樣使得tracker非常容易擴展，直接增加tracker機器即可擴展爲tracker cluster來服務，cluster裏每個tracker之間是完全對等的，所有的tracker都接受stroage的心跳信息，生成元數據信息來提供讀寫服務。
3、Uploadfile
FastDFS向使用者提供基本文件訪問接口，比如upload、download、append、delete等，以客戶端庫的方式提供給用戶使用。
選擇tracker server
當集羣中不止一個tracker server時，由於tracker之間是完全對等的關係，客戶端在upload文件時可以任意選擇一個tracker。
選擇存儲的group
當tracker接收到upload file的請求時，會爲該文件分配一個可以存儲該文件的group，支持如下選擇group的規則：
1.Round robin，所有的group間輪詢
2.Specifiedgroup，指定某一個確定的group
3.Load balance，剩餘存儲空間多的group優先
選擇storage server
當選定group後，tracker會在group內選擇一個storage server給客戶端，支持如下選擇storage的規則：
1.Round robin，在group內的所有storage間輪詢
2.First server ordered by ip，按ip排序
3.First server ordered by priority，按優先級排序（優先級在storage上配置）
選擇storage path
當分配好storage server後，客戶端將向storage發送寫文件請求，storage將會爲文件分配一個數據存儲目錄，支持如下規則：
1.Round robin，多個存儲目錄間輪詢
2.剩餘存儲空間最多的優先
生成Fileid(文件名)
選定存儲目錄之後，storage會爲文件生一個Fileid，由storage server ip、文件創建時間、文件大小、文件crc32和一個隨機數拼接而成，
然後將這個二進制串進行base64編碼，轉換爲可打印的字符串。
選擇兩級目錄
當選定存儲目錄之後，storage會爲文件分配一個fileid，每個存儲目錄下有兩級256*256的子目錄，storage會按文件fileid進行兩次hash（猜測），
路由到其中一個子目錄，然後將文件以fileid爲文件名存儲到該子目錄下。
生成文件名(訪問url:路徑+文件名)
當文件存儲到某個子目錄後，即認爲該文件存儲成功，接下來會爲該文件生成一個文件名，
文件名由group、存儲目錄、兩級子目錄、fileid、文件後綴名（由客戶端指定，主要用於區分文件類型）拼接而成。
4、Download file
客戶端upload file成功後，會拿到一個storage生成的文件名，接下來客戶端根據這個文件名即可訪問到該文件。
跟upload file一樣，在download file時客戶端可以選擇任意tracker server。
tracker發送download請求給某個tracker，必須帶上文件名信息，tracke從文件名中解析出文件的group、大小、創建時間等信息，然後爲該請求選擇一個storage用來服務讀請求。由於group內的文件同步時在後臺異步進行的，所以有可能出現在讀到時候，文件還沒有同步到某些storage server上，爲了儘量避免訪問到這樣的storage，tracker按照如下規則選擇group內可讀的storage。
1. 該文件上傳到的源頭storage -源頭storage只要存活着，肯定包含這個文件，源頭的地址被編碼在文件名中。
2. 文件創建時間戳==storage被同步到的時間戳且(當前時間-文件創建時間戳)>文件同步最大時間（如5分鐘)-文件創建後， 認爲經過最大同步時間後，肯定已經同步到其他storage了。
3. 文件創建時間戳< storage被同步到的時間戳。-同步時間戳之前的文件確定已經同步了
4.(當前時間-文件創建時間戳)>同步延遲閥值（如一天）。-經過同步延遲閾值時間，認爲文件肯定已經同步了。
5、文件同步
寫文件時，客戶端將文件寫至group內一個storage server即認爲寫文件成功，storage server寫完文件後，會由後臺線程將文件同步至同group內其他的storage server。
每個storage寫文件後，同時會寫一份binlog，binlog裏不包含文件數據，只包含文件名等元信息，這份binlog用於後臺同步，storage會記錄向group內其他storage同步的進度，以便重啓後能接上次的進度繼續同步；進度以時間戳的方式進行記錄，所以最好能保證集羣內所有server的時鐘保持同步。
storage的同步進度會作爲元數據的一部分彙報到tracker上，tracke在選擇讀storage的時候會以同步進度作爲參考
http://my.oschina.net/denglz/blog/488339
待議：
1.文件(例如圖片)是怎同步過去的？
2.storage1有路徑path和兩級目錄，那麼storage2和3應該也有，對應着？
3.怎麼判斷文件在storage2和3上存在的？
4.新添加tracker或者storage，怎麼動作的？
5.優缺點、適用情況？