CN106027647A

CN106027647A - Lxpfs集群分布式文件存储系统

Info

Publication number: CN106027647A
Application number: CN201610339942.1A
Authority: CN
Inventors: 李瑜; 段睿宏; 杨晴; 张劲松; 邓安明
Original assignee: Tongfang Technology of Yunnan Power Grid Co Ltd
Current assignee: Tongfang Technology of Yunnan Power Grid Co Ltd
Priority date: 2016-05-20
Filing date: 2016-05-20
Publication date: 2016-10-12
Anticipated expiration: 2036-05-20
Also published as: CN106027647B

Abstract

LXPFS集群分布式文件存储系统，采用LXPFS集群给应用提供访问方法，通过封装好的JS API访问LXPFS中的文件；访问LXPFS文件的方式分为三种：读、写和删除；在前端实现访问LXPFS文件的组件，在Web应用开发中只需生成一个组件，调用相应的接口就能实现访问；系统采用主从模式架构，由一个Dispatchnode和一个及以上的Tasknode组成；Dispatchnode是一个controller服务器，负责调配所有文件的存储以及处理并转发客户端的请求，负责管理它所在节点上的存储和响应客户端的请求；上传文件是将数据写入Tasknode中，下载文件则是读取Tasknode文件数据。本系统采用对大文件分割的方式进行上传，对上传的文件没有大小限制，解决了大容量存储、分布存储、负载均衡等问题，它以服务的方式提供Web服务器一个文件管理组件的功能。

Description

LXPFS集群分布式文件存储系统

技术领域

本发明用于解决Web服务项目对文件访问和文件的存储，具体涉及LXPFS集群分布式文件存储系统的技术领域。

背景技术

基于Web技术的应用系统，由于开发周期短，与用户平台无关，易于实现交互应用，能对信息进行快速、高效地收集、处理和发布，近几年来得到了快速发展。

数据对于应用是很重要的，可以这么说几乎所有的应用系统开发都是围绕着数据进行的，Web应用系统也不例外。在用户使用的过程中，应用系统在用户需要时提供数据。Web系统在与用户交互，其实也是一个数据交换过程。应用系统的数据主要保存在数据库和文件里，然而数据库也是基于文件的。应用系统的信息数据一般是保存在数据库里，大的数据则保存在文件里。所以文件管理系统对于Web应用同样是一个基础而重要的功能模块之一。

为了方便用户的使用，Web应用一般提供三种对文件的访问方式，上传、下载和删除，也可以说写入、读取和删除。文件上传存在多种技术，常见的有：基于JS框架提供的上传组件；基于数据库技术；使用控件进行上传；使用其他的上传组件等。使用JS框架提供的上传组件，代码的可重用性变得异常差。多个使用不同JS框架开发的Web应用服务系统，就存在多个不同版本的文件管理功能模块。基于数据库的上传，一般是将文件保存在数据库里。这种方式虽然能够提高文件的索引，便于维护和管理，但对于存储空间的浪费也是很突出的。使用不同的上传技术，都会有不同的弊端。相比传统的上传技术，LXPFS(Linux XProgram FileSystem)在减少弊端和完善。

很多Web上传都对大文件上传做了限制，这是因为上传文件过大，Http上传请求会长时间占用资源，可能致使浏览器挂死。为了实现克服大文件的上传，于是又出现了使用控件的方法。比如网页版的百度网盘和360网盘，在用户上传的文件大小超过限制时，会提示用户安装控件。虽然使用控件实现了大文件的上传，但是它增加了开发难度和提高了开发成本，我们必须针对不同的平台系统和不同的浏览器开发不同版本的控件，这显然不为开发人员所乐见。一些专业的团队开发了上传的组件，它相比以上任何上传技术都有很大的进步性，可是每个使用这些上传组件的系统都是孤立的。这些孤立的系统就如孤岛一样，资源无法共享没有被有效利用。

LXPFS采用文件分片上传的方式，实现了大文件的上传。并且在前端实现中，未引入任何JS框架，这样提高了Web应用系统的兼容，减少了对Web应用开发的技术限制。在前端只是实现了基本的上传组件功能，所有的界面展示交由Web应用，这种方式相比有些上传组件更加灵活。LXPFS采用了秒传技术，提高上传效率，很多上传组件也有所实现，但是LXPFS相比组件而言，它是一个服务系统。它给每个Web应用服务系统提供一个文件访问的组件功能，允许多系统接入，它同时存储多个应用系统的数据，扩大了文件共享的范围，增加了秒传的机率。并且LXPFS对应用系统的数据又做了相应的隔离，对于安全有很好的保障。它打破了上传组件的孤岛模式。

