这篇日志最早是保存在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：管理节点磁盘空间

节点上的文件动态地添加和删除，会在磁盘空间上留下不连续的磁盘空间，该进程在系统负载较低时扫描文件，整理磁盘空间