1.1. 檔案上傳
FastDFS向使用者提供基本檔案訪問介面，比如upload、download、append、delete等，以客戶端庫的方式提供給使用者使用。
選擇tracker server
當叢集中不止一個tracker server時，由於tracker之間是完全對等的關係，客戶端在upload檔案時可以任意選擇一個trakcer。複製程式碼選擇儲存的group
當tracker接收到upload file的請求時，會為該檔案分配一個可以儲存該檔案的group，支援如下選擇group的規則：
- Round robin，所有的group間輪詢
- Specified group，指定某一個確定的group
- Load balance，剩餘儲存空間多多group優先
選擇storage server
當選定group後，tracker會在group內選擇一個storage server給客戶端，支援如下選擇storage的規則：
- Round robin，在group內的所有storage間輪詢
- First server ordered by ip，按ip排序
- First server ordered by priority，按優先順序排序（優先順序在storage上配置）
選擇storage path
當分配好storage server後，客戶端將向storage傳送寫檔案請求，storage將會為檔案分配一個資料儲存目錄，支援如下規則：
- Round robin，多個儲存目錄間輪詢
- 剩餘儲存空間最多的優先
生成Fileid
選定儲存目錄之後，storage會為檔案生一個Fileid，由storage server ip、檔案建立時間、檔案大小、檔案crc32和一個隨機數拼接而成，然後將這個二進位制串進行base64編碼，轉換為可列印的字串。
選擇兩級目錄
當選定儲存目錄之後，storage會為檔案分配一個fileid，每個儲存目錄下有兩級256*256的子目錄，storage會按檔案fileid進行兩次hash（猜測），路由到其中一個子目錄，然後將檔案以fileid為檔名儲存到該子目錄下。
生成檔名
當檔案儲存到某個子目錄後，即認為該檔案儲存成功，接下來會為該檔案生成一個檔名，檔名由group、儲存目錄、兩級子目錄、fileid、檔案字尾名（由客戶端指定，主要用於區分檔案型別）拼接而成。
檔案上傳型別有3種：
1)upload：上傳普通檔案，包括主檔案
2)upload_appender：上傳appender檔案，後續可以對其進行append操作【又用作斷點續傳】
3)upload_slave：上傳從檔案。
1.2. 檔案下載
客戶端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(當前時間-檔案建立時間戳)>同步延遲閥值（如一天）。 -經過同步延遲閾值時間，認為檔案肯定已經同步了。
Storage上的Nginx Module首先會去看本機有沒有被請求的檔案，如果沒有的話，會從FileId中解開源Storage的IP地址，然後去訪問，如果此時源Storage當機了，那麼本次下載請求就此失敗（Nginx Module從始至終沒有拿著被請求檔案的Group Name去問Tracker現在哪臺活著的Storage能響應請求）
由於以上的流程無法保證HA，所以我們還是決定在前端負載均衡裝置上手動根據URL中的GroupName將請求轉到相應的upstream組（Storage Server組）中，唯一的不好是，增加Group時需要調整負載均衡裝置的設定
1.3. 檔案刪除
刪除處理流程與檔案下載類是：
- Client詢問Tracker server可以下載指定檔案的Storage server，引數為檔案ID（包含組名和檔名）；
- Tracker server返回一臺可用的Storage server；
- Client直接和該Storage server建立連線，完成檔案刪除。
1.4. 檔案同步
寫檔案時，客戶端將檔案寫至group內一個storage server即認為寫檔案成功，storage server寫完檔案後，會由後臺執行緒將檔案同步至同group內其他的storage server。
每個storage寫檔案後，同時會寫一份binlog，binlog裡不包含檔案資料，只包含檔名等元資訊，這份binlog用於後臺同步，storage會記錄向group內其他storage同步的進度，以便重啟後能接上次的進度繼續同步；進度以時間戳的方式進行記錄，所以最好能保證叢集內所有server的時鐘保持同步。
storage的同步進度會作為後設資料的一部分彙報到tracker上，tracke在選擇讀storage的時候會以同步進度作為參考。
比如一個group內有A、B、C三個storage server，A向C同步到進度為T1 (T1以前寫的檔案都已經同步到B上了），B向C同步到時間戳為T2（T2 > T1)，tracker接收到這些同步進度資訊時，就會進行整理，將最小的那個做為C的同步時間戳，本例中T1即為C的同步時間戳為T1（即所有T1以前寫的資料都已經同步到C上了）；同理，根據上述規則，tracker會為A、B生成一個同步時間戳。
1.5. 斷點續傳
提供appender file的支援，通過upload_appender_file介面儲存，appender file允許在建立後，對該檔案進行append操作。實際上，appender file與普通檔案的儲存方式是相同的，不同的是，appender file不能被合併儲存到trunk file。.續傳涉及到的檔案大小MD5不會改變。續傳流程與檔案上傳類是，先定位到源storage，完成完整或部分上傳，再通過binlog進行同group內server檔案同步。
1.6. 檔案屬性
FastDFS提供了設定/獲取檔案擴充套件屬性的介面（setmeta/getmeta)，擴充套件屬性以key-value對的方式儲存在storage上的同名檔案（擁有特殊的字首或字尾），比如/group/M00/00/01/some_file為原始檔案，則該檔案的擴充套件屬性儲存在/group/M00/00/01/.some_file.meta檔案（真實情況不一定是這樣，但機制類似），這樣根據檔名就能定位到儲存擴充套件屬性的檔案。
以上兩個介面作者不建議使用，額外的meta檔案會進一步“放大”海量小檔案儲存問題，同時由於meta非常小，其儲存空間利用率也不高，比如100bytes的meta檔案也需要佔用4K（block_size）的儲存空間。
1.7. HTTP訪問支援
FastDFS的tracker和storage都內建了http協議的支援，客戶端可以通過http協議來下載檔案，tracker在接收到請求時，通過http的redirect機制將請求重定向至檔案所在的storage上；除了內建的http協議外，FastDFS還提供了通過apache或nginx擴充套件模組下載檔案的支援。