LXPFS是一个轻量级分布式存储系统，相比Hadoop、tfs等分布式存储系统而言，LXPFS在安全方面做了特殊的限制，并且它主要是面向Web应用开发。它旨在提高文件的上传效率，实现交互信息很少而可做的操作很多。相比其他的分布式文件存储系统，它更偏重于降低Web应用系统对于文件管理模块功能的开发难度，统一多个应用系统的文件管理开发，同时减少Web应用服务系统对于文件管理模块的运维成本。并且它多种备份策略，是从集群HA(高可用)架构和文件的特殊存储方式等多方面来实现的。在集群架构的节点的功能划分也是不同的。

发明内容

为了避免应用的重复性开发，一般的做法是把功能模块进行抽象，形成一个独立的组件，并提供相应的接口进行调用。LXPFS是一个轻量级的分布式文件存储系统，它以服务的方式提供给Web应用一个文件存储管理的功能组件，因此它允许多个Web应用接入，而LXPFS则会接管这些Web应用的文件管理的工作。LXPFS的出现降低了开发的难度，减少了开发成本。对比文件管理组件，LXPFS统一管理多应用的文件，扩大了文件共享池的范围，增加了秒传的机率，使上传效率有很大提高，同时也降低了Web应用中的文件管理的运维成本。

1组件服务

LXPFS给应用提供了访问方法，可以通过封装好的JS API访问LXPFS中的文件。访问LXPFS文件的方式分为三种，读、写和删除。我们已经在前端实现了访问LXPFS文件的组件，在Web应用开发中，只需要生成一个组件，调用相应的接口就可以实现访问。

组件分为三个功能模块，上传功能、下载功能和删除功能。上传文件是写入LXPFS集群Tasknode数据的一种方式，而下载文件则是读取Tasknode文件数据的一种方式。

上传组件服务被封装成一个实体类QFileUpload。每个QFileUpload实体类中维护着一个上传队列。上传之前需要先选择本地文件，选择的一个本地文件将被封装成一个上传任务对象，并被自动添加到上传任务队列里。上传任务对象随机产生一个唯一的ID值作为文件ID(fd)，还会计算生成文件的MD5值，并保存了上传文件的相关信息和上传信息。添加上传任务队列完成后即可进行上传，由于添加文件的MD5计算是异步的，所以在上传时有些比较大的文件有可能还没有获得MD5值，这时上传服务组件会自动获取已经数据准备完成得上传任务，然后依次执行。

下载、删除的组件服务和上传的组件服务实现思路是一致的。文件以分片的方式进行上传，文件块被分散保存在LXPFS集群的Tasknode上。Tasknode的任务进程实例在接收下载请求时，会根据文件共享池里的映射关系表索引文件块，并把这些文件块拼接形成一个完整的文件以支持组件下载。

1.1文件分片

Http发送上传请求，大文件内容较多需要传输的数据量较大，因此上传需要很长时间。Http的长时间请求，占用资源，会致使浏览器挂死。为了防止浏览器挂死，所以很多浏览器一般都会限制上传文件的大小。上传的文件超过浏览器的文件大小限制，那么就无法上传。我们采用的方法是把大文件分割成多个较小的文件块，上传这些文件块时间较短，不会长时间占用资源。

数据的最小单位是位，单位的有序数据集合组成数据块。而这些数据块的位置是被编号的，因此，可以认为有效的数据是有序的，数据块只是数据集合的一个子集，也就是一个片段。

文件其实可以看作是一个有序的字节串，字节串中第一个字节是文件的头，最后一个字节是文件的尾。每一个文件为了便于系统和用户识别，都被分配了一个便于理解的名字。典型的文件操作有读、写、创建和删除等。文件通过目录组织起来，因为目录也可以包含子目录，所以目录可以层层嵌套，形成文件路径。从本质上讲，文件系统是特殊的数据分层存储结构，而文件则是有效存储的数据块。因此大文件只是一个较大的有序的数据片段，同样也可以看作是由其他多个数据小片段组成的。当然这些数据片段并不是随意组合的，它们是有序的。

Html5增加了很多新的特性，其中之一就是提供了Web应用可读取本地文件的API。在此之前读取本地文件的操作被认为是不安全的，所以是被禁止的。使用该特性，按照一个设定的大小值来读取文件，可以把大文件进行分片。每读取到的一个文件片段将被封装成一个blob对象，即成为一个文件块，也可以说是文件切片。根据文件的大小和分片的设定值，一个文件可能被分割成一个或者多个文件块。假设文件的大小为10M，我们的文件切片的设定值是4M，那么文件分割后的文件块数计算如下：10M/4M＝2.5，所以文件块数为3。

分割后的文件块，由一个UUID值标识，这个值我们可以称之为文件块ID。除此之外文件被顺序读取，有序分割，分割后的这些文件块是有序的，为了标明这种有序性，我们使用一个编号值来设定文件块的顺序。文件分片具体可以参考图1。

如图1所示，大文件被分割成一组文件块。这时上传一个大文件，需要把它所有的文件切片都进行上传。相当于一个大文件的上传操作被分解成了一组小文件上传的操作。

1.2断点续传

所谓断点续传，就是网络中断、上传错误等原因导致文件上传意外中断，文件再次上传时，不需要从文件的文件头开始进行上传，而是从文件上传中断时的断点位置开始上传的操作。

