分布式存储冗余数据压缩方法和系统、客户端以及服务器与流程

文档序号:12068225阅读:395来源:国知局
分布式存储冗余数据压缩方法和系统、客户端以及服务器与流程

本发明涉及分布式计算领域,特别涉及一种分布式存储冗余数据压缩技术。



背景技术:

随着云计算相关技术在国内的广泛应用,基于廉价硬件的分布式存储在企业内外部数据处理中得到了广泛应用。

为保证分布式存储系统的整体可靠性,目前典型的分布式存储在底层普遍采用数据冗余存储的方式,例如将一份数据存储保留多个副本,且存储在不同的主机上,用空间置换安全性的提升。基于底层提供的数据安全保障,从应用层面就不再需要对数据做冗余处理。由于同样的文件存储了多份,分布式存储上应用层数据的冗余不仅会浪费计算资源和网络资源,也会增加整体维护成本,需要对应用层冗余数据进行必要的压缩处理。

目前分布式存储在应用层数据压缩,通常采用先上传、后剔重的方案,这一方案虽然也可以释放冗余数据占据的存储空间,但需要占用通信网络资源、且剔重操作集中在服务器端,会降低整体效能。对于大体积文件来说,这一缺陷尤其明显。



技术实现要素:

本发明实施例所要解决的一个技术问题是:先上传后剔重的应用层数据压缩方法存在的通信网络资源浪费以及整体效能比较低的问题。

根据本发明实施例的一个方面,提供了一种分布式存储冗余数据压缩方法,包括:客户端将上传数据打包成数据块;客户端生成数据块的数据块ID;客户端将数据块ID发送至服务器,使服务器判断该数 据块ID对应的数据块是否已经存在;客户端接收服务器返回的该数据块ID对应的数据块是否已经存在响应;根据响应,如果该数据块ID对应的数据块已存在于服务器,客户端开始下一个数据块的传输;如果该数据块ID对应的数据块不存在于服务器,客户端将该数据块ID对应的数据块传输至服务器。

根据本发明实施例的另一个方面,提供了一种分布式存储冗余数据压缩方法,包括:服务器端接收客户端发送的数据块ID;服务器端判断该数据块ID对应的数据块是否已经存在;如果数据块ID对应的数据块已经存在,则服务器端将数据块ID已存在的信息反馈给客户端;如果数据块ID对应的数据块不存在,则服务器端通知客户端上传数据块ID对应的数据块,并在接收到数据块ID对应的数据块后,将数据块ID记录到已上传数据块列表中。

根据本发明实施例的又一个方面,提供了一种用于分布式存储冗余数据压缩的客户端,包括:数据块打包单元,用于将上传数据打包成数据块;数据块ID生成单元,用于生成数据块的数据块ID;数据块ID发送单元,用于将数据块ID发送至服务器,使服务器判断该数据块ID对应的数据块是否已经存在;响应接收单元,用于接收服务器返回的该数据块ID对应的数据块是否已经存在响应;数据块传输单元,用于根据响应,如果该数据块ID对应的数据块已存在于服务器,则开始下一个数据块的传输;如果该数据块ID对应的数据块不存在于服务器,则将该数据块ID对应的数据块传输至服务器。

根据本发明实施例的再一个方面,提供了一种用于分布式存储冗余数据压缩的服务器,包括:数据块ID接收单元,用于接收客户端发送的数据块ID;数据块判断单元,用于判断该数据块ID对应的数据块是否已经存在;信息反馈单元,用于如果数据块ID对应的数据块已经存在,则信息反馈单元将数据块ID已存在的信息反馈给客户端;如果数据块ID对应的数据块不存在,则信息反馈单元通知客户端上传数据块ID对应的数据块;数据块接收单元,用于接收数据块ID对应的数据块;数据块ID记录单元,用于在接收到数据块ID对 应的数据块后,将数据块ID记录到已上传数据块列表中。

根据本发明实施例的另一个方面,提供了一种分布式存储冗余数据压缩系统,包括前述的客户端以及前述的服务器。

本发明至少具有以下优点:

通过客户端和服务器端的协作,目标数据在上传服务器前先判断是否在服务器端已经存在,如果存在则进行“预压缩”,从而实现了对应用层冗余数据的压缩,减少对通信网络资源和服务器端资源的占用,提升分布式存储的整体效能。

