最近了解了一個分布式文件系統——MooseFS，之前對分布式的東西知道的很少，分布式文件系統、分布式數據庫都是近而遠之，覺得太復雜了離我還很遙遠。在各位老師的推動下我用6臺機器實踐了一下moosefs，moosefs的部署還是很簡單的，和配置NFS很像，就是多了兩種角色的機器，正是有了它們，才使得moosefs在可擴展性和穩定性上都要遠好于NFS，在讀寫的性能方面，通過dd進行的簡單測試來看，moosefs也就是寫入的速度稍微好于NFS，讀上沒有差別。下面是對于MFS知識點的一些總結。

　　MFS系統由4個部分構成：master、metalogger、chunkserver、client。

　　Master —— mfs的大腦，記錄著管理信息，比如：文件大小，存儲的位置，份數等，和innodb中共享空間（ibdata）中存儲的信息類似，這些信息被記錄到metadata.mfs中，當該文件被載入內存后，該文件會重命名為metadata.mfs.back，當chunkserver上有更新時，master會定期將獲得的新的信息回寫到metadata.mfs.back中，保證元數據的可靠。

　　硬件推薦：大內存，因為內存中需要將metadata.mfs加載進來，這個文件的大小取決于你chunkserver上存儲的數據量，內存的大小會成為之后的問題，要ECC的可以進行錯誤校驗，當內存中數據量達到一定程度，如果沒有個容錯的機制，會很可怕；冗余電池，和磁盤配置RAID1/RAID5/RAID10，都是為了保證高可靠。

　　Metalogger —— mfs的備份，好比mysql中的m-s結構，metalogger會定期重master上將的metadata、changelog、session類型的文件下載同步到本地目錄下，并加后綴”_ml”將其重命名。

　　硬件推薦：與master機器配置一致，metalogger本身就是master的一個備機，當master宕機后，可以直接將metalogger提升為master。

　　Chunkserver —— 數據存儲地，文件以chunk大小存儲，每chunk最大為64M，小于64M的，該chunk的大小即為該文件大小，超過64M的文件將被均分，每一份（chunk）的大小以不超過64M為原則；文件可以有多份copy，即除了原始文件以外，該文件還存儲的份數，當goal為1時，表示只有一份copy，這份copy會被隨機存到一臺chunkserver上，當goal的數大于1時，每一份copy會被分別保存到每一個chunkserver上，goal的大小不要超過chunkserver的數量，否則多出的copy，不會有chunkserver去存，goal設置再多實際上也就沒有意義的。Copy的份數，一般設為大于1份，這樣如果有一臺chukserver壞掉后，至少還有一份copy，當這臺又被加進來后，會將失去的那份copy補回來，始終保持原有的copy數，而如果goal設為1copy，那么當存儲該copy的chunkserver壞掉，之后又重新加入回來，copy數將始終是0，不會恢復到之前的1個copy。

　　Chunkserver上的剩余存儲空間要大于1GB（Reference Guide有提到），新的數據才會被允許寫入，否則，你會看到No space left on device的提示，實際中，測試發現當磁盤使用率達到95%左右的時候，就已經不能寫入了，當時可用空間為1.9GB。

　　硬件建議：普通的機器就行，就是要來存幾份數據，只要磁盤夠大就好。

　　Client —— 客戶端通過內核加載的FUSE模塊，再通過和master的溝通，將chunkserver共享的分區掛載到本地，然后進行讀寫操作。由于FUSE模塊是外加的模塊，當系統重啟后，需要執行modprobe fuse，將其加載到內核中。