现实生活中，意外是无法避免的。有时文件很大，也许有几G，而带宽有限，用户上传下载文件需要历时很久，甚至数小时。万一网路中断，或者出现上传错误，不具备断点续传，那该文件又要重新开始上传或下载，可以想象用户会是什么样的表情。断点续传允许用户在断点继续上传，不必从头开始，它对于用户体验是一个很大的提升。

文件分片上传，文件块的相关属性也会一并传输给服务器。服务器保存文件的上传信息，包括文件分片的信息。服务器通过这些信息，可以获取到文件切片数、已经上传的文件块，以及文件块的对应序号等。当意外原因导致上传任务失败，再次手动重启这次任务时，服务器就会根据上次上传的记录信息，通过一定算法获得当前需要上传的文件切片。也就是说，当用户进行上传时，文件需要上传哪一片哪些片是完全由服务器计算得到，前端只是根据服务器的计算值来执行上传任务。

因此，文件上传意外中断，服务器同样可以计算得到上次文件上传任务已经上传的断点值，前端则依据这个断点值来重启这个上传任务。文件不会从文件头开始上传，而是从断点处的文件块开始上传，这样就实现了断点续传的功能。

1.3秒传

秒传是一种特殊的上传技术手段，事实上并没有实际的数据输出，只是对上传的文件完成一个映射而已。

随着时间轴的推移，上传到文件存储服务器的文件数量会逐渐增多。这些保存在文件服务器上的文件资源对于上传是开放的、共享的，所有的文件资源就形成了一个文件共享池。上传的文件资源数量越大，文件共享池越大，相同文件重复上传的机率就会越大。如果一个文件已经在文件共享池里存在，这个文件每次重复上传都把该文件的内容重复地传输给服务器，并在服务器上重复保存相同的副本，那么这样既浪费存储空间，上传效率也极低。上传到文件服务器的文件的主要用途是，在用户需要使用时提供使用，比如查看文件内容、下载文件等。众所周知在电影院看同一部电影，电影院一般会安排这些人在同一个包间内进行统一播放，而不是为每个人提供一个显示器为每个人单独播放，因为这样既浪费资源，又效率极低。因此，我们只会为同一文件在文件共享池里保存至多一个副本。在文件重复上传时，就建立一条记录映射文件共享池里的对应文件，从而避免了上传时文件数据的重复传输。

MD5是一个将任意长度的数据字符串转化成短的固定长度的值得单向操作。因此MD5可以用于校验字符串或者文件，如果文件的MD5不一样，说明文件的内容也是不一样的。就好比每个人的指纹都是唯一的一样，文件的MD5值也是唯一的。因此可以在文件上传时对文件的MD5进行校验，判断文件是否已经存在于文件服务器上。当检索到上传文件的MD5值和文件服务器上某个文件的MD5值相同，那么服务器就会产生一条新记录保存文件的相关信息和文件的存储位置，然后保存于数据库中，这样就完成了文件的映射。如果需要使用这个文件，就会根据记录里记录文件的存储位置的信息读取出文件数据，具体如图2所示。

2分布式存储

LXPFS是一个轻量级的分布式文件存储系统，它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的，实现方式也是全新的。

LXPFS采用的是主从模式(controller/worker)的架构。一个LXPFS集群是由一个Dispatchnode和一定数目的Tasknode组成。Dispatchnode是一个controller服务器，负责调配所有文件的存储以及处理并转发客户端的请求。集群中的Tasknode一般是一个节点一个，负责管理它所在节点上的存储和响应客户端的请求。Dispatchnode和Tasknode被设计成可以运行在安装GNU/Linux操作系统(OS)的机器上。一个典型的部署场景是一台机器上只运行一个Dispatchnode实例，而集群中的其他机器分别运行一个Tasknode实例。事实上一台机器上可以同时运行多个实例进程。集群中只有一个controller服务器，只有单一的Dispatchnode实例。我们的controller服务器和worker服务器是可以相互转换角色的，不过在转换的过程中需要做一些特殊的配置和部署。

如图3所示，LXPFS使用HA(HighAvailable)高可用集群架构。为保证系统运行的连续性，一般有一个或两个以上的节点，且分为活动节点和备用节点。当活动节点出现问题，导致正在运行的业务(任务)不能正常运行时，备用节点此时就会侦测到，并立即接续活动节点来执行业务。从而实现业务的不中断或短暂中断。图中worker就是Tasknode的活动节点，而backuper则是Tasknode的备用节点。controller也有一个备用节点controller1，如果maser发生意外，controller1将取代controller进行工作。

2.1文件组织和文件存储

2.1.1文件存储

LXPFS文件存储系统将每个写入的文件存储成一系列的数据块，除了最后一个，所有的数据块都是同样大小的。每个文件的数据块大小都是可配置的，并且拥有在集群里唯一的编号(Block ID)，Block ID在前端文件分片时生成。在Tasknode上，LXPFS基于Linux以文件和目录的形式组织这些文件数据。LXPFS根据系统时间，新建一些挂载目录，文件写入时文件块会以文件的形式被组织放在相应的目录下。

