Moosefs源代码分析

一、分析MFS非常有用的资源

本来想写的，但是看到了CSDN上的资料就没这个心情了，非常详细的讲解分享给大家：

CSDN中非常详细的文档：http://download.csdn.net/detail/zmfsea/9385601

关键点很突出的博客：http://blog.csdn.net/mwx1234/article/details/38928723

百度运维改进版本的shadowmfs：http://blog.csdn.net/mwx1234/article/details/38945471

shadowmfs的讲解PPT:http://www.infoq.com/cn/presentations/moosefs-redis-structure-improvement-and-performance-promotion?utm_source=infoq&utm_medium=videos_homepage&utm_campaign=videos_row1

shadowmfs源码：https://github.com/ops-baidu/shadow-mfs

二、个人看代码经验

个人认为看源代码的关键点在以下几个方面：(尤其是像mfs这样注释少的)

1. 首先安装程序，体验她的所有功能；(对当前领域已经很熟悉的可以跳过这一步)

2. 如果是多模块的话，应该弄明白多模块之间的通信接口或者信息结构；

3. 通过消息结构猜测代码的实现细节；

4. 粗略看源代码的编码习惯，比如变量命名规则，相关变量和结构的声明位置等；

5. 凭经验找到程序的关键点，比如select、poll、epoll(事件驱动)、pthread_create(多线程运行)、pthread_cond(线程之间通信)、main(主函数)；

6. 逐步跟踪代码分析，如果常见的算法什么的如果没有必要的话就直接略过，关键难解的地方进行逐步调试。

三、对MFS分析或猜测后的概要

1、mfsmount:

主要就是两块：fuse和master_conn 流程大约是这样的：

(1) fuse监听挂载目录，调用main函数注册的回调函数;

(2) 读写回调函数分别把任务放到读写队列；一些mfs自定义(toolize,比如mfssetgoal之类)的操作直接走master-proxy；

(3) 读写队列分别由对应的读写线程处理。

(4) 读写线程调用公用的master通信模块发消息给master或者chunkserver，将返回后的消息处理之后返回给fuse，fuse通过VFS把结果返回给用户。

在(1)(3)步骤中，一定都是多线程的，因为客户端不同命令串行处理，万一一个任务耗时长，其他命令都排队等着肯定不行，当然配套的也会有最大的线程数限制。

(5) 在1-4中有各种缓存，缓存都是用hash方式存储在内存之中的。

2、master：

她的任务就比较杂，分别要维护mfsmount、mfschunkserver、mfsmetaloger的心跳和监听他们发的消息，这就是六个任务，还有需要处理一些需要定时的任务；

master、chunkserver和metaloger都是在主要架构中的模块；他们都有一个共同的框架：

(1) 首先初始化一个struct{name,function} RunTab[]的数组；

(2) initialize会遍历这个数组，调用RunTab中的function，

对应的函数就会把任务注册到各种队列中(如重载配置rlhead、定时任务timehead、事件驱动pollhead、心跳kahead)，当然还有一些是初始化一些资源，比如说缓存(dcm,datacachememory)什么的；

(3) 然后就是mainloop遍历这些队列处理任务；

mfsmaster设计真是让人感觉太简单粗暴，Linux上用poll，性能过3000的时候就出问题了，整个mfaster是单线程运行的，应该是为了保证读写一致性，反正不一致还要线程间来回用锁同步，还不如直接用一个线程，可以节省锁的开销，设计者应该是这样想的吧，当然简单一点就好，别人可以按照自己的业务自己再重新设计，比如百度的shadowmfs就是把master改成了异步多线程的实现方式。

3、chunkserver

对于chunk的分析，首先要看结构了

(1) chunkserver是按照chunk(64M)来存的，mfshdd指定的存储目录存的就是整块的chunk；

(2) 既然号称文件系统，chunk的组织方式一定是B+树了;

事实上，chunkserver要复杂得多，除了节点之间的关系外，边也掺和进来了，MFS实现的比较全，什么软连接、硬连接、多个目录对应同一个文件之类的都是支持的；

(3) 针对多个用户传输文件，一定是多线程的，而且一定用了线程池，保证所有客户端的文件都在传；

(4)传输和存储都是漫长的过程，中间出现问题的概率也很大，一定有对应的状态机制和状态之间的各种转换和很多容错设计；

(5) 既然mfsmount中有缓存机制，那么chunk中一定会要实时监测mfsmount中的那个cache是不是新的，如果有新的文件被改写，一定要通知客户端更新缓存；

4、metalogger:

应该是没什么内容的，就是直接和master直接通信，比个版本号，定时把master实时的处理数据下载到本地，备份下来；