通过以下参照附图对本发明的示例性实施例的详细描述,本发明的其它特征及其优点将会变得清楚。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。

图1示出根据本发明分布式存储冗余数据压缩方法的一个实施例的流程示意图。

图2示出根据本发明分布式存储冗余数据压缩方法的另一个实施例的流程示意图。

图3示出根据本发明分布式存储冗余数据压缩方法的又一个实施例的流程示意图。

图4示出根据本发明分布式存储冗余数据压缩客户端的一个实施例的结构示意图。

图5示出根据本发明分布式存储冗余数据压缩客户端的另一个实施例的结构示意图。

图6示出根据本发明分布式存储冗余数据压缩服务器的一个实施例的结构示意图。

图7示出根据本发明分布式存储冗余数据压缩服务器的另一个实施例的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。以下对至少一个示例性实施例的描述实际上仅仅是说明性的,决不作为对本发明及其应用或使用的任何限制。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

下面参考图1描述本发明一个实施例的分布式存储冗余数据压缩方法。

图1示出根据本发明分布式存储冗余数据压缩方法的一个实施例的流程示意图。如图1所示,该实施例的方法包括:

步骤S102,客户端将上传数据打包成数据块。

一种示例性的方法,客户端根据数据打包策略将上传数据打包成数据块。以基于体积的策略为例,客户端比较上传数据的体积与数据打包策略中设定的数据块阈值体积X;若上传数据的体积小于或等于X,则将上传数据打包成一个数据块,并且打包数据块体积等于上传数据体积;若上传数据的体积大于X,则以体积X为单位对上传数据进行分割,分割后不足X的部分进行填充处理,分割后的各部分上传数据分别打包成一个数据块。

例如,客户端预先设定数据块阈值体积为100兆比特。客户端比较上传数据的体积与数据打包策略中设定的数据块阈值体积:若上传数据的体积小于或等于100兆比特,则将上传数据打包成一个数据块,并且打包数据块体积等于上传数据体积;若上传数据的体积大于100兆比特,则以体积100兆比特为单位对上传数据进行分割,分割后不足100兆比特的部分进行填充处理,分割后的各部分上传数据分别打包成一个数据块。此外,数据打包策略中,除了包括数据块分割填充 机制之外,还可以包括数据块完整性校验机制,以保证上传数据块的完整性。

步骤S104,客户端根据数据块ID生成策略生成数据块的数据块ID。

一种示例性的方法,客户端根据数据块体积生成数据块ID。客户端比较数据块的体积与数据块ID生成策略中设定的数据块阈值体积Y;若数据块的体积小于Y,则根据数据块所在的源文件名、文件后缀、文件大小以及文件修改时间中的至少一项信息生成数据块ID;若数据块的体积等于或大于Y,则对数据块采用消息摘要算法计算生成数据块ID。此外,若数据块体积小于等于Y,且数据块所在的源文件名、文件后缀、文件大小以及文件修改时间都相同,则也可以根据配置对数据块采用消息摘要算法计算生成数据块ID。

典型的数据块ID生成策略包括基于文件特征的数据块ID生成策略和基于消息摘要算法数据块ID生成策略。

基于文件特征的数据块ID生成策略计算简单,耗费的系统资源较少,但存在文件唯一性识别错误的风险。例如,对于小体积数据块,可以采用“文件名+文件后缀名+文件大小+修改时间”作为打包数据块的数据块ID。但是,如果有多个不同数据块的文件名、文件后缀名、文件大小以及修改时间均相同,那么依照基于文件特征的数据块ID生成策略所生成的数据块ID相同。

基于消息摘要算法的数据块ID生成策略可以避免文件唯一性识别错误的发生,但其计算复杂,耗费的系统资源较多,通常可以适用于大体积数据块。常见的基于消息摘要算法包括CRC32、MD5以及SHA算法。例如,通过MD5算法,不同的数据块可以生成唯一的数据块ID。