如图4所示，LXPFS集群Tasknodes上所有的文件数据形成一个大的文件存储空间，在这个空间里包含了所有接入的Web应用的数据。在这个大的存储空间里有一个文件共享池，文件共享池里的每个文件由一个唯一的MD5与之一一对应，这些文件是不同的。接入的应用服务系统在存储空间里维护着各自的应用空间表，在这张表里每个文件被赋予一个文件ID，文件与文件共享池里的文件建立映射，从而实现了应用空间的文件维护。

LXPFS支持文件的“一次写入多次读取”，就是文件一旦写入LXPFS集群，该文件的相关信息就不会被改动，比如文件ID，文件关联的文件块的存储信息，以及文件块的命名等都不会能被改动。这么做是为了维护文件的完好性。

LXPFS为了支持高可用性，采用特别的文件存储策略，具体如下：一个文件的所属文件块被分散在集群中的Tasknode；一个文件一定存在多个备份，并且这些文件备份也以文件块的方式分散存储在集群的Tasknode上；这些备份的存储算法如下：保证任意一个Tasknode上的所有文件数据，在其他Tasknode上至少存在一个这些文件的完整完好备份。

为了保障数据的有效性，LXPFS会对文件块进行有效性检查。每个文件块在写入前，系统都会记录这个文件块的MD5值，作为它的有效性检查的依据。如果保存在系统上的某个文件块计算得到的MD5值与记录的MD5值无法对应，那么说明此文件块内容被修改，其将被视为无效。

2.1.2文件的删除

当用户或应用程序删除某个文件时，这个文件并不是直接从LXPFS上删除。实际上LXPFS会先检测这个文件在共享池里是否还在其他的映射。如果存在即被判断为软删除，那么只是删除用户所属的那条记录和映射。要是文件不存在其他的映射，就是硬删除。硬删除在删除映射的同时还会删除文件对应的文件块数据。

2.1.3文件组织

允许接入的Web应用服务器，它对于每个文件都会附于一个特殊的组织方式，这个组织方式我们可以看作是文件的组织路径。这个文件的组织路径和文件的实际路径是无关的，文件的实际路径是文件在LXPFS系统中的实际保存的路径。而文件的组织路径是文件在Web服务系统中展示的位置，这个展示的位置有可能是某个模块的附件，也有可能就是某个显示的目录。在每次写入数据也就是上传文件的时候，上传请求包含文件在Web应用系统的组织路径，这个路径是以字符串的方式保存的。如果Web应用系统允许让LXPFS文件系统查看和运维，那么就会传入上传文件的组织路径。如果Web应用系统想要向LXPFS文件系统隐藏文件的组织路径，可以自己维护一张组织路径和路径ID的映射表，而只传入文件的路径ID即可。

LXPFS基于路径ID提供了一个文件版本的功能，如果写入的文件与应用系统已保存的文件的路径ID相同，并且文件名也相同，就判定为存在文件版本问题。每个文件版本被赋予一个文件版本序号。

2.2Tasknode

Tasknode节点主要是用于处理数据的存储，以及管理数据存储的信息。这部分功能被设计成一个进程，可以这么说一个实例进程即实现一个Tasknode的全部功能。尽管如此一台运行Linux系统的机器Tasknode可以同时运行多个实例进程，最简易的部署时一台机器上运行一个实例进程。为了满足高并发，每个实例进程维护着一个可配置线程数量的线程池和一个动态扩展的任务队列。在这些线程中有一个比较特殊，它专门接收任务，然后把接收的任务放在实例进程的任务队列里等待被线程池里的其他线程处理。任务队列是共享的，因此线程之间对资源有竞争，我们使用了Linux的线程同步方法，所以这些线程是线程安全的。我们采用生产者和消费者的模式来处理任务，这个专门接收任务的线程就是我们的生产者，其他线程取任务则是消费者。消费者线程在任务队列为空时闲置等待，当生产者线将得任务放入任务队列，进程就安排线程池里的闲置线程取任务进行处理。当线程池里的线程都处于满负荷运行，任务就会在任务队列里，等待消费者线程处理。总之，只要任务队列不为空，进程都为安排消费者线程来进行处理，具体可参考图5。

高并发性还并不只是使用多线程多任务实现的，还可以根据需要动态地扩展多实例进程处理，正如之前我们所说，可以在机器上运行多个实例进程。为了避免网络数据阻塞，我们还使用了事件轮询接口，当然我们的网络数据基本都是及时通讯的，很少出现阻塞的情况。

在一台机器上运行多个实例进程，一方面可以处理高并发，另一方面也可以实现高可用性。当一个实例进程因为意外或者未知错误挂死时，服务器依然能够正常地处理数据存储的请求。当然我们后续还会加入很多容错机制，如果可能我们还将实现实例进程挂死现场保护机制，即在实例进程挂死后，它的任务队列可以被保护起来，然后让其他的实例进程继续进行处理。

