文件服務器
基礎概念介紹
FastDFS:
FastDFS是一款開源的輕量級分佈式文件系統純C實現，支持Linux、FreeBSD等UNIX系統類google FS，不是通用的文件系統，只能通過專有API訪問，目前提供了C、Java和PHP API爲互聯網應用量身定做，解決大容量文件存儲問題，追求高性能和高擴展性FastDFS可以看做是基於文件的key value pair存儲系統，稱作分佈式文件存儲服務更爲合適。
適用場景：
特別適合以中小文件（ 建議範圍： 4KB 到 500MB ） 爲載體的在線服務， 如相冊網站、 視頻網站等等。
三個角色
1. tracker-server:
跟蹤服務器， 主要做調度工作， 起負載均衡的作用。 在內存中記錄集羣中所有存儲組和存儲服務器的狀態信息， 是客戶端和數據服務器交互的樞紐。 相比GFS中的master更爲精簡， 不記錄文件索引信息， 佔用的內存量很少。
2. storage-server:
存儲服務器（ 又稱：存儲節點或數據服務器） ， 文件和文件屬性（ metadata） 都保存到存儲服務器上。 Storage server直接利用OS的文件系統調用管理文件。
3. client：
客戶端，作爲業務請求的發起方，通過專有接口，使用TCP/IP協議與跟蹤器服務器或存儲節點進行數據交互。FastDFS向使用者提供基本文件訪問接口，比如upload、download、append、delete等，以客戶端庫的方式提供給用戶使用。
另外兩個概念
group:
組， 也可稱爲卷。 同組內服務器上的文件是完全相同的 ，同一組內的storage server之間是對等的， 文件上傳、 刪除等操作可以在任意一臺storage server上進行 。
meta data:
文件相關屬性，鍵值對（ Key Value Pair） 方式，如：width=1024,heigth=768 。
單機文件系統 VS 分佈式文件系統
單機文件系統
單機時代初創時期由於時間緊迫，在各種資源有限的情況下，通常就直接在項目目錄下建立靜態文件夾，用於用戶存放項目中的文件資源。如果按不同類型再細分，可以在項目目錄下再建立不同的子目錄來區分。例如： resources\static\file、 resources\static\img等。
優點：這樣做比較便利，項目直接引用就行，實現起來也簡單，無需任何複雜技術，保存數據庫記錄和訪問起來也很方便。
缺點：如果只是後臺系統的使用一般也不會有什麼問題，但是作爲一個前端網站使用的話就會存在弊端。一方面，文件和代碼耦合在一起，文件越多存放越混亂；另一方面，如果流量比較大，靜態文件訪問會佔據一定的資源，影響正常業務進行，不利於網站快速發展。
獨立文件服務器
隨着公司業務不斷髮展，將代碼和文件放在同一服務器的弊端就會越來越明顯。爲了解決上面的問題引入獨立圖片服務器，工作流程如下：項目上傳文件時，首先通過ftp或者ssh將文件上傳到圖片服務器的某個目錄下，再通過ngnix或者apache來訪問此目錄下的文件，返回一個獨立域名的圖片URL地址，前端使用文件時就通過這個URL地址讀取。
優點：圖片訪問是很消耗服務器資源的（因爲會涉及到操作系統的上下文切換和磁盤I/O操作），分離出來後，Web/App服務器可以更專注發揮動態處理的能力；獨立存儲，更方便做擴容、容災和數據遷移；方便做圖片訪問請求的負載均衡，方便應用各種緩存策略（HTTP Header、Proxy Cache等），也更加方便遷移到CDN。
缺點：單機存在性能瓶頸，容災、垂直擴展性稍差
分佈式文件系統
通過獨立文件服務器可以解決一些問題，如果某天存儲文件的那臺服務突然down了怎麼辦？可能你會說，定時將文件系統備份，這臺down機的時候，迅速切換到另一臺就OK了，但是這樣處理需要人工來干預。另外，當存儲的文件超過100T的時候怎麼辦？單臺服務器的性能問題？這個時候我們就應該考慮分佈式文件系統了。
業務繼續發展，單臺服務器存儲和響應也很快到達了瓶頸，新的業務需要文件訪問具有高響應性、高可用性來支持系統。分佈式文件系統，一般分爲三塊內容來配合，服務的存儲、訪問的仲裁系統，文件存儲系統，文件的容災系統來構成，仲裁系統相當於文件服務器的大腦，根據一定的算法來決定文件存儲的位置，文件存儲系統負責保存文件，容災系統負責文件系統和自己的相互備份。
優點：擴展能力: 毫無疑問，擴展能力是一個分佈式文件系統最重要的特點；高可用性: 在分佈式文件系統中，高可用性包含兩層，一是整個文件系統的可用性，二是數據的完整和一致性；彈性存儲: 可以根據業務需要靈活地增加或縮減數據存儲以及增刪存儲池中的資源，而不需要中斷系統運行
缺點：系統複雜度稍高，需要更多服務器
部署結構:
Tracker相當於FastDFS的大腦，不論是上傳還是下載都是通過tracker來分配資源；客戶端一般可以使用ngnix等靜態服務器來調用或者做一部分的緩存；存儲服務器內部分爲卷（或者叫做組），卷於卷之間是平行的關係，可以根據資源的使用情況隨時增加，卷內服務器文件相互同步備份，以達到容災的目的。
適合小公司的最小化部署圖：
192.168.1.177安裝fastdfs的tracker節點，以及nginx反向代理服務器用於下載服務。
192.168.1.188，192.168.1.189安裝fastdfs的storage節點，默認分一組，一組內兩臺機器互爲備份.
注意：爲了做到高可用，一個group建議分爲兩臺以上的機器。
上傳機制
首先客戶端請求Tracker服務獲取到存儲服務器的ip地址和端口，然後客戶端根據返回的IP地址和端口號請求上傳文件，存儲服務器接收到請求後生產文件，並且將文件內容寫入磁盤並返回給客戶端file_id、路徑信息、文件名等信息，客戶端保存相關信息上傳完畢。
內部機制如下：
選擇tracker server
當集羣中不止一個tracker server時，由於tracker之間是完全對等的關係，客戶端在upload文件時可以任意選擇一個trakcer。 選擇存儲的group 當tracker接收到upload file的請求時，會爲該文件分配一個可以存儲該文件的group，支持如下選擇group的規則：
1、Round robin，所有的group間輪詢
2、Specified group，指定某一個確定的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、剩餘存儲空間最多的優先
4、生成Fileid
選定存儲目錄之後，storage會爲文件生一個Fileid，由storage server ip、文件創建時間、文件大小、文件crc32和一個隨機數拼接而成，然後將這個二進制串進行base64編碼，轉換爲可打印的字符串。 選擇兩級目錄 當選定存儲目錄之後，storage會爲文件分配一個fileid，每個存儲目錄下有兩級256*256的子目錄，storage會按文件fileid進行兩次hash（猜測），路由到其中一個子目錄，然後將文件以fileid爲文件名存儲到該子目錄下。
精巧的文件ID-FID
說到下載就不得不提文件索引（又稱：FID）的精巧設計了。文件索引結構如下圖，是客戶端上傳文件後存儲服務器返回給客戶端，用於以後訪問該文件的索引信息。文件索引信息包括：組名，虛擬磁盤路徑，數據兩級目錄，文件名。
組名：文件上傳後所在的存儲組名稱，在文件上傳成功後有存儲服務器返回，需要客戶端自行保存。
虛擬磁盤路徑：存儲服務器配置的虛擬路徑，與磁盤選項store_path*對應。
數據兩級目錄：存儲服務器在每個虛擬磁盤路徑下創建的兩級目錄，用於存儲數據文件。
文件名：與文件上傳時不同。是由存儲服務器根據特定信息生成，文件名包含：源存儲服務器IP地址、文件創建時間戳、文件大小、隨機數和文件拓展名等信息。