这篇日志最早是保存在Evernote中,后来写到了QQ邮箱的记事本里用发送给了导师,今天贴到CSDN博客上公布。
创建时间:2014年5月11日(星期天) 晚上7:25 | 分类:书签 | 天气:广州大雨-暴雨转大雨 | 字数:1930 | 发送到我的Qzone | 另存为... | 打印 | 添加到日历
本文提出了一个基于P2P的分布式文件系统的构想。它采用蜂群思想(受《失控》启发),最大化单个节点的智能性来实现群体存储的智能性。它的优点是支持无限扩容,动态添加和删除节点,自动优化存储,以及超强的容灾能力。
普通文件系统都需要一个NameNode,维护文件列表,客户端访问时先跟NameNode通信,获取存取文件的实际位置,再与data server通信得到文件内容,这里client与NameNode一直处于通信状态,需要得到文件位置再与之通信,这种系统的问题就在于如果NameNode挂掉,整个文件系统也会瘫痪。现有的方法是热备份NameNode,牺牲了一些性能,且在特殊条件下并不能保证效果。
因此设想一种去中心化的分布式文件系统,全部由data server组成。每个data server维护自身保存的文件和目录,并通过与其他Server之间的频繁通信来支持文件系统的正常功能,类似于全球路由转发系统。下面详细介绍不同的文件系统功能的实现:
P2PFS示例,蓝色表示访问请求,绿色表示请求转发,红色表示找到文件并执行文件通信
client可以从任何位置接入集群,只需要给通信的data server提交文件访问请求,请求只需包含文件名信息和client的地址,如果dataserver本机上有文件数据则直接发送给客户端,如果没有则转发访问请求,其他data server继续查找本机,没有则继续转发,转发之前与client通信确认client还在监听,有则根据请求信息与client发起连接,传输数据。
client接收到传输请求之后则关闭监听,开始传输数据,此时有可能其他data server还在转发该请求,但一旦监测到client已经启动连接则不再转发
client提出文件访问请求之后即相当于一台server,可以接收任意dataserver发起的连接而接收数据。它设置一个等待超时,超过该时间没有任何data server与这连接,说明这个文件是不存在的,client返回读文件失败
为了实现多次查找的优化。client请求时有一个参数,记录上次访问成功的节点作为参考,如果附加了这一字段,文件访问时会优先查找该主机,以便实现更快的查找。同时接入的server会缓存成功的连接,并在一定时间后失效,这样做的目的是如果文件访问比较频繁,省去了多次查找的麻烦。
data server转发时每次转发3台主机,总体上经过8次转发,就可以覆盖6500多台主机。但是要考虑如何避免请求的重复发送。
client接入任意一个data server即可写文件。首先发送写请求,该data server直接将文件写入本机,并发送备份给上行和下行的不同主机,文件描述信息和文件备份的保存位置一同保存,至少三份写完之后,client成功返回。
data server定期与保存自己文件备份的data server列表中的服务器通信,当有节点失效没有响应时,该data server就广播失效的节点。接收到失效通知的节点,包括上述节点,发送缺失备份的文件信息到其他的节点并更新备份信息。
查询文件系统中文件大小、是否存在、所有者,权限等信息时,只需要发送文件请求广播,收到请求的节点将文件描述信息,而不用返回文件数据。
本文件系统主要是依据文件名存取,文件夹可通过文件名加分隔符的形式实现。当查询文件夹下有哪些文件时,需要使用通配方式返回文件描述信息。
以同样的机制查找到文件位置之后,data server对文件执行增删改等操作,并根据自身文件的存储分布新增或释放(最终由驻守进程回收磁盘空间),当所有保存文件备份的data server返回成功信息时,client成功返回。
首先广播查找文件位置,应答的dataserver删除文件标记,并根据文件记录的备份信息发送删除通知,当data server接收到第一个响应地关闭监听,接收到3个响应时成功返回。
当节点访问量较大时选择只接收可承载的服务,被拒绝的文件访问请求经过转发自动发送到其他备份节点,并由这些节点发送数据给client
如何加载频繁被访问的文件的访问速度?包括固定client频繁访问和大规模频繁访问?
client访问时携带上次成功访问的dataserver信息,接收请求的server可据此快速定位。从而实现single client快速访问
接收client的data server的出口节点缓存成功的连接列表,当大量client通过该data server入口访问时,可快速定位
如何应对扫描,重命名,空间计算等标准文件系统需要的操作?
访问文件时支持通配符,获取文件夹下的文件列表可通过该方式解决。除此之外,文件头保存文件的容量,存储块地址(节点地址),文件名等信息,重命名等不涉及文件数据的操作时只需要修改这部分信息
如何应对大文件和小文件的存储要求?
大文件。大文件分成多个块存在不同的位置,访问文件时只需找到存放文件头信息的节点,该节点数据发送完成之后再通知下一个保存数据的节点继续发送,原理同内存中的非连续地址的连续访问
小文件以长字符串形式存储成大块,请求访问时定位到该大文件,通过大文件头保存文件信息将文件数据发送给client
每个data server上独立运行如下几个进程:
状态监控进程status:监控节点状态
用于监控dataserver自身的磁盘占用、CPU负载、网络吞吐量、温度等信息。用于机身状态异常报警,以及在用户查询集群状态时响应。
文件信息维护进程filecontrolers:维护节点文件目录信息
响应其他node发来的文件访问请求,并查询和更新本机保存文件的信息,可以是多个进程。dataserver保存的文件信息都存储在内存中,并通过该进程进行维护。
文件数据转发进程filetransfers:传输数据
对于文件信息维护进程确认的文件通信任务,如读文件操作,节点将传输任务交给该进程,该进程负责与client发起连接并传输数据,确保数据完整性,在传输结束之后断开连接。
集群心跳进程heartbeat:检测失效节点
节点上保存了许多文件,每个文件都有在不同节点上的备份,该进程与这些保存备份的节点定时通信,当有节点失效时,查找缺失备份的文件并传输到新的节点恢复文件。
磁盘空间管理进程diskmanager:管理节点磁盘空间
节点上的文件动态地添加和删除,会在磁盘空间上留下不连续的磁盘空间,该进程在系统负载较低时扫描文件,整理磁盘空间
基于p2p的分布式文件系统p2pfs的实现构想,布布扣,bubuko.com
原文地址:http://blog.csdn.net/byandong/article/details/38661527