除此之外，我们也在每个服务器上部署实现了一个后台运行的维护进程。它的工作主要是维护机器上多个实例进程的正常运行，Linux系统不能随意关闭这些实例进程。Linux中每个进程都对应一个唯一的pid，实例进程挂死时，维护进程就会收到一个消息，通过消息可以获得挂死的进程的pid，然后维护进程再使用进程表里的进程参数启动该实例进程。因此即使这些实例进程被意外关闭，或者因为未知错误意外挂死，它们依然能够被维护进程自启动。

2.3Dispatchnode

Dispatchnode主要是分发存储数据和调度任务，这种分发和调度是基于一定的综合考量，目的是为了更高效、更合理的存储数据和执行任务。

Dispatchnode维护着多张数据参数表，根据这些参数表，Dispatchnode的实例进程获取参数，然后应用于负载均衡的算法。应用的每个访问请求，都会经过Dispatchnode。Dispatchnode在接收到请求信息后，会解析请求数据，根据请求数据进行负载均衡计算，最后有效地派发任务给Tasknode，如图6所示。

Dispatchnode的工作内容可以抽象为以下几个部分：

a.验证访问请求的IP是否已经注册；

b.解析访问请求数据包，获取访问操作方式、操作对象以及其他相关信息；

c.利用心跳机制，获取集群中目标节点服务器的负载参数，计算分析这些参数，获取最适合委派任务的目标节点位置；

d.使用操作对象文件的MD5值索引文件，找到文件所在目标节点服务器实现秒传，否则将任务派发给最适合的目标节点。

2.4心跳机制

集群的服务器之间是通过网络来相互沟通的，controller服务器管理着其他所有的worker服务器。因此Dispatchnode会定时地例行检测Tasknode是否运行正常以及运行情况。每个Tasknode节点周期性地向Dispatchnode发送心跳信号，心跳信号里包含有一些用于负载均衡策略的重要参数值。Dispatchnode也可以主动向Tasknode发送一个检测信号。Tasknode收到这个信号就会收集自己的运行情况，统计汇总任务队列的任务量、CPU和内存等服务器的负载参数，然后发送给Dispatchnode。Dispatchnode在获取这些数据后，会先保存再做统计分析，最后应用于负载均衡策略。事实上网路中断、worker服务器意外挂死等因素都会导致某一部分Tasknode跟Dispatchnode断联，Dispatchnode通过心跳机制来判断这一情况。对无法接收到心跳信号的Tasknode，Dispatchnode会将其标记为宕机状态，不会再将新的工作任务派发给它们。此时存储于判定为宕机的Tasknode上的所有数据将失效，但是LXPFS集群使用一系列的高可用性措施，保证了即使出现部分Tasknode宕机，系统的数据依然能够完备，系统依然运行正常，具体参考数据安全和文件存储小节。

2.5负载均衡

在对Tasknode进行部署的时候，一般都会配置它的警戒线和临界点。LXPFS集群中所有的数据都保存在这些Tasknode上，如何合理保存这些文件数据？我们的原则是尽量使集群中每个Tasknode的负荷趋于平等。在LXPFS系统运行开始时，Dispatchnode记录每个Tasknode的警戒线和临界点，即使后来某个Tasknode的这些参数值改变，Dispatchnode也可以通过心跳机制获取得到。Dispatchnode是起到一个调度任务的作用，所以负载均衡在此处实现。

如果某些Tasknode节点上的空闲空间较富余而低于设定的临界点，按照负载均衡策略系统就会自动地将数据从集群中储存空间紧张或者占用较大的Tasknode移动到其他空闲的Tasknode。如果某些Tasknode在某个时刻任务队列的任务量较大，内存和CPU使用率极高，Dispatchnode在调度任务时会尽量将任务派发给负荷较小的Tasknode。当然Dispatchnode在派发任务时，就会出于均衡的考虑，尽量把任务较多地派发给性能较高负荷较轻的Tasknode。只是可能某些情况导致Tasknode不能正常进行任务工作，导致任务队列堆积，从而造成负荷增大，这个时候Dispatchnode又会起到再次均衡的作用。

实际运行过程中，这种均衡需要考虑的维度是多维的。可能有些维度还存在着非此即彼的情况，所以在制定负载均衡策略时我们会出于综合的考虑优先选择某个维度，不过我们保持集群中所有Tasknode的尽量均衡的原则是不变的。

2.6安全

在保障LXPFS系统正常运行的同时，其安全也是十分重要的。基于安全有两方面的考虑，一是要保障数据不外泄，二是数据的完好性。

2.6.1网络安全

