CN102982033A - 小文件的存储方法及*** - Google Patents

小文件的存储方法及*** Download PDF

Info

Publication number
CN102982033A
CN102982033A CN2011102600942A CN201110260094A CN102982033A CN 102982033 A CN102982033 A CN 102982033A CN 2011102600942 A CN2011102600942 A CN 2011102600942A CN 201110260094 A CN201110260094 A CN 201110260094A CN 102982033 A CN102982033 A CN 102982033A
Authority
CN
China
Prior art keywords
primary memory
data
client
storage
storer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN2011102600942A
Other languages
English (en)
Other versions
CN102982033B (zh
Inventor
曾毅
向灿
伍正勇
钟智将
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen City Cloud Fun Network Polytron Technologies Inc
Original Assignee
Shenzhen QVOD Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen QVOD Technology Co Ltd filed Critical Shenzhen QVOD Technology Co Ltd
Priority to CN201110260094.2A priority Critical patent/CN102982033B/zh
Publication of CN102982033A publication Critical patent/CN102982033A/zh
Application granted granted Critical
Publication of CN102982033B publication Critical patent/CN102982033B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明提供一种小文件的存储方法及***,其中,该方法包括:管理***接收来自客户端的存储请求;管理***根据存储请求,获取主存储器的IP地址;管理***将主存储器的IP地址发送给客户端;客户端与主存储器之间建立连接;主存储器接收并存储来自客户端的需要存储的数据,并断开客户端与主存储器建立的连接;管理***设置群组文件名,主存储器设置需要存储数据的文件名;主存储器根据群组文件名将多个本地存储数据进行归类处理;主存储器将归类处理后的本地存储数据备份到隶属存储器,并记录存储路径信息。通过本发明,可以提高IO性能。

Description

小文件的存储方法及***
技术领域
本发明涉及通信领域,具体地,涉及一种小文件的存储方法及***。
背景技术
目前,文件存储***已趋于成熟。申请号201010184752.X公开了一种文件存储方法,该方法通过用户在网页页面上提交文件、并上传至中转服务器,将文件从中转服务器通过远程服务存储到存储服务器。该存储服务器没有独立的单做用作全局管理调度的管理服务器,难易实现全面的全局调度。而且,客户端(Client)分别与主存储器、隶属存储器均建立了短连接,同时完成存储和备份,在主存储器以及隶属存储器均操作成功时,才反馈给Client操作成功消息,这属于同步备份,反馈时延较长。并且,存储器的存储用磁盘没有存储区分,这导致了访问的IO性能较差,从而可能导致寻址效率低。
也就是说,现有的文件存储***存在反馈时延较长、访问IO性能较差的问题。
发明内容
本发明实施例的主要目的在于提供一种小文件的存储方法及***,以解决现有技术中的文件存储***的反馈时延较长、访问IO性能较差的问题。
为了实现上述目的,本发明实施例提供一种小文件的存储方法,该方法包括:管理***接收来自客户端的存储请求;所述管理***根据所述的存储请求,获取主存储器的IP地址;所述管理***将所述主存储器的IP地址发送给所述客户端;所述客户端与所述主存储器之间建立连接;所述主存储器接收并存储来自所述客户端的需要存储的数据,并断开所述客户端与所述主存储器建立的连接;所述管理***设置群组文件名,所述主存储器设置所述需要存储数据的文件名;所述主存储器根据所述群组文件名将多个本地存储数据进行归类处理;所述主存储器将归类处理后的本地存储数据备份到隶属存储器,并记录存储路径信息。
具体地,在获取主存储器的IP地址之前,上述的方法还包括:所述管理***在存储器组中选择一个存储器为主存储器,其余存储器为隶属存储器,其中,所述的存储器组至少包括两个存储器;所述管理***将选择的主存储器的信息发送给选择的隶属存储器。
优选地,在所述管理***将选择的主存储器的信息发送给选择的隶属存储器之后,所述的方法还包括:当所述的主存储器停机时,所述管理***在所述存储器组中重新选择新的主存储器。
优选地,在所述主存储器将归类处理后的本地存储数据备份到隶属存储器并记录存储路径信息之后,所述的方法还包括:所述主存储器接收所述的客户端对存储数据的编辑操作;所述主存储器对编辑后的数据进行保存并备份到相应的隶属存储器。
本发明实施例还提供一种小文件的存储***,该***包括:管理***、客户端、以及包括主存储器和隶属存储器的存储器组,其中,所述的管理***包括:存储请求接收单元,用于接收来自客户端的存储请求;IP地址获取单元,用于根据所述的存储请求获取主存储器的IP地址;IP地址发送单元,用于将所述主存储器的IP地址发送给所述客户端;群组文件名设置单元,用于设置所述主存储器存储数据的群组文件名;所述主存储器包括:数据接收单元,用于接收并存储来自所述客户端的需要存储的数据;通信链路管理单元,用于建立或断开所述客户端与所述主存储器之间的通信链路;文件名设置单元,用于设置所述需要存储数据的文件名;数据归类处理单元,用于根据所述管理***设置的群组文件名将多个本地存储数据进行归类处理;数据备份单元,用于将归类处理后的本地存储数据备份到隶属存储器,并记录存储路径信息。
具体地,所述的管理***还包括:隶属关系选择单元,用于在存储器组中选择一个存储器为主存储器,其余存储器为隶属存储器;隶属信息发送单元,用于将选择的主存储器的信息发送给选择的隶属存储器。
优选地,所述的隶属关系选择单元还用于:当所述的主存储器停机时,在所述存储器组中重新选择新的主存储器。
优选地,所述主存储器还包括:编辑操作接收单元,用于接收所述的客户端对存储数据的编辑操作;所述的数据备份单元还用于对编辑后的数据进行保存并备份到相应的隶属存储器。
借助于上述技术方案至少之一,通过管理***将主存储器的IP地址发送给客户端,使得客户端与主存储器之间可以直接连接进行数据的存储,且,备份操作也是在主存储器和隶属存储器之间实现,从而可以克服现有技术中的反馈时延较长、访问IO性能较差的问题,提高IO性能。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1是根据本发明实施例的小文件存储方法的流程图;
图2是根据本发明实施例的管理***与多个存储器之间的连接关系示意图;
图3是根据本发明实施例的小文件存储***结构示意图;
图4、5分别是Master、Slave执行数据备份时的流程图;
图6是Block文件的逻辑结构示意图;
图7、8分别是Master、Slave处理同一个Block的流程图;
图9是根据本发明实施例的小文件存储***的结构框图;
图10是根据本发明实施例的管理***的结构框图;
图11是根据本发明实施例的小文件存储***的架构示意图;
图12是根据本发明实施例的上传文件数据流程;
图13是根据本发明实施例的查阅文件的流程图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例提供一种小文件的存储方法和***。以下结合附图对本发明进行详细说明。
实施例一
本发明实施例提供一种小文件的存储方法,如图1所示,该方法包括:
步骤101,管理***接收来自客户端的存储请求;
步骤102,管理***根据存储请求,获取主存储器的IP地址;
步骤103,管理***将主存储器的IP地址发送给客户端;
步骤104,客户端与主存储器之间建立连接;
步骤105,主存储器接收并存储来自客户端的需要存储的数据,之后断开客户端与主存储器建立的连接;
步骤106,管理***设置群组文件名,主存储器设置需要存储数据的文件名;
步骤107,主存储器根据管理***设置的群组文件名将多个本地存储数据进行归类处理:
步骤108,主存储器将归类处理后的本地存储数据备份到隶属存储器,并记录存储路径信息。
由以上描述可知,通过管理***将主存储器的IP地址发送给客户端,使得客户端与主存储器之间可以直接连接进行数据的存储,且,备份操作也是在主存储器和隶属存储器之间实现,无需像现有技术中的同步备份,因此,通过本发明实施例可以克服现有技术中的反馈时延较长、访问IO性能较差的问题,提高IO性能。
在实际操作中,在获取主存储器的IP地址之前,管理***需要在存储器组中选择一个存储器为主存储器,其余存储器为隶属存储器,其中,存储器组至少包括两个存储器;然后管理***将选择的主存储器的信息发送给选择的隶属存储器。
图2示出了管理***(也可以称为管理服务器,NameServer)与多个存储器(DataServer)之间的连接关系,如图2所示,以两台DataServer(简称为DS)为一存储器组(group),布置多组为一集群,每一组由唯一的ID号标识,在同一组内DataServer有不同的机器号标识。DataServer在启动时,向NameServer注册,提供ID号和机器号,NameServer选择一台DataServer作为主存储器(Master),其余的为隶属存储器(Slave)。
在备份过程中,由NameServer提供给Master相应的Slave信息。当Master因故障停机,那么由NameServer自动选择Slave作为Master继续提供服务,支持Master与Slave的自动切换,避免人工干预,减少服务停止时间以及人为出错风险。即,当主存储器停机时,管理***在存储器组中重新选择新的主存储器。在Master和Slave自动切换时,为避免数据重复备份,采用以下策略:制定Master与Slave的通信协议,Master与Slave相互通信实时同步备份的位置,记录相应的位置至本地文件。
在具体实施过程中,主存储器还可以接收客户端对存储数据的编辑操作,当客户端完成编辑操作后,主存储器对编辑后的数据进行保存并备份到相应的隶属存储器,以便后续的查阅。该编辑操作可以包括查询、修改等操作。
以下给出一个实例。
图3是小文件存储***结构示意图,如图3所示,***中的每组MasterServer/SlaveServer均需向管理服务器(NameServer,简称为Ns)注册后才能发挥***存储的作用。注册后的若干组MasterServer/SlaveServer,每个MasterServer以及SlaveServer均通过心跳通信的方式与管理服务器保持长连接,使得MasterServer/SlaveServer均受到管理服务器的监控。
当用户需要上传数据时,客户端向管理服务器发起上传请求,管理服务器选择合适主存储器,并将该主存储器的连接信息IP和Port发送给用客户端,客户端根据连接信息与该主存储器建立短连接。连接建立后,主存储器向管理服务器发出Block分配请求,该Block即上述的群组文件名,由管理服务器设定。管理服务器的Block分配模块响应请求并分配Block id给主存储器。同时,管理服务器在关系列表模块中建立Block id和DS的对应关系。DS在收到分配的Block id后,开始和用户进行上传小文件步骤。在实际操作中,主存储器会根据自身情况选择是否需要向管理服务器发送Block分配请求。如果主存储器当前大文件(Block)写满了,那么主存储器向管理服务器发送Block分配请求,Block分配请求只是分配可用的Block id,实际存取的大文件名由存储器决定,管理服务器管理Block id号,使得全局唯一,避免重复。
主存储器将接收到的大量小文件(实际数据文件)合并成为一个大文件(Block)。每一个Block拥有集群内唯一的标识Block id。Block id由NameServer指定和命名,NameServer维护Block和DataServer的对应关系,以及DataServer相关信息,包括DataServer加入与退出。数据存储在DataServer,各组DataServer之间的数据是相互独立的,同一组内的数据是一样的。
每一个小文件在***中对应于唯一的文件名(Filename),在一个Block内有唯一的Fileid。这样通过Block id和File id就可以定位到实际的文件。上述Filename就是由Block id、Fileid、文件类型以及应用ID号编码生成。
在用户(Client)上传数据时,只和主存储器建立短连接,不和隶属存储器建立直接连接。在用户和主存储器通讯完成并反馈给用户操作成功消息后即断开。
当用户需要进行查询或删除操作时,客户端向管理服务器发起查询或删除请求,管理服务器根据查询或删除的对象ID,从关系列表模块中找到该对象ID对应的Block id以及对应的DataServer。管理服务器将DataServer的连接信息IP和Port发送给用户,用户根据连接信息与管理服务器确定的DataServer建立短连接,连接后在具体的Block内进行相应的查询或删除操作。
主存储器在设定的时间间隔或者设定文件修改操作量条件满足时,在主存储器和隶属存储器之间完成异步备份作业。NameServer和DataServer都有热备份存在,当NameServer或DataServer不可用,相应的热备就可以充当NameServer或DataServer使用。
上述数据备份采用的是Master-Slave架构,Master对数据更新操作时,如执行完上传或删除操作时,将更新信息串行化写入本地log文件。以每一组为单位,在同组内从Master异步备份数据至Slave。Master根据log文件,将数据操作发送至Slave,Slave记录当前备份所处位置。
备份的数据分为两部分:实际文件数据和信息数据,以下分别对这两部分数据的备份进行描述。
(一)对实际文件数据的备份
制定Master与Slave的通信协议,Master与Slave相互通信实时同步备份的位置,记录相应的位置至本地文件log1。同时,Slave记录作为Slave时,同步数据所处的位置至本地文件log2。当Slave切换成Master时,新的Slave向新的Master发送数据同步请求,新的Master根据log2记录的文件坐标,定位至相应的位置开始同步数据;如果没有发生Master与Slave切换,Slave就根据log1记录的文件坐标,向Master发送数据同步请求,Master根据Slave发送的文件坐标位置,定位到相应的位置同步数据。坐标位置表示为:文件名和偏移量。
具体地,Master开启一个线程,作为同步的Server端,Slave开启一个线程,作为Client端。Server和Client工作流程分别如下:
(1)Client端:
1)Client向Server发送数据同步请求,并告知当前数据所处的坐标位置(logName,logPos),如果发送请求失败,则休眠1秒钟,继续发送请求,如果成功,则进行至2);
2)Client等待接收Server发送指令和数据,如果成功进行至3);
3)解析指令,进行文件数据写入或删除操作,以及坐标位置更新操作,如果成功进行至4),否则返回至1);
4)将坐标位置写入本地文件,同时更新logName和logPos,返回至1)。
(2)Server端:
1)Server等待接收Client的同步请求,如果成功进行至2);
2)Server根据Client的坐标位置,定位到相应位置,如果有数据,就发送给Client,否则进行至5),如果成功发送数据则进行至3),失败则返回至1);
3)Server向Client发送数据到相应的坐标位置,成功则跳至4),否则返回至1);
4)更新坐标位置,返回至2);
5)检查是否要跳转至新的log文件,如果是,则更新坐标位置信息,并发送该信息给Client,然后返回至1)。
图4、5分别是Master、Slave执行数据备份时的流程图,如图4所示,Master的操作流程为:
步骤401,等待接收数据同步请求;
步骤402,根据坐标位置,定位至相应的位置;
步骤403,判断是否有未同步的数据,如果有,则进行步骤404,否则进行步骤405;
步骤404,发送数据给Client,即,发送数据给Slave,然后进行步骤406;
步骤405,检查是否需要转至新文件,如果是,更新坐标位置,并发送给Client;
步骤406,是否发送数据成功,如果是,则进行步骤407,否则返回至步骤401;
步骤407,发送新的坐标位置给Client;
步骤408,是否发送新的坐标位置成功,如果是,则进行步骤409,否则返回至步骤401;
步骤409,更新坐标位置。
如图5所示,Slave的操作流程为;
步骤501,根据坐标位置,发送数据同步请求;
步骤502,是否发送数据同步请求成功,如果是,则进行步骤503,否则进行步骤504;
步骤503,等待接收数据和指令;
步骤504,休眠1秒,并返回步骤501;
步骤505,是否有数据,如果是,则进行步骤506,否则返回步骤501;
步骤506,接收数据,解析指令,执行相关操作;
步骤507,更新坐标位置信息,并写入本地文件。
由上述可知,Master根据Slave发送的坐标信息,将相对于该位置,做过更新操作的数据全部发送给Slave,直到没有数据可以发送;而Slave一直接收数据,直到数据到达,然后根据最新的坐标位置信息,向Master发送同步请求。如果数据同步不成功,那么坐标信息也不会更新,此时Slave会要求Master再一次发送该数据,直到成功。
(二)对信息数据的备份
信息数据备份针对每一个Block,在Master和Slave之间,维持同一个能分配使用的Fileid,保持实时的一致性,同时写入该File id至对应Block文件的头部,每个Block文件逻辑结构如图6所示,每一Block有一个8字节的Block head用于存放针对该Block能使用的下一个File id,在Block中,每一小文件都有一个32字节的file head,存放索引信息。
在***中可以建立一个Block索引数据库,用于存放每一个Block能分配使用的File id,在同一个Block中File id加1递增。Block每分配一个File id,那么就更新对应Block的数据库记录,同时写入Block文件头部,并且将该File id同步至Slave,更新Slave上对应的数据库记录和Block文件头部。如果同步File id至Slave,则保存该记录,等待重传。需要说明的是,在重传的记录中,每一个Block id只对应一条File id记录,并且该记录可能会被实时更新。
图7、8分别是Master、Slave处理同一个Block的流程图,如图7所示,Master的操作流程为:
步骤701,Block分配一个File id;
步骤702,将下一个可用的File id保存至相应的数据库、并写入Block头部;
步骤702,检测是否有需要重传的记录,如果是,则进行步骤704,否则,进行步骤706;
步骤704,是否重传成功,如果否,则进行步骤705,否则进行步骤706;
步骤705,留待下一次重传;
步骤706,删除重传成功的记录,并同步File id至Slave;
步骤707,是否同步成功,如果否,则进行步骤708,否则返回步骤701;
步骤708,保存和更新重传记录。
如图8所示,Slave的操作流程为:
步骤801,接收同步的Block id和file id;
步骤802,将Block id和file id保存至相应的数据库、写入Block头部,并返回步骤802。
实施例二
本发明实施例还提供一种小文件的存储***,如图9所示,该***包括:管理***1、客户端2、以及包括主存储器31和隶属存储器32的存储器组3,其中:
管理***1包括:
存储请求接收单元11,用于接收来自客户端的存储请求;
IP地址获取单元12,用于根据存储请求获取主存储器的IP地址;
IP地址发送单元13,用于将主存储器的IP地址发送给客户端;
群组文件名设置单元14,用于设置主存储器存储数据的群组文件名;
主存储器31包括:
数据接收单元311,用于接收并存储来自客户端的需要存储的数据;
文件名设置单元312,用于根据预定规则设置需要存储数据的文件名;
数据归类处理单元313,用于根据管理***设置的群组文件名将多个本地存储数据进行归类处理;
数据备份单元314,用于将归类处理后的本地存储数据备份到隶属存储器,并记录存储路径信息;
通信链路管理单元315,用于建立或断开客户端与主存储器之间的通信链路。
由以上描述可以看出,通过管理***将主存储器的IP地址发送给客户端,使得客户端与主存储器之间可以直接联系进行数据的存储,且,备份操作也是在主存储器和隶属存储器之间实现,无需像现有技术中的同步备份,因此,通过本发明实施例可以克服现有技术中的反馈时延较长、访问IO性能较差的问题,提高IO性能。
如图10所示,管理***1还包括:
隶属关系选择单元15,用于在存储器组中选择一个存储器为主存储器,其余存储器为隶属存储器;
隶属信息发送单元16,用于将选择的主存储器的信息发送给选择的隶属存储器。
当主存储器停机时,隶属关系选择单元14还用于在存储器组中重新选择新的主存储器。
上述主存储器31还包括:编辑操作接收单元,用于接收客户端对存储数据的编辑操作。相应地,数据备份单元314还用于对编辑后的数据进行保存并备份到相应的隶属存储器。
上述各单元具体的执行过程,可以参考上述实施例一中的描述,此处不再赘述。
为了更好的理解本发明实施例,以下结合图11详细描述本发明实施例。图11是该小文件存储***的架构示意图,如图11所示,小文件存储***(以下简称为kwfs)是一种分布式文件存储***,由三大部分组成:kwfs Client,kwfs NameSverver和kwfs DataServer。kwfs NameSverver为中心节点,作为整个小文件存储***的调度和控制中心,DataServer可以自由添加和移除,保证良好的可扩展性。同时,对应于若干DataServer,均设置SlaveServer,作为DataServer的备份。其中,DataServer和SlaveServer均与NameSverver建立采用心跳机制的长连接。
其中,NameSverver管理各DataServer有关信息,包括***信息、各DataServer服务器加入、退出等、以及管理各DataServer服务器Block id的创建,删除,负载等。
DataServer处理实际数据存储与读写,向NameServer报告服务器状态(负载,文件数等);维护Block id与文件File id关系(索引)数据存储位置、大小等。
图12是上传文件数据流程,如图12所示,当Client向NameSverver发出请求信息时,NameSverver查询本地由DataServer不断更新的索引目录并将具有被查文件数据的DataServer的IP地址和Port反馈给Client,Client再分别与DataServer建立数据通信连接,以保证NameSverver的正常运作减少传输压力。其中,该不断更新的索引目录(Master,Slave)DataServer在本地也保存。在完成上传之后,DataServer将Block状态更新到NameSverver,并向Client反馈操作结果,如包括文件名(Filename)。
文件名由Block id、File id、文件类型和应用id组成,采用base64(六位2进制表示)编码生成。如果使用8字节存储Block id,4字节存储File id,那么Filename的长度为16个字节。如:假设Block id为123456,File id为888那么kwfs文件名为:AAAAAAAB4kAAAAN4。如果需要标识文件类型,那么设定六位二进制组合表示文件类型(可以标识64种文件类型),那么kwfs文件名长度为17个字节。
在NameSverver上存储Block id和DataServer的对应关系,在DataServer存储Block id和File id以及文件在Block内的偏移量和文件长度的对应关系。
图13是查阅文件的流程图,如图13所示,Client根据Filename解码出Block id和File id(File id是相对于Block id的),然后定位到实际数据。
当需要删除文件时,首先是逻辑删除,即在DataServer上将相应的File id的信息移出至保存删除信息的数据库中,然后是物理删除,在特定的时间点,根据删除信息回收对应文件的磁盘空间,按序移动和合并Block中未删除的数据,修改相应File id的偏移量。
在备份策略上,可采用多写和单写备份方式:多写方式在一定程度上会影响Server的响应速度;单写则需要以日志的方式记录数据备份的时间点和状态,保证在备份过程中出现故障时,再次备份时不会丢失数据。在***实现过程中,可以根据实际情况选择合适的策略。
由以上描述可以看出,本发明实施例通过由NameSverver统一全局调股管理,扩展时直接增加Master DataServer/Slave DataServer组即可,实现对DataServer的统一全局管理调度,可扩展性好。该NameSverver的设置可完成Master与Slave自动切换,避免人工干预,也可以避免切换后数据重复备份,减少服务停止时间。且,Client只和Master DataServer建立短连接,直接通信完成并反馈给Client操作成功消息后即断开。Master DataServer在设定的时间间隔或者设定文件修改操作量条件满足时,和Slave DataServer之间完成异步备份作业。并且,由于若干DataServer的设置,使得整个小文件***的容错性增强,同时,NameSverver对Client的统一请求管理,和Client与NameSverver的通信方法,使得***的稳定性增强。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读取存储介质中,比如ROM/RAM、磁碟、光盘等。
以上所述的具体实施例,对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本发明的具体实施例而已,并不用于限定本发明的保护范围,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (8)

