.前2期我發了一期文件服務器的好處，那么這期我就講解下如何搭建文件服務器，來方便我們的日常辦公。接下來我們來講解下文件服務器構造。如下圖， 基本有光貓、交換機、服務器、普通辦公電腦幾個部分組成。如果你是個新廠地，從無到有，這個時候要提前做好規劃，了解場地的布局，根據實際情況畫出網絡拓撲圖，然后再進行施工，如果的網絡已經搭建好了，只是增加一個文件服務器，那相對來說非常簡單了。
2.下面我們就重點講解下在已經構建好的網絡上，增加一個文件服務器的方法，
a.首先我們要準備一臺電腦，電腦的配置要求不是很高，一般的普通辦公電腦就好，如果你有閑置不用的工業級電腦或者服務器，那就最好了，如果沒有的話就用普通臺式電腦也可以，一般般的就行，但是硬盤應該盡量要用大一點的，最好用4TB以上的硬盤，因為文件服務器是專門放文件的，對容量需求比較大，最好用大一點的，而且最好用2個硬盤，一個固態硬盤安裝操作系統，一個普通的大容量硬盤存放文件。
b.準備好電腦以后，這個時候我們就開始安裝操作系統，文件服務器 屬于服務端，和我們普通的辦公電腦、家用電腦性質不一樣，所有不能安裝我們常用的Windows7 Windows10這些操作系統，我曾經也試過，直接安裝Windows7 Windows10的系統來做文件服務器，結果訪問的用戶多來之后電腦就會出現死機的情況，后面就選擇服務器專用系統Windows 2008 或者 Windows 2012操作系統， 可能大家沒咋聽過，因為它是專門用到服務器上的，經常接觸服務器的人應該比較清楚。
c.安裝操作系統的方法很簡單，和普通電腦安裝操作系統的方法一樣，安裝成功后，我們需要進入到控制面板里面，增加用戶，以及設置用戶權限，因為一個公司或者單位肯定有很多的部門，各部門的都有自己部門的文件，有些文件是可以共享的，有些屬于機密文件，不公開的，肯定不能所有有都進去看，有些文件可以看，但是不能誰都有修改或者刪除的權利吧，所有就要通過你的登陸用戶和密碼來設置不同的權限，來保證整改文件服務器來有序的運行，這點很關鍵。
d.當以上都準備好以后，將文件服務器接入網絡，并設置好服務器的IP地址，當然這個IP地址是必須和所在的網絡的地址段保持一致。設置好之后，我們就隨便找一臺辦公電腦進行訪問即可，按下快捷鍵windows+r 會彈出來一個運行的對話框，輸入\+文件服務器的IP地址就可以了。這個時候會提示，需要輸入用戶名和密碼，直接輸入之前分配好的用戶名和密碼就可以進入了。
4.以上就是文件服務器的搭建方法，可能在安裝的過程中會出現各式各樣的問題，但是問題并不可怕，辦法總比問題多，想要了解更多，可以關注我，我會定期將我的經驗分享給大家，你們的支持就是我最大的動力，也可以私信或者在評論區留言。
如何搭建一個簡易的文件服務器?#企業如何搭建文件服務器？ 安全、易用、可異地存取是關鍵！
企業選擇文件服務器受限于成本預算，通常會使用電腦主機或現有服務器自組搭建。但權限設置復雜、無法遠程存取、功能單一、操作不直觀等，降低管理效率。更重要的是，隨著勒索病毒轉向攻擊企業，文件服務器存在中毒風險且缺乏災備，一旦遭遇攻擊可能導致數據丟失。
將老舊的文件服務器更換為群暉 Synology NAS，文件共享和管理更加便利，而且無需擔心病毒威脅，提升工作效率和數據安全。
群暉文件服務器的 6 大要點
群暉文件服務器提供文件存儲、共享和數據保護方案，無需額外購買許可證，節省企業部署預算。
跨平臺、跨區域的即時共享
支持 SMB / NFS / FTP 等協議，局域網內共享。借助 SMB 聚合門戶，集中訪問多臺 NAS 共享文件夾，提升文件存取效率。并且無需自建 FTP，即可跨平臺、多終端隨時存??；總部和分支機構間也能便捷傳輸文件。
圖形化的權限安全管理
圖形化界面，操作直觀簡便，無需輸入指令或導入表格。支持委派專人管理權限，并且可設置密碼、有效期實現安全分享，通過導出權限報告實現權限審核。
不受地域限制的在線辦公
通過網頁或移動端 App，不受地域限制，即可實現移動辦公，還可設置文件離線訪問。并且支持在線 Office，多人協作提升團隊辦公效率。
融入現有 IT 的平滑遷移
支持 Windows AD 域和 LDAP 目錄服務，可直接加入企業已有帳號系統。并且支持 Windows ACL 13 種權限，實現平滑遷移，無需建立新帳號。
無懼病毒，自帶容災備份
為文件夾和 iSCSI LUN 建立快照保護，可快速恢復被病毒鎖定的文件，防止企業數據丟失。同時可為服務器、虛擬機和 PC 實現免許可證的整機備份方案。
數據防篡改，不可變更且合規
WriteOnce 一次性寫入，基于 WORM 存儲技術，協助企業符合法規規范和行業標準，保護數據未經授權被存儲、篡改，并有效抵御勒索病毒。
群暉代理體系：群暉國代，四川群暉代理商，成都群暉總代理，成都群暉經銷商，成都群暉企業方案商，成都群暉體驗中心，成都群暉銷售中心，成都群暉NAS存儲，群暉文件服務器
成都佳誠偉業科技有限公司是 一家IT產品分銷，系統集成為一體的專業服務提供商。主要為西南地區 用戶提供IT服務，公司先后入圍央采，省采，高校采購平臺。公司組建有專業的銷售團隊和技術服務團隊，高效的銷售和售后服務管理體系，及時快捷地為客戶 提供專業化服務。公司主營產品：電腦、服務器、工作站、存儲、辦公設備、會議設備、網絡設備。
今天給大家介紹的是FastDFS，一個開源的分布式文件系統，也是入職之后接觸到的一個技術，由于公司項目業務需求，服務器里存了上億量級的文件，所以使用了這么一項技術來存儲這些文件，我也就隨之開始了解這項技術，并且在這里和大家一起從0到1地開始了解它。
FastDFS是一個以C語言開發的開源輕量級分布式文件系統，由阿里巴巴開發并開源。它對文件進行管理，功能包括：文件存儲、文件同步、文件訪問（上傳、下載）等。解決了大容量存儲和負載均衡的問題。特別適合以文件為載體的在線服務，如相冊網站、視頻網站等等。
FastDFS為互聯網量身定制，充分考慮了冗余備份、負載均衡、線性擴容等機制，并注重高可用、高性能等指標，使用FastDFS很容易搭建一套高性能的文件服務器集群提供文件上傳、下載等服務。
從0，自己的一些疑問：FastDFS過時了嗎？
相信這也是很多同學想要問的一些問題，我還沒有了解這個技術的時候，也同樣有這樣的疑問。
首先，現在有很多文件存儲都會選擇像七牛云、阿里云OSS等云服務，為什么要自己搭一套文件服務器增加維護成本呢？
其次，這并不是面試的熱點，甚至在入職之前自己都沒有接觸過，甚至甚至，沒有聽說過，反倒是那些熱門的技術，就算自己不主動去了解，當遇到的時候，大致也能知道是用來干嘛的。
那么我來說說我的理解，首先這個技術一定是還沒有過時的，因為有些特殊的文件，因為信息安全顧慮等原因，不會選擇公有云服務器，還有基于成本考慮，還有很多的中型互聯網公司仍然是基于FastDFS來做自己的文件服務器的。另外，FastDFS作為一個分布式服務器，對輕量級、橫向擴展、容災備份、高可用、高性能、負載均衡都有著充分的考慮，依舊是一個文件服務器的不二之選。
那么為什么這樣一項技術在如今卻很少有人了解呢？
第一，我認為是需求所致，與其它業務相比，需要存儲大量文件的業務相對之下還是比較少。如果文件存儲量不大，按照傳統的文件存儲方式也不會有什么大的問題。
第二，現在有七牛云、阿里云OSS等公司提供對象存儲，加之國內對于”上云“的追捧，就很少有人愿意自己搭服務器來做文件存儲服務了。
當然對于一個技術人來說，各種各樣的技術都得去學習，去適應，所以這篇文章希望可以幫助到感興趣的同學，或是在工作中遇到高量級文件存儲的同學，FastDFS是不錯的選擇。
這是傳統文件存儲的方式，服務器上甚至不需要裝任何的應用，只需要有SFTP服務，我們就可以寫對應的代碼，完成文件的CRUD。
這樣的好處就是很方便，只需要一臺機器，幾行代碼就能搞定文件的存儲，但是這種方式的瓶頸和缺陷是很明顯的。
首先，對于單體服務器來說，不考慮宕機的情況，單體文件服務器的帶寬、磁盤容量是有上限的，那么當文件的體積占滿了整個磁盤，我們只能選擇擴展，但是這種單體服務器的方式，對于擴容就不太友好了，我們可以想想，難道我們要將原有的硬盤數據拷到一個更大的硬盤里，然后更換硬盤嗎？
除了擴展以外，我們還需要面臨一個問題，就是文件的查找，如果我們將所有文件都存放到一起，文件的數量如果到了一定的數量，就會面臨磁盤IO速度瓶頸，不知道大家有沒有遇到過下圖中這種場景：
磁盤查詢慢
如果我們需要在一個磁盤中找到某個文件，如果沒有一個路徑，或者路徑下有很多文件，那么系統就會掃描磁盤，我們都知道，計算機體系結構中，關于速度，CPU>內存>硬盤，如果在生產環境下，真的需要存儲大量的文件，假設存儲的是用戶的頭像，那么用戶每次打開APP，就需要等待個十幾秒，自己的頭像才會顯示，那這個app估計沒有人會使用吧。
有同學可能會說，那我們可以使用緩存啊，Redis的String類型是可以存儲二進制數據的，而且Redis的String類型是一個Key對應一個值，查詢效率會很高。的確這樣在查詢效率上可以達到，但是我們按照一張圖片1M來計算，緩存又能存多少張圖片呢？很顯然這是一個十分昂貴的方式。
剛才我們考慮的都是服務器不宕機的狀態，那么假設服務器宕機，那么我們就無法再提供數據存儲服務；如果硬盤損壞，那么所有的數據都將丟失。
上文中說了傳統文件存儲方式的一些缺陷和弊端，這其實也是所有“單點“的弊端，無論是單點數據庫、或者單點緩存、又或者是單點網關、單點注冊中心，都在往分布式集群的方向發展。
總結一下，單點文件系統大致有這些弱點：
1. 磁盤容量存在瓶頸
2. IO速度存在瓶頸
3. 宕機、硬盤損壞數據丟失的風險
那么對于文件系統，我們如何使用分布式的方式來解決上述的缺陷呢？
上文中提到，當服務器文件系統存在磁盤容量瓶頸的原因是磁盤無法很方便的進行擴容，我們通常需要從硬件的層面來考慮擴容硬盤，如：更換大容量硬盤。
這種方式顯然是不現實的，因為更換硬盤意味著我們需要關服務器，生產環境服務器關停三十秒都是很嚴重的生產事故，所以我們只能使用服務器橫向擴展的方式，如果不能更換硬盤，那么我們就加服務器。
多服務器
這樣我們就可以使用多臺服務器共同來構成我們的文件系統了，每個文件服務器都是一個獨立的節點，來存儲不同的文件，根據特定的邏輯（這里需要自己寫），來決定文件需要存儲到哪個文件服務器中。這樣即使服務器容量滿了，我們也還可以繼續橫向擴展，理論上這樣我們的文件系統是沒有容量上限的。
剛才我們解決了單點文件服務器容量瓶頸，但是如果某臺或者某幾臺服務器上的文件數量過多（查詢效率降低），或者有大量的用戶訪問某一臺服務器，還是會造成IO速度瓶頸。那么要如何解決這個問題。
我們可以想一想類似的案例——MySQL數據庫。
眾所周知，MySQL的數據也是存在硬盤中的，而我們在寫SQL語句的時候，為了保證查詢效率，通常會避免全表掃描，而是通過索引讓其找到我們對應的那條數據。
所以我們也可以通過這種方式，避免全盤掃描或者大范圍掃描，而我們都知道，操作系統對于文件是有一個天然的索引的，就是我們的多級目錄。FastDFS也正是利用了這個來增加我們文件IO的效率的，這個暫且不提，下文中會展示。
能否解決這個問題才是分布式文件系統和單機文件系統最根本的區別，因為無論是單機磁盤容量瓶頸還是IO速度瓶頸，我們都可以通過增加硬件配置來解決，只不過不太方便且成本太高罷了。而單機模式是絕對無法解決宕機造成的文件服務失效，或者硬盤損壞造成的數據丟失的，因為數據只存在一份。
那么我們思考一下分布式文件系統是如何來解決這些問題的。
首先我們需要解決宕機的問題，如上圖，我們有多個文件服務器節點，但是如果我們自己寫邏輯來決定某個文件應該存哪個服務器上，假設那個服務器此時宕機了，文件依舊是無法存入的，當然我們可以繼續寫邏輯來決定如果宕機了之后應該怎么辦，但是FastDFS中已經替我們實現了，Tracker節點可以幫助我們選擇文件應該上傳到哪個服務器上，并且還可以在某個節點宕機的時候選擇其從節點（備份節點）進行文件上傳，防止因為宕機造成的無法操作文件。
那么根據上面這幅圖，第二個問題也就很好理解了，假設某臺服務器硬盤損壞了，那么數據依舊會存在備份，即使備份服務器也損壞了，數據也只會丟失一部分，而不會全部丟失。
上面說了這么多的關于分布式文件系統可以解決的一些實際問題，那么就直接切入今天的主題——FastDFS。
FastDFS文件系統由兩大部分組成，客戶端和服務端。
客戶端通常指我們寫的程序（當然FastDFS也提供了客戶端測試程序），例如我們使用Java去連接FastDFS、操作文件，那么我們的Java程序就是一個客戶端，FastDFS提供專有API訪問，目前提供了C、Java和PHP等編程語言的API，用來訪問FastDFS文件系統。
服務端由兩個部分組成，分別是跟蹤器（Tracker）和存儲節點（Storage）。
跟蹤器（Tracker）：主要做調度工作，類似微服務注冊中心，在內存中記錄集群存儲節點的storage的狀態信息，是客戶端和服務端存儲節點storage的樞紐，因為相關信息全部在內存中，每個Storage在啟動后會連接Tracker，告知自己所屬的group等信息，并周期性發送心跳，TrackerServer的性能非常高，假設我們有上百個Storage節點，我們只需要3臺左右的Tracker就足夠了。
存儲節點（Storage）用于存儲文件，包括文件和文件屬性（metaData）都保存到服務器磁盤上，完成文件管理的所有功能：文件存儲、文件同步和文件訪問等。Storage以group為組織單位，一個group內可以包含多臺Storage機器，數據互為備份，總存儲空間以group內容量最小的storage為準（木桶），所以建議一個group內的機器存儲空間大小應該盡量相同，以免造成空間的浪費。Storage在第一次啟動時，會在每一個存儲目錄里創建二級目錄，共計256 * 256個目錄，我們上傳的文件會以Hash的方式被路由到其中某個子目錄下。
FastDFS整體架構
FastDFSUpload
FastDFSDownload
客戶端發送下載請求，Tracker根據文件信息，返回Storage地址和端口（客戶端也可以通過自己存儲的文件位置直接訪問Storage）。
客戶端訪問Storage，Storage根據file_id（組名、虛擬磁盤、二級目錄、文件名）查找到文件，返回文件數據。
當客戶端發起上傳請求時，會先訪問Tracker，由于Storage定期向Tracker發送狀態信息，所以Tracker中存有所有Storage Group的信息。
Tracker根據本地的Storage Group信息，為客戶端上傳的文件分配Storage Group，并返回給客戶端。
客戶端拿到Storage Group地址和端口后，上傳文件到指定的Storage Group中。
Storage返回文件的路徑信息和文件名。
Client將文件信息存儲到本地。
安裝前準備
安裝
安裝FastDFS需要兩個源碼包，分別是libfastcommon-1.0.43.tar.gz和fastdfs-6.06.tar.gz。
這里附上作者的github地址：fastdfs，libfastcommon，大家可以到這里下載對應的包。
下載完成后，將其上傳到我們的linux服務器中
分別運行tar -zxvf fastdfs-6.06.tar.gz和tar -zxvf libfastcommon-1.0.43.tar.gz對其進行解壓，解壓后進入libfastcommon-1.0.43目錄中運行sh make.sh，運行完畢后運行sh make.sh install，然后進入fastdfs-6.06目錄中執行相同的操作，即可完成安裝。
安裝成功后進入/usr/bin目錄下，如果存在很多fdfs開頭的命令，則證明安裝成功。
而/etfc/fdfs目錄中存放了所有的FastDFS的配置文件：
然后進入/etc/fdfs，這里存放了所有fastDFS的配置文件
最后一步，我們需要進入FastDFS安裝包解壓后的conf目錄下，找到http.conf和mime.types將其復制到/etc/fdfs目錄下。
這樣我們就完成了FastDFS的安裝。
安裝完成后需要先把配置文件配置好才能夠正常啟動，這里會貼上tracker.conf、storage.conf、client.conf的所有配置項，就當作一個配置模板吧，配置的時候可以直接copy。
首先是tracker.conf：
storage.conf：
需要配置tracker.conf和storage.conf
我們需要進行一些最小配置，來支持FastDFS的啟動。
首先是tracker.conf
然后是storage.conf
配置好并且檢查配置文件中的目錄都存在之后，將配置文件拷貝到/etc/fdfs目錄下，然后啟動tracker和storage即可。
啟動FastDFS后，可以去到我們剛才在storage.conf中配置的storage_path目錄下，可以看到FastDFS在這個目錄下創建了一個data目錄，在data目錄中創建了256*256個文件夾，用于分散存儲數據，這樣可以提高查找文件的效率。這個就是上文中所說的，FastDFS解決IO效率的一種手段，將文件分布到每個目錄下，類似于Java中的HashMap，通過文件的HashCode，迅速判斷文件的位置從而找到文件。
至此我們的FastDFS已經成功啟動。
檢查Linux上是否安裝了GCC、libevent、libevent-devel
如果沒有安裝，則需進行安裝
yum install gcc libevent libevent-devel -y上文中我們已經將FastDFS成功啟動，并且可以看到啟動后數據目錄的變化?，F在我們就可以使用客戶端來測試一下FastDFS的功能了。
首先我們需要配置一下客戶端，在/etc/fdfs目錄下找到client.conf配置文件，進行如下的最小配置：
配置完畢后，需要在任意目錄下，創建一個用于測試的文件。
創建好文件并寫入內容后，就可以對已部署的fdfs進行各種方式的測試了。
首先是文件上傳，FastDFS自帶的客戶端通過fdfs_test 配置文件 upload 需要上傳的文件路徑進行文件的上傳，示例如下:
當執行完這條命令之后，我們可以看到文件上傳到的storage server的一些信息，例如group_name，ip，端口等，還可以看到我們的文件上傳到那個group，存在這個group的哪個路徑下。
本次我們上傳的文件通過返回信息，可以看到上傳到group1下（因為我們只有一個storage并且只設置了一個group），上傳到的路徑為M00/ED/49/wKiJA19kwRqAI_g6AAAAEbcXlKw7921454，那么就可以到這個目錄下查看一下這個文件是否已經上傳成功了。
文件上傳成功，但是這個目錄下面不止存在我們剛才上傳的文件，還存在其它的一些文件，這里做一下說明：
filename：為文件本體。
filename-m：為文件元數據，例如文件的類型、大小、如果是圖片還有長度寬度等。
filename_big：為備份文件，如果存在主備服務器，那么該文件會存放到備份服務器上。
filename_big-m：文件元數據的備份，如果存在主備服務器，那么該文件會存放到備份服務器上。
文件下載，使用自帶的FastDFS測試客戶端，文件下載的方式與上傳類似，使用fdfs_test 配置文件路徑 download 組名 遠程文件名稱，即可下載該文件。
示例如下:
文件下載成功。
文件刪除測試，使用fdfs_test 配置文件路徑 delete 組名 遠程文件名稱示例如下：
發現僅存在文件備份，而文件本體已刪除成功。
我們只使用了FastDFS自帶的客戶端測試工具來測試文件的上傳、下載和刪除，但是在實際狀況下我們并不是這么操作文件的，而是通過程序發送請求來操作文件，那么就涉及到要通過HTTP訪問文件，這里單純依靠FastDFS就無法做到了，我們需要Nginx的配合。
Nginx的安裝這里就不再贅述了，這里就默認大家都安裝好了Nginx。這里直接進行nginx的配置。
配置之前我們首先需要一個nginx的擴展模塊包——fastdfs-nginx-module，這里同樣提供一個下載地址：fastdfs-nginx-module。
下載完成之后，將其上傳到服務器并解壓：
然后將mod_fastdfs.conf文件復制到/etc/fdfs目錄下，并且修改它，修改項如下：
配置完成后我們需要將這個擴展模塊新增到原來的nginx中：
修改nginx.conf文件，新增一個server:
然后重啟nginx：
如果你的nginx和fastdfs都是啟動狀態，那么此時已經可以訪問成功了。
訪問成功
完成了文件訪問之后，我們復盤一下剛才我們做了什么，首先我們安裝了nginx，然后將nginx的fastdfs擴展模塊添加到nginx中，之后進行了一下擴展模塊和nginx的配置，但在配置nginx的代理的時候，我們并沒有像以前一樣直接將代理地址寫入配置中，而是將原來寫代理地址的位置直接寫了fastdfs擴展模塊，那么這個模塊究竟是如何運行起來的呢？
按照傳統的nginx反向代理的配置方式，我們應該在攔截到請求之后，直接通過配置地址的方式，代理到目標服務器上，但是這里直接指向fastdfs模塊，很顯然，這個模塊幫我們干了這件事。
還記得我們在擴展模塊的配置文件中，配置了Tracker Server的地址嗎？
當我們請求任意一個Group時，都會被nginx攔截下來然后發送給擴展模塊，然后擴展模塊通過我們配置的這個Tracker Server的地址，將請求轉發給Tracker，Tracker會根據自己本地的group映射表，返回一個ip:port，例如我們剛才訪問的是group1，那么擴展模塊會將group1發送給Tracker， Tracker返回192.168.137.3:23000給nginx，然后擴展模塊再通過這個地址，去訪問storage，獲取文件流，返回給瀏覽器。
擴展模塊執行流程
單點FastDFS跑通之后，有同學可能就會有疑惑，那這和我們之前的文件系統也沒有很大差別啊，前面說的橫向擴展、容災備份我們也完全都沒有看到啊。
不急不急，這就來了。
剛才我們在一臺機器上部署了FastDFS，并且測試了上傳下載刪除等功能，最后整合nginx完成了使用瀏覽器對文件的訪問，并且了解了一下擴展模塊的運行原理。這些是為了讓大家更好的了解FastDFS，但是本篇文章主要介紹分布式文件系統，分布式文件系統最大的特點也就在于容災備份、可擴展、高可用。那么接下來就是重頭戲，來講講FastDFS分布式集群的搭建。
我們需要準備7臺Linux虛擬機，來完成本次集群的搭建，包括1臺Nginx，2臺Tracker Server，4臺Storage分為2個group，每個group中一主一備。
我這里準備的linux服務器信息如下：
其中Group1中的兩臺Storage相互備份，Group2中的兩臺Storage相互備份。
對這六臺服務器，按照上文中的安裝過程，依次安裝Nginx和FastDFS。(步驟如上)
建議在安裝之前執行yum命令先一次性將依賴包安裝完成：
yum -y install gcc perl openssl openssl-devel pcre pcre-devel zlib zlib-devel libevent libevent-devel wget net-tools
配置集群
集群的配置和上面單體的配置有些許不同，由于我們是將Tracker和Storage拆開，所以在裝Tracker的服務器上并不需要進行Storage的配置，同理在裝Storage的機器上也不需要進行Tracker的配置。
Tracker(101和102服務器)需要配置的點：
Storage(103 104 105 106服務器)需要配置的點：
storage配置
使用fdfs_trackered 配置文件路徑來啟動trakcer：
Tracker啟動
使用fdfs_stroaged 配置文件路徑來啟動storage：
我們可以在任意一臺storage服務器中，使用fdfs_monitor /etc/fdfs/storage.conf命令來查看整個集群的狀態：
可以看到集群已經搭建成功了，并且我們可以看到每個storage的狀態信息，例如每個節點的所屬組、IP、存儲空間大小、HTTP端口、是否啟動、連接的tracker server等等。
在六臺機器中隨意找一臺配置client.conf文件，配置項如下：
然后創建一個用于測試上傳功能的文件，創建完畢后，使用fdfs_upload_file進行上傳，由于我們設置的上傳模式是輪詢，所以記住要多上傳幾遍，才能看出效果。
集群上傳文件
上傳效果，可以看到group1的兩臺機器互為備份，而group2的兩臺機器互為備份。
剛才我們設置的上傳策略是輪詢，所以我們可以看到，每次在上傳的時候，都會切換到與上一次不同的group中。FastDFS可以設置三種不同的負載均衡策略，分別是：輪詢、指定一個group上傳、選擇一個剩余空間最多的group進行上傳。
由于篇幅有限，這里就不一一測試了，感興趣的同學可以在線下進行測試。
做一個簡單的回顧，上文中在配置單體的FastDFS時，我們是如何通過HTTP訪問文件的？
我們使用了nginx，安裝了fastdfs的擴展模塊，然后在nginx中做了一個反向代理指向擴展模塊，擴展模塊去請求我們的tracker server獲取到group對應的storage服務器的ip端口號等信息，然后擴展模塊拿到這個信息之后，就去storage server中獲取文件流，返回給瀏覽器。
所以FastDFS集群也一樣，我們也需要通過nginx來訪問文件，但是這里的配置略微有些不同。
我們得分這么幾種情況來配置nginx：Tracker、Storage、入口服務器。
Tracker Server的nginx配置：
啟動nginx，如果nginx的work process沒有正常啟動，需要將mod_fastdfs.conf、fastdfs解壓包目錄中的mime.types和http.conf復制到/etc/fdfs目錄下。
Storage Server的nginx配置：
首先需要配置mod_fastdfs.conf
nginx配置:
然后啟動Storage的nginx。
測試一下訪問：
測試訪問
實際我們剛才不論是訪問哪臺服務器，都是可以正常訪問到這個文件的。
我們可以來推一下剛才的訪問流程，我們剛才在tracker中配置了stroage的負載均衡，而在stroage的反向代理中配置了fastdfs的擴展模塊。
假設我們訪問的是tracker，那么tracker服務器我們配置了負載均衡，負載均衡會自動路由到任意一臺storage上，storage上配置了擴展模塊，會帶上我們訪問的group去請求tracker，tracker返回這個group的storage的ip和端口號。
那么假設我們訪問的是storage，那么storage里的擴展模塊就直接攜帶我們的url中的group去訪問tracker，一樣也能找到storage的ip和端口。
所以只要group是正確的，無論訪問哪臺機器，都可以訪問到文件。
還記得我們搭集群之前說過，我們需要7臺機器嗎，但是現在我們只用了6臺，第7臺機器就是用在這里。
因為剛才我們只是把集群搭起來了，但是這樣我們需要記住6個ip地址，再來回顧一下最初的架構圖：
我們需要提供一個nginx，負載均衡到兩個tracker中，然后我們之后的程序就只需要訪問這個入口，就可以正常使用整個集群的服務了。
nginx配置如下:
測試：
通過入口訪問成功
集群搭建完畢。
分布式文件系統對于傳統文件系統的一些優勢，具體在于容災備份、橫向擴展，和解決傳統文件系統文中介紹的具體的技術——FastDFS整合nginx，作為分布式文件系統的解決方案之一，可以很好的解決一些生產環境下的巨量文件存儲問題。
另外FastDFS也可以很方便的通過Java程序來對文件進行諸如上傳下載之類的操作，但由于篇幅原因，本文中沒有介紹到，當然如果大家感興趣的話我會在下一篇博客中來具體說說在真實項目是如何使用FastDFS的。