LXPFS系统设计的主要目的就为了降低多个Web应用服务系统的文件管理模块的开发难度和减小其开发周期，并且统一它们的文件管理功能，使之便于维护。LXPFS系统允许多个Web应用服务系统接入，在接入之前我们希望每个Web应用服务系统首先完成注册。每个Web应用服务器一旦开启就不会关闭，而它们的IP和网卡的物理地址是固定的。在它们接入LXPFS系统之前，需要先提供Web应用服务系统所部署的服务器的IP以及网卡的物理地址等信息，由LXPFS系统管理人员根据这些信息完成系统接入的注册工作。一旦注册，我们则认为来此这台机器的数据是安全的，是网络安全的，允许接入并为之提供服务。否则，则认为是不安全，不给于提供服务。数据访问时，应用需要发送访问请求给Dispatchnode，也就是controller服务器。在Dispatchnode会拦截访问请求并验证请求的来源，如果来源安全，则允许访问，否则拒绝访问。

其次，LXPFS文件存储系统对于文件不做任何的权限控制，所有的对于文件访问的权限控制都交还接入的Web应用服务系统。LXPFS只对接入的Web应用服务系统提供数据的写入、读取和删除的服务，至于这些文件能被Web应用服务系统中的哪些用户所使用和访问，完全是由它们进行权限控制处理的。最后在数据存储一节中，我们知道，LXPFS对每个接入的系统的数据都做了隔离。

2.7动态扩展worker

原有的LXPFS集群运行一定时间后，随着存储的文件越来越多，集群容量出现不足，此时需要对LXPFS集群扩容。或者使用的人越来越多，对LXPFS集群的并发性有更高的要求，这就亟待需要对LXPFS集群进行扩展。由于worker与controller之间使用心跳机制通信，如果系统扩展，只需要将相应数量的worker服务器部署好应用程序启动即可。这些worker服务器会向controller进行心跳汇报。controller接收到这些新worker服务器的心跳汇报，会自动完成worker在LXPFS系统中注册工作。注册完成后，LXPFS集群就实现了一次新的扩展，不需要重启系统就实现扩展的方式就是动态扩展。对于扩展新加入的worker服务器，将从多方面极大地减少LXPFS集群的负荷。新worker服务器其存储空间会相比其他的worker服务器要富余很多，此时LXPFS系统会根据动态负载均衡的策略，来将存储空间比较紧张的worker服务器的数据向这些新加入的worker服务器移动。为了避免数据转移在LXPFS集群负载大的时段进行，我们一般可以制定工作计划在某个时段来移动数据。

本发明是通过如下技术方案来实现的：

LXPFS集群分布式文件存储系统，本发明特征在于，采用LXPFS集群给应用提供访问方法，通过封装好的JS API访问LXPFS中的文件；访问LXPFS文件的方式分为三种：读、写和删除；在前端实现了访问LXPFS文件的组件，在Web应用开发中，只需要生成一个组件，调用相应的接口就能实现访问；系统采用主从模式的架构，由一个Dispatchnode和一个及以上的Tasknode组成；Dispatchnode是一个controller服务器，负责调配所有文件的存储以及处理并转发客户端的请求，Tasknode是在每节点设一个，负责管理它所在节点上的存储和响应客户端的请求；上传文件是将数据写入LXPFS集群的Tasknode中，下载文件则是读取Tasknode文件数据。

Dispatchnode的工作内容分为以下几个部分：

a.验证访问请求的IP是否已经注册；

每个文件块在写入前，系统都会记录这个文件块的MD5值，作为它的有效性检查的依据；如果保存在系统上的某个文件块计算得到的MD5值与记录的MD5值无法对应，那么说明此文件块内容被修改，其将被视为无效。

在系统运行开始时，Dispatchnode记录每个Tasknode的警戒线和临界点，即使后来某个Tasknode的这些参数值改变，Dispatchnode也可以通过心跳机制获取得到。

上传模块服务被封装成一个实体类QFileUpload，每个QFileUpload实体类中维护着一个上传队列，上传之前需要先选择本地文件，选择的一个本地文件将被封装成一个上传任务对象，并被自动添加到上传任务队列里；上传任务对象随机产生一个唯一的ID值作为文件ID，还会计算生成文件的MD5值，并保存了上传文件的相关信息和上传信息；添加上传任务队列完成后即可进行上传，由于添加文件的MD5计算是异步的，所以在上传时有些比较大的文件有可能还没有获得MD5值，这时上传服务组件会自动获取已经数据准备完成得上传任务，然后依次执行。

下载、删除模块服务和上传模块服务的实现思路是一致的，文件以分片的方式进行上传，分割后的文件块被分散保存在LXPFS集群的Tasknode上；Tasknode的任务进程实例在接收下载请求时，会根据文件共享池里的映射关系表索引文件块，并把这些文件块拼接形成一个完整的文件以支持组件下载。

当用户或应用程序删除某个文件时，LXPFS集群会先检测这个文件在共享池里是否还在其他的映射；如果存在即被判断为软删除，那么只是删除用户所属的那条记录和映射；要是文件不存在其他的映射，就是硬删除，硬删除在删除映射的同时还会删除文件对应的文件块数据。