为了更好的提高分布式存储冗余数据压缩效率,可以将基于文件特征的数据块ID生成策略和基于消息摘要算法的数据块ID生成策略结合使用。例如,客户端预先设定数据块阈值体积100兆比特。然后,客户端比较数据块的体积与数据块ID生成策略中设定的数据块阈值 体积:若数据块体积小于100兆比特,则免去生成数据块ID的过程,直接采用“文件名+文件后缀名+文件大小+修改时间”作为打包数据块的数据块ID,并进行数据块上传;若数据块的体积大于100兆比特,则对数据块采用MD5算法计算生成数据块ID。

此外,若多个数据块体积小于100兆比特,且多个数据块所在的源文件名、文件后缀、文件大小以及文件修改时间都相同,则也对这些数据块采用消息摘要算法计算生成数据块ID。

步骤S106,客户端将数据块ID发送至服务器,相应的,服务器端接收客户端发送的数据块ID。

步骤S108,服务器判断该数据块ID对应的数据块是否已经存在。

一种示例性的判断方法,服务器可以根据已上传数据块列表记录的信息,判断列表中是否有请求上传的数据块ID,如果有,则说明该数据块已经上传过,可以执行步骤S110进行“预压缩”,如果没有,则说明该数据块还没有上传过,可以执行步骤S112进行数据块的上传。

步骤S110,如果服务器判断数据块ID对应的数据块已经存在,则服务器端将数据块ID已存在的信息反馈给客户端,客户端开始下一个数据块的传输;

步骤S112,如果服务器判断数据块ID对应的数据块不存在,则服务器端通知客户端上传数据块ID对应的数据块,客户端将该数据块ID对应的数据块传输至服务器,服务器在接收到数据块ID对应的数据块后,将数据块ID记录到已上传数据块列表中。

其中,已上传数据块列表中记录有已上传的数据块ID,还可以包括已上传数据块的存储位置信息等内容。

上述方法通过客户端和服务器端的协作,目标数据在上传服务器前先判断是否在服务器端已经存在,如果存在则进行“预压缩”,从而实现了对应用层冗余数据的压缩,并且减少对通信网络资源和服务器端资源的占用,提升分布式存储的整体效能。

图2示出根据本发明分布式存储冗余数据压缩方法的又一个实施例的流程示意图。如图2所示,在图1所示实施例的基础上,本实 施例的方法还包括:

步骤S201,在服务器配置数据块打包策略和数据块ID生成策略,客户端在对数据块进行打包之前,从服务器同步数据打包策略和数据块ID生成策略,由每个客户端对本地数据分别进行数据块打包和数据块ID的生成。

影响数据打包策略的参数可以包括数据体积、数据所有者、数据文件类别。基于同步参数,可以确定数据块的打包策略。服务器可以根据安全、性能和其他个性化要求,制定数据块ID计算算法,标识其唯一性。

通过客户端与服务器同步数据块打包策略,服务器可以处理具有统一规格的数据块,进一步提高了分布式存储的整体效能。此外,由于数据块ID是上传数据的唯一标识,服务器依据数据块ID对数据块作出是否需要“预压缩”的判断。如果服务器和客户端的数据块ID生成策略不同,那么有可能出现以下两种情形:不同客户端根据不同数据块生成策略生成相同数据块ID,服务器端会错误的执行预压缩;不同客户端根据相同数据块生成不同数据块ID,服务器端会错误的遗漏预压缩。因此,作为一个优选的方案,服务器和各个客户端的数据块ID生成策略相同,可以保证不同的数据块具有其对应的不同数据块ID。从而可以避免上述情形的发生,有助于预压缩高效地、准确地进行。

图3示出根据本发明分布式存储冗余数据压缩方法的又一个实施例的流程示意图。如图3所示,在图1所示实施例的基础上,本实施例的方法还包括:步骤S307,客户端将上传数据所属文件的文件名称发送至服务器,相应的,服务器接收客户端发送的上传数据块所属文件的文件名称。步骤S307可以与步骤S106同时执行。

在步骤S110或S112服务器接收到客户端上传的数据块之后,执行步骤S314,服务器建立文件名称与其数据块的连接。

在该实施例中,服务器端维护“文件名-数据块ID”的有序连接,一个文件名可以对应一个或更多个数据块ID。如果有多个数据块,需要按先后顺序存放。一个数据块ID可以对应一到多个文件名,当 数据块ID没有对应的文件名时,该数据块ID和数据块本身可以删除。基于文件名,根据数据块ID按次序组合其对应的数据块,则可以得到文件本身。

