最近了解了一个分布式文件系统――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，将其加载到内核中。

建议继续学习：

1. 分布式缓存系统 Memcached 入门    (阅读：14701)
2. Zookeeper工作原理    (阅读：10352)
3. GFS, HDFS, Blob File System架构对比    (阅读：9356)
4. Zookeeper研究和应用    (阅读：8500)
5. 分布式日志系统scribe使用手记    (阅读：8021)
6. 一致性哈希算法及其在分布式系统中的应用    (阅读：7912)
7. 分布式哈希和一致性哈希    (阅读：7634)
8. HBase技术介绍    (阅读：6737)
9. 分布式系统的事务处理    (阅读：5968)
10. Memcache分布式部署方案    (阅读：5429)