本发明中，Tasknode分为活动节点和备用节点，controller服务器也分为活动节点和备用节点。

本发明中，文件以分片的方式进行上传后，分割后的文件块由一个UUID值标识，这个值即为文件块的ID，且分割后的文件块是有序的。

本发明中，当网络中断或上传错的原因导致文件上传意外中断时会断点续传，即文件再次上传不需要从文件的文件头开始进行上传，而是从文件上传中断时的断点位置开始上传。

本发明中，controller服务器和Tasknode能相互转换。

本发明所述心跳机制是指：每个Tasknode周期性地向Dispatchnode发送心跳信号，心跳信号里包含有一些用于负载均衡策略的参数值；Dispatchnode也可以主动向Tasknode发送一个检测信号，Tasknode收到这个信号就会收集自己的运行情况，统计汇总任务队列的任务量、CPU和内存等服务器的负载参数，然后发送给Dispatchnode，Dispatchnode在获取这些数据后，会先保存再做统计分析，最后应用于负载均衡策略。

如果Tasknode节点上的空闲空间较富余而低于设定的临界点，按照负载均衡策略系统就会自动地将数据从集群中储存空间紧张或者占用较大的Tasknode移动到其他空闲的Tasknode；如果Tasknode在某个时刻任务队列的任务量较大，内存和CPU使用率极高，Dispatchnode在调度任务时会尽量将任务派发给负荷较小的Tasknode。

数据访问时，应用需要发送访问请求给Dispatchnode，在Dispatchnode会拦截访问请求并验证请求的来源，如果来源安全，则允许访问，否则拒绝访问。

该系统能进行动态扩展，具体为：由于Tasknode与controller服务器之间使用心跳机制通信，系统扩展时只需要将Tasknode下的worker服务器部署好应用程序启动即可；这些worker服务器会向controller服务器进行心跳汇报；controller服务器接收到这些新worker服务器的心跳汇报，会自动完成worker服务器在系统中的注册工作；注册完成后，LXPFS集群就实现了一次新的扩展而不需要重启系统。

本发明具有以下有益效果：

1、LXPFS统一管理多应用的文件，扩大了文件共享池的范围，增加了秒传的机率，使上传效率有很大提高，同时也降低了Web应用中的文件管理的运维成本。

2、支持高可用性，采用特别的文件存储策略，具体如下：一个文件的所属文件块被分散在集群中的Tasknode；一个文件一定存在多个备份，并且这些文件备份也以文件块的方式分散存储在集群的Tasknode上；这些备份的存储算法遵从如下规则：保证任意一个Tasknode上的所有文件数据，在其他Tasknode上至少存在一个这些文件的完整完好备份。

3、保障数据的有效性：LXPFS会对文件块进行有效性检查。每个文件块在写入前，系统都会记录这个文件块的MD5值，作为它的有效性检查的依据。如果保存在系统上的某个文件块计算得到的MD5值与记录的MD5值无法对应，那么说明此文件块内容被修改，其将被视为无效。

4、断点续传：当网络中断、上传错误等原因导致文件上传意外中断时，文件再次上传不需要从文件的文件头开始进行上传，而是从文件上传中断时的断点位置开始上传的操作。

5、动态扩展worker：由于worker与controller之间使用心跳机制通信，如果系统扩展，只需要将相应数量的worker服务器部署好应用程序启动即可。这些worker服务器会向controller进行心跳汇报。controller接收到这些新worker服务器的心跳汇报，会自动完成worker在LXPFS系统中注册工作。注册完成后，LXPFS集群就实现了一次新的扩展。

附图说明

图1为本发明中文件分割的示意图；

图2为本发明中文件实现秒传的示意图；

图3为本发明的架构示意图；

图4为本发明中文件存储结构示意图；

图5为本发明实例进程内部实现图；

图6为LXPFS分布式文件管理系统。

具体实施方式

见图1-图6，LXPFS集群分布式文件存储系统，本发明特征在于，采用LXPFS集群给应用提供访问方法，通过封装好的JS API访问LXPFS中的文件；访问LXPFS文件的方式分为三种：读、写和删除；在前端实现了访问LXPFS文件的组件，在Web应用开发中，只需要生成一个组件，调用相应的接口就能实现访问；系统采用主从模式的架构，由一个Dispatchnode和一个及以上的Tasknode组成；Dispatchnode是一个controller服务器，负责调配所有文件的存储以及处理并转发客户端的请求，Tasknode是在每节点设一个，负责管理它所在节点上的存储和响应客户端的请求；上传文件是将数据写入LXPFS集群的Tasknode中，下载文件则是读取Tasknode文件数据。

Dispatchnode的工作内容分为以下几个部分：

a.验证访问请求的IP是否已经注册；

本发明中，controller服务器和Tasknode能相互转换。

Claims