下面参考图4描述本发明一个实施例的分布式存储冗余数据压缩客户端的结构。

图4示出根据本发明分布式存储冗余数据压缩客户端的一个实施例的结构示意图。如图4所示,该实施例的客户端40包括:

数据块打包单元402,用于将上传数据打包成数据块;

数据块ID生成单元404,用于生成数据块的数据块ID;

数据块ID发送单元406,用于将数据块ID发送至服务器,使服务器判断该数据块ID对应的数据块是否已经存在;

响应接收单元408,用于接收服务器返回的该数据块ID对应的数据块是否已经存在响应;

数据块传输单元410,用于根据所述响应,如果该数据块ID对应的数据块已存在于服务器,则开始下一个数据块的传输;如果该数据块ID对应的数据块不存在于服务器,则将该数据块ID对应的数据块传输至服务器。

其中,数据块打包单元402用于根据数据打包策略配置将上传数据打包成数据块,例如,比较上传数据的体积与数据打包策略中设定的数据块阈值体积X;根据数据打包策略,若上传数据的体积小于或等于X,则将上传数据打包成一个数据块,并且打包数据块体积等于上传数据体积;若上传数据的体积大于X,则以体积X为单位对上传数据进行分割,分割后不足X的部分进行填充处理,分割后的各部分上传数据分别打包成一个数据块。

其中,数据块ID生成单元404用于根据数据块ID生成策略配置生成数据块的数据块ID,比较数据块的体积与数据块ID生成策略中设定的数据块阈值体积Y;根据数据块ID生成策略,若数据块的体积小于Y,则根据数据块所在的源文件名、文件后缀、文件大小以及文件修改时间中的至少一项信息生成数据块ID,或者对数据块采用消 息摘要算法计算生成数据块ID;若数据块的体积等于或大于Y,则对数据块采用消息摘要算法计算生成数据块ID。

其中,数据块ID生成单元404用于根据数据块ID生成策略,在数据块体积小于等于Y,且数据块所在的源文件名、文件后缀、文件大小以及文件修改时间都相同的情况下,则对数据块采用消息摘要算法计算生成数据块ID,以便检查其是否在服务器端已经存在。

下面参考图5描述本发明另一个实施例的分布式存储冗余数据压缩客户端的结构。

图5示出根据本发明分布式存储冗余数据压缩客户端的另一个实施例的结构示意图。如图5所示,该实施例的客户端50还包括:

包括策略同步单元501,用于从服务器同步数据打包策略和数据块ID生成策略。

文件名发送单元509,用于将上传数据所属文件的文件名称发送至服务器,以便服务器建立文件名称与其数据块的连接。

优选的,数据块ID发送单元406与文件名发送单元509可以同步执行。

下面参考图6描述本发明一个实施例的分布式存储冗余数据压缩服务器的结构。

图6示出根据本发明分布式存储冗余数据压缩服务器的一个实施例的结构示意图。如图6所示,该实施例的服务器60包括:

数据块ID接收单元602,用于接收客户端发送的数据块ID.

数据块判断单元604,用于判断该数据块ID对应的数据块是否已经存在。

信息反馈单元606,用于如果数据块ID对应的数据块已经存在,则信息反馈单元将数据块ID已存在的信息反馈给客户端;如果数据块ID对应的数据块不存在,则信息反馈单元通知客户端上传数据块ID对应的数据块。

数据块接收单元608,用于接收数据块ID对应的数据块。

数据块ID记录单元610,用于在接收到数据块ID对应的数据块 后,将数据块ID记录到已上传数据块列表中。

下面参考图7描述本发明另一个实施例的分布式存储冗余数据压缩服务器的结构。

图7示出根据本发明分布式存储冗余数据压缩服务器的另一个实施例的结构示意图。如图7所示,该实施例的服务器70还包括:

策略同步单元701,用于将数据打包策略和数据块ID生成策略同步到各客户端。

文件名接收单元709,用于接收客户端发送的上传数据块所属文件的文件名称,并建立文件名称与其数据块的连接。

优选的,数据块ID接收单元602与文件名接收单元709可以同步执行。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。

以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1