1.一种小文件的存储方法,其特征在于,所述的方法包括:
管理***接收来自客户端的存储请求;
所述管理***根据所述的存储请求,获取主存储器的IP地址;
所述管理***将所述主存储器的IP地址发送给所述客户端;
所述客户端与所述主存储器之间建立连接;
所述主存储器接收并存储来自所述客户端的需要存储的数据,并断开所述客户端与所述主存储器建立的连接;
所述管理***设置群组文件名,所述主存储器设置所述需要存储数据的文件名;
所述主存储器根据所述群组文件名将多个本地存储数据进行归类处理;
所述主存储器将归类处理后的本地存储数据备份到隶属存储器,并记录存储路径信息。
2.根据权利要求1所述的方法,其特征在于,在获取主存储器的IP地址之前,所述的方法还包括:
所述管理***在存储器组中选择一个存储器为主存储器,其余存储器为隶属存储器,其中,所述的存储器组至少包括两个存储器;
所述管理***将选择的主存储器的信息发送给选择的隶属存储器。
3.根据权利要求2所述的方法,其特征在于,在所述管理***将选择的主存储器的信息发送给选择的隶属存储器之后,所述的方法还包括:
当所述的主存储器停机时,所述管理***在所述存储器组中重新选择新的主存储器。
4.根据权利要求1所述的方法,其特征在于,在所述主存储器将归类处理后的本地存储数据备份到隶属存储器并记录存储路径信息之后,所述的方法还包括:
所述主存储器接收所述的客户端对存储数据的编辑操作;
所述主存储器对编辑后的数据进行保存并备份到相应的隶属存储器。
5.一种小文件的存储***,其特征在于,所述的***包括:管理***、客户端、以及包括主存储器和隶属存储器的存储器组,其中,
所述的管理***包括:
存储请求接收单元,用于接收来自客户端的存储请求;
IP地址获取单元,用于根据所述的存储请求获取主存储器的IP地址;
IP地址发送单元,用于将所述主存储器的IP地址发送给所述客户端;
群组文件名设置单元,用于设置所述主存储器存储数据的群组文件名;
所述主存储器包括:
数据接收单元,用于接收并存储来自所述客户端的需要存储的数据;
通信链路管理单元,用于建立或断开所述客户端与所述主存储器之间的通信链路;
文件名设置单元,用于设置所述需要存储数据的文件名;
数据归类处理单元,用于根据所述管理***设置的群组文件名将多个本地存储数据进行归类处理;
数据备份单元,用于将归类处理后的本地存储数据备份到隶属存储器,并记录存储路径信息。
6.根据权利要求5所述的***,其特征在于,所述的管理***还包括:
隶属关系选择单元,用于在存储器组中选择一个存储器为主存储器,其余存储器为隶属存储器;
隶属信息发送单元,用于将选择的主存储器的信息发送给选择的隶属存储器。
7.根据权利要求6所述的***,其特征在于,所述的隶属关系选择单元还用于:当所述的主存储器停机时,在所述存储器组中重新选择新的主存储器。
8.根据权利要求5所述的***,其特征在于,所述主存储器还包括:
编辑操作接收单元,用于接收所述的客户端对存储数据的编辑操作;
所述的数据备份单元还用于对编辑后的数据进行保存并备份到相应的隶属存储器。
CN201110260094.2A 2011-09-05 2011-09-05 小文件的存储方法及*** Expired - Fee Related CN102982033B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201110260094.2A CN102982033B (zh) 2011-09-05 2011-09-05 小文件的存储方法及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201110260094.2A CN102982033B (zh) 2011-09-05 2011-09-05 小文件的存储方法及***

