token 過期后返回的內容
http..=/etc/fdfs/anti-steal.jpg
【token 生成算法】：md5( + + ts) 同時ts沒有超過 ttl 范圍。
服務器會自動根據token,st 以及設置的秘鑰來驗證合法性。訪問鏈接形式如：
（2）【文件元數據解析】
根據 獲取元數據信息, 包括：源 ip，文件路徑，名稱，大小等。
（3）【文件訪問路由】
因文件的 包含了上傳文件時的源 IP ，所以在獲取不到本機下的文件時（未同步或者延遲情況下） 擴展組件，會根據源服務器IP 來重定向或者代理方式獲取文件。
重定向模式
配置項 = ，服務器返回302，重定向url
源 ip:port/文件路徑?=1
代理模式
配置項 = proxy，使用源 地址作為代理proxy的host，其他部分不變
四、同步機制
4.1 同步規則
同步只發生在本組的 之間。
源頭數據才需要同步，備份數據不需要再次同步。
新增 時，會由已有一臺 將已有的所有數據（源頭數據和備份數據）同步給新增服務器。
4.2 復制
文件同步采用異步復制方式， 使用文件記錄文件上傳、刪除等操作，根據進行文件同步。中只記錄文件ID和操作，不記錄文件內容 . 格式如下：
時間戳 | 操作類型 | 文件名
C M02/52/CB/
.jpg
操作類型（部分）：
C表示源創建、c表示副本創建
A表示源追加、a表示副本追加
D表示源刪除、d表示副本刪除
. . . . . . .
4.3 同步流程
新增 后，組內其他 服務器會啟動同步線程，在 的協調下向新增服務器發起全量和增量同步操作。
（1） C啟動后向 上報所屬group、ip、port、版本號、存儲目錄數、子目錄數、啟動時間、老數據是否同步完成，當前狀態等信息。
（2） 收到 C 加入申請請求后，更新本地 list，返回給C，并適時同步給A、B。
（3） C向 申請同步請求，響應后變更自身狀態為。
（3） A 和B 在心跳周期內從同步到的新 list 發現沒有C，則啟動同步線程，先向發起同步申請
（）,會把同步源IP級同步時間戳返回給A和B,如果源IP和自己本地IP一致，則標記自己作為同步源用來做老數據同步（全量同步源），如果不一致，則標記自己作為增量同步源（只有在C節點狀態為時才同步）。該決策是由 選擇產生的，不可A、B同時作為同步源，同時同步給C。
（3）同步源（假設是 A）以 .mark為后綴的文件記錄目標機器同步信息，并上報變更 C狀態為。
（5）數據同步過程中 C 的狀態變更過程->->。 是最終狀態，表示 C 已對外提供服務。
五、文件存儲
5.1 LOSF問題
小文件存儲（LOSF）面臨的問題：
本地文件系統梳理優先，存儲小文件數量受限。
目錄層級和目錄中文件數量會導致訪問文件開銷很大（IO次數多）。
小文件存儲，備份和恢復效率低。
針對小文件存儲問題， 提供了文件合并解決方案。 默認創建大文件為 64M，大文件可以存儲很多小文件，容納一個小文件的空間叫slot，solt 最小256字節，最大16M。小于256字節當256字節存儲，超過16M文件單獨存儲。
5.2 存儲方式
（1）【默認存儲方式】未開啟合并 ，生成的 和磁盤上實際存儲的文件一一對應。
（2）【合并存儲方式】多個對應文件被存儲成了一個大文件 。trunk文件名格式：//data/00/ 文件名從1開始遞增。而生成的 更長，會新增16個字節額外內容用來保存偏移量等信息。
如下：
【】：占用大文件的空間（注意按照最小slot-256字節進行對齊）
【mtime】：文件修改時間
【crc32】：文件內容的crc32碼
【】：文件擴展名
【】：文件大小與size相等
【id】：大文件ID如
【】：文件內容在trunk文件中的偏移量
【size】：文件大小。
5.4 存儲空間管理
（1）【Trunk 】由 在一組 選擇出來的，并通知給該組內所有 ，負責為該組內所有操作分配空間。
（2）【空閑平衡樹】trunk 會為每個構造一個空閑平衡樹，相同大小的空閑塊保存在鏈表中，每次上傳請求時會到根據上傳的文件大小到平衡樹中查找獲取大于或者接近的空閑塊，然后從空閑塊中分割出多余的作為新的空閑塊，重新加入平衡樹。如果找不到則會重建一個新的trunk文件，并加入到平衡樹中。該分配過程即是一個維護空閑平衡樹的過程。
（3）【Trunk 】開啟了合并存儲后，Trunk 會多出一個同步。記錄了 所有分配與回收的空閑塊操作，并由Trunk 同步給同組中其他 。
格式如下：
時間戳 | 操作類型 | |
| |
file.id| |
size A 0 0 0 1 0
各字段含義如下：
【file.id】：文件名，比如
【】：在文件中的偏移量
【size】：占用的大小，按照slot對齊
六、文件去重
不具備文件去重能力，必須引入 來配合完成。 是一個鍵值對的高效分布式hash系統，底層采用 DB 來做數據庫持久化，同步方式使用復制方式。在去重場景中，對文件內容做hash，然后判斷文件是否一致。
在文件上傳成功后，查看 存儲對應存儲路徑，會發現返回的是一個軟鏈接小文件 文件系統，之后每次重復上傳都是返回一個指向第一次上傳的文件的軟鏈接。也就保證了文件只保存了一份。
（注意：不會返回原始文件的索引，返回的全部都是軟鏈接，當所有的軟鏈接都被刪除的時候小文件 文件系統，原始文件也會從中被刪除）。
七、總結
真正意義上只是一個管理文件的系統（應用級文件系統），比如管理上傳文件、圖片等。并不像系統磁盤文件系統NTFS或者FAT 等這種系統級文件系統。