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实时的处理数据下载到本地,备份下来;

上一篇:Python学习(七) 流程控制if语句


下一篇:windows下 zookeeper dubbo 安装+配置+demo 详细图文教程