1.LXPFS集群分布式文件存储系统，其特征在于，采用LXPFS集群给应用提供访问方法，通过封装好的JS API访问LXPFS中的文件；访问LXPFS文件的方式分为三种：读、写和删除；在前端实现了访问LXPFS文件的组件，在Web应用开发中，只需要生成一个组件，调用相应的接口就能实现访问；该系统采用主从模式的架构，由一个Dispatchnode和一个及以上的Tasknode组成；Dispatchnode是一个controller服务器，负责调配所有文件的存储以及处理并转发客户端的请求，Tasknode是在每节点设一个，负责管理它所在节点上的存储和响应客户端的请求；上传文件是将数据写入LXPFS集群的Tasknode中，下载文件则是读取Tasknode文件数据；

Dispatchnode的工作内容分为以下几个部分：

a.验证访问请求的IP是否已经注册；

d.使用操作对象文件的MD5值索引文件，找到文件所在目标节点服务器实现秒传，否则将任务派发给最适合的目标节点；

每个文件块在写入前，系统都会记录这个文件块的MD5值，作为它的有效性检查的依据；如果保存在系统上的某个文件块计算得到的MD5值与记录的MD5值无法对应，那么说明此文件块内容被修改，其将被视为无效；

在系统运行开始时，Dispatchnode记录每个Tasknode的警戒线和临界点，即使后来某个Tasknode的这些参数值改变，Dispatchnode也可以通过心跳机制获取得到；

上传模块服务被封装成一个实体类QFileUpload，每个QFileUpload实体类中维护着一个上传队列，上传之前需要先选择本地文件，选择的一个本地文件将被封装成一个上传任务对象，并被自动添加到上传任务队列里；上传任务对象随机产生一个唯一的ID值作为文件ID，还会计算生成文件的MD5值，并保存了上传文件的相关信息和上传信息；添加上传任务队列完成后即可进行上传，由于添加文件的MD5计算是异步的，所以在上传时有些比较大的文件有可能还没有获得MD5值，这时上传服务组件会自动获取已经数据准备完成得上传任务，然后依次执行；

下载、删除模块服务和上传模块服务的实现思路一致，文件以分片的方式进行上传，分割后的文件块被分散保存在LXPFS集群的Tasknode上；Tasknode的任务进程实例在接收下载请求时，会根据文件共享池里的映射关系表索引文件块，并把这些文件块拼接形成一个完整的文件以支持组件下载；

2.根据权利要求1所述的LXPFS集群分布式文件存储系统，其特征在于：Tasknode分为活动节点和备用节点，controller服务器也分为活动节点和备用节点。

3.根据权利要求1所述的LXPFS集群分布式文件存储系统，其特征在于：文件以分片的方式进行上传后，分割后的文件块由一个UUID值标识，这个值即为文件块的ID，且分割后的文件块是有序的。

4.根据权利要求1所述的LXPFS集群分布式文件存储系统，其特征在于：当网络中断或上传错的原因导致文件上传意外中断时会断点续传，即文件再次上传不需要从文件的文件头开始进行上传，而是从文件上传中断时的断点位置开始上传。

5.根据权利要求1所述的LXPFS集群分布式文件存储系统，其特征在于：controller服务器和Tasknode能相互转换。

6.根据权利要求1所述的LXPFS集群分布式文件存储系统，其特征在于：所述心跳机制是指：每个Tasknode周期性地向Dispatchnode发送心跳信号，心跳信号里包含有一些用于负载均衡策略的参数值；Dispatchnode也可以主动向Tasknode发送一个检测信号，Tasknode收到这个信号就会收集自己的运行情况，统计汇总任务队列的任务量、CPU和内存等服务器的负载参数，然后发送给Dispatchnode，Dispatchnode在获取这些数据后，会先保存再做统计分析，最后应用于负载均衡策略。

7.根据权利要求6所述的LXPFS集群分布式文件存储系统，其特征在于：如果Tasknode节点上的空闲空间较富余而低于设定的临界点，按照负载均衡策略系统就会自动地将数据从集群中储存空间紧张或者占用较大的Tasknode移动到其他空闲的Tasknode；如果Tasknode在某个时刻任务队列的任务量较大，内存和CPU使用率极高，Dispatchnode在调度任务时会尽量将任务派发给负荷较小的Tasknode。

8.根据权利要求1所述的LXPFS集群分布式文件存储系统，其特征在于：数据访问时，应用需要发送访问请求给Dispatchnode，在Dispatchnode会拦截访问请求并验证请求的来源，如果来源安全，则允许访问，否则拒绝访问。

9.根据权利要求1或6或7所述的LXPFS集群分布式文件存储系统，其特征在于，该系统能进行动态扩展，具体为：由于Tasknode与controller服务器之间使用心跳机制通信，系统扩展时只需要将Tasknode下的worker服务器部署好应用程序启动即可；这些worker服务器会向controller服务器进行心跳汇报；controller服务器接收到这些新worker服务器的心跳汇报，会自动完成worker服务器在系统中的注册工作；注册完成后，LXPFS集群就实现了一次新的扩展而不需要重启系统。