Publications (2)

Publication Number Publication Date
CN102982033A true CN102982033A (zh) 2013-03-20
CN102982033B CN102982033B (zh) 2016-08-03

Family

ID=47856071

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201110260094.2A Expired - Fee Related CN102982033B (zh) 2011-09-05 2011-09-05 小文件的存储方法及***

Country Status (1)

Country Link
CN (1) CN102982033B (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103823846A (zh) * 2014-01-28 2014-05-28 浙江大学 一种基于图论的大数据存储及查询方法
CN110083306A (zh) * 2019-03-14 2019-08-02 南京时沃信息科技有限公司 一种分布式对象存储***及存储方法
CN111343502A (zh) * 2020-03-30 2020-06-26 招商局金融科技有限公司 视频处理方法、电子装置及计算机可读存储介质
CN111988419A (zh) * 2020-08-28 2020-11-24 深圳壹账通智能科技有限公司 文件上传方法、下载方法、装置、计算机设备和存储介质
CN115794733A (zh) * 2022-11-11 2023-03-14 南京维拓科技股份有限公司 一种工业设计中设计文档管理的方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080104083A1 (en) * 2006-10-31 2008-05-01 Procuri, Inc. Dynamic data access and storage
CN102023978A (zh) * 2009-09-15 2011-04-20 腾讯科技(深圳)有限公司 一种海量数据处理方法及***
CN102136003A (zh) * 2011-03-25 2011-07-27 上海交通大学 大规模分布式存储***

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080104083A1 (en) * 2006-10-31 2008-05-01 Procuri, Inc. Dynamic data access and storage
CN102023978A (zh) * 2009-09-15 2011-04-20 腾讯科技(深圳)有限公司 一种海量数据处理方法及***
CN102136003A (zh) * 2011-03-25 2011-07-27 上海交通大学 大规模分布式存储***

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103823846A (zh) * 2014-01-28 2014-05-28 浙江大学 一种基于图论的大数据存储及查询方法
CN110083306A (zh) * 2019-03-14 2019-08-02 南京时沃信息科技有限公司 一种分布式对象存储***及存储方法
CN111343502A (zh) * 2020-03-30 2020-06-26 招商局金融科技有限公司 视频处理方法、电子装置及计算机可读存储介质
CN111988419A (zh) * 2020-08-28 2020-11-24 深圳壹账通智能科技有限公司 文件上传方法、下载方法、装置、计算机设备和存储介质
CN115794733A (zh) * 2022-11-11 2023-03-14 南京维拓科技股份有限公司 一种工业设计中设计文档管理的方法

Also Published As

Publication number Publication date
CN102982033B (zh) 2016-08-03

Similar Documents

Publication Publication Date Title
CN103078927B (zh) 一种key-value数据分布式缓存***及其方法
CN103827723B (zh) 大规模存储***
US9424272B2 (en) Distributed file system using consensus nodes
AU2019236685A1 (en) Distributed file system using consensus nodes
CN102411639B (zh) 元数据的多副本存储管理方法和***
CN108964948A (zh) 主从服务***、主节点故障恢复方法及装置
CN101751415B (zh) 元数据服务***、元数据同步方法与写服务器更新方法
CN103905537A (zh) 分布式环境下管理工业实时数据存储的***
CN103207841A (zh) 基于键值对缓存的数据读写方法及装置
CN104202424B (zh) 一种使用软件架构扩展缓存的方法
CN102982033A (zh) 小文件的存储方法及***
CN103428288B (zh) 基于分区状态表和协调节点的副本同步方法
WO2016177231A1 (zh) 基于双主控的主备倒换方法及装置
CN113268472B (zh) 一种分布式数据存储***及方法
CN100530069C (zh) 一种非同质存储设备的虚拟化***及方法
CN101370027A (zh) 网络存储***、方法及应用服务器
CN102891894A (zh) 应用于服务器集群的缓存方法、缓存服务器及缓存***
CN105069152A (zh) 数据处理方法及装置
CN113010496A (zh) 一种数据迁移方法、装置、设备和存储介质
CN101552799A (zh) 媒体节点容错方法和装置
CN110807039A (zh) 一种云计算环境下数据一致性维护***及方法
CN103544081B (zh) 双元数据服务器的管理方法和装置
CN102541693A (zh) 数据的多副本存储管理方法和***
CN102624932A (zh) 基于索引的异地云数据同步方法
CN105323271B (zh) 一种云计算***以及云计算***的处理方法和装置

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
ASS Succession or assignment of patent right

Owner name: SHENZHEN TIANQU NETWORK TECHNOLOGY CO., LTD.

Free format text: FORMER OWNER: SHENZHEN KUAIBO TECHNOLOGY CO., LTD.

Effective date: 20141215

C41 Transfer of patent application or patent right or utility model
TA01 Transfer of patent application right

Effective date of registration: 20141215

Address after: 518057 Guangdong city of Shenzhen province Nanshan District south road six No. 6 7 storey building to Kelon

Applicant after: SHENZHEN TEEQEE NETWORK TECHNOLOGY Co.,Ltd.

Address before: 518057 Guangdong city of Shenzhen province Nanshan District Gao Xin Road No. 009 China Technology Development Institute Technology Park building three, 22 layers of A

Applicant before: SHENZHEN QVOD TECHNOLOGY Co.,Ltd.

C14 Grant of patent or utility model
GR01 Patent grant
CP03 Change of name, title or address

Address after: 518063 Nanshan District, Shenzhen, Guangdong, Guangdong Province, 9, No. 3, building No. 3, China Science and Technology Development Institute.

Patentee after: Shenzhen city cloud fun network Polytron Technologies Inc.

Address before: 518057 Guangdong city of Shenzhen province Nanshan District south road six No. 6 7 storey building to Kelon

Patentee before: SHENZHEN TEEQEE NETWORK TECHNOLOGY Co.,Ltd.

CP03 Change of name, title or address
CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20160803