CN107465744B - 数据下载控制方法及系统 - Google Patents

Abstract

本发明提供了数据下载控制方法及系统，涉及数据下载领域。本发明提供的数据下载控制方法，其先获取了目标用户进行下载的第一实时下载情况；并调取了建立好的下载模型；而后，根据下载模型确定所述第一实时下载情况的合理程度(第一实时下载情况与下载模型越相似，则合理程度越高)；并最后根据合理程度进行下载控制。在确定下载的合理程度的时候，使用了下载模型这样的数据模型来辅助进行判断，提高了判断的准确程度。

Description

数据下载控制方法及系统

技术领域

本发明涉及数据下载领域，具体而言，涉及数据下载控制方法及系统。

背景技术

随着通信技术的迅猛发展，智能设备已经深深的融入到了人们的日常生活中，常见的智能设备如手机、平板电脑、台式电脑等等。人们可以使用智能设备进行各种活动，比如浏览网页、在线观看视频等等，其中最常用的一种操作便是下载操作，大部分的用户行为也均与下载操作有关。

从用户主观行为的角度进行分类，下载行为可以分为善意下载行为和恶意下载行为，对于善意的下载行为，下载服务器通常是支持的，但对于恶意的下载行为，则通常需要加以管制。

在进行管制前首先需要对下载行为进行检测，以判断下载行为是否是恶意下载行为，在传统方案中，一般会对用户的下载次数进行监控，如果下载次数过多则会被认为是恶意下载行为，进而对其进行管控，但此种监控方式并不能很好的适用在任一种下载环境中。

发明内容

本发明的目的在于提供数据下载控制方法，以提高针对碎片型数据进行下载的控制的准确程度。

第一方面，本发明实施例提供了数据下载控制方法，包括：

获取目标用户进行下载的第一实时下载情况；

调取下载模型；

根据下载模型确定第一实时下载情况的合理程度；

根据合理程度进行下载控制。

结合第一方面，本发明实施例提供了第一方面的第一种可能的实施方式，其中，还包括：

获取目标用户在不同碎片云上进行下载的第一历史下载情况；

根据第一历史下载情况对目标用户所对应的下载模型进行更新，调取的下载模型包括目标用户所对应的下载模型。

结合第一方面，本发明实施例提供了第一方面的第二种可能的实施方式，其中，还包括：

获取不同用户在指定的碎片云上进行下载的第二历史下载情况；

根据第二历史下载情况对指定的碎片云所对应的下载模型进行更新；调取的下载模型包括指定的碎片云所对应的下载模型。

结合第一方面，本发明实施例提供了第一方面的第三种可能的实施方式，其中，还包括：

根据合理程度的数值大小，确定合理程度所对应的计算权值；

根据计算权值和第一实时下载情况对调取得到的下载模型进行更新。

结合第一方面，本发明实施例提供了第一方面的第四种可能的实施方式，其中，第一实时下载情况的类型包括以下的一种或多种：

目标用户/其他用户在指定碎片云上的数据的下载数量、目标用户/其他用户在指定时间内下载数据的数量、目标用户/其他用户下载指定数据的时间长度、目标用户/其他用户下载数据所在的时间段、目标用户/其他用户在同一个碎片云中下载数据的次序、目标用户/其他用户在同一个碎片云中读取数据的位置。

结合第一方面，本发明实施例提供了第一方面的第五种可能的实施方式，其中，根据合理程度进行下载控制包括：

若合理程度低于预设的数值，则获取关于目标用户的至少两个第二实时下载情况；每个第二实时下载情况分别用于描述客户端在不同的碎片云中下载碎片数据的情况；

计算至少两个第二实时下载情况之间的匹配程度；

根据匹配程度进行下载控制。

结合第一方面，本发明实施例提供了第一方面的第六种可能的实施方式，其中，根据合理程度进行下载控制包括：

碎片云为碎片云，碎片云中所存储的数据为碎片数据，存储在不同碎片云中的碎片数据用于相配合的组合成完整数据。

结合第一方面，本发明实施例提供了第一方面的第七种可能的实施方式，其中，步骤根据匹配程度进行下载控制包括：

若匹配程度满足预设的第一条件，则在预定时间内拒绝客户端的下载请求；

若匹配程度满足预设的第二条件，则对目标用户设置可执行下载操作的时间段，并将可执行下载操作的时间段向目标用户发送；

若匹配程度满足预设的第三条件，则调取客户端的历史下载数据，并依据历史下载数据对客户端进行控制。

结合第一方面，本发明实施例提供了第一方面的第八种可能的实施方式，其中，步骤计算至少两个第二实时下载情况之间的匹配程度包括：

获取匹配列表，匹配列表中记载了预设的至少两个第二实时下载情况；

根据至少两个第二实时下载情况确定实际关联关系；

根据实际关联关系和预设关联关系的相似程度确定匹配程度；实际关联关系是根据获取的至少两个第二实时下载情况确定的，预设关联关系是根据预设的至少两个第二实时下载情况确定的。

第二方面，本发明实施例还提供了数据下载控制装置，包括：

获取模块，用于获取目标用户进行下载的第一实时下载情况；

调取模块，用于调取下载模型；

确定模块，用于根据下载模型确定第一实时下载情况的合理程度；

控制模块，用于根据合理程度进行下载控制。

本发明实施例提供的数据下载控制方法，其先获取了目标用户进行下载的第一实时下载情况；并调取了建立好的下载模型；而后，根据下载模型确定第一实时下载情况的合理程度(第一实时下载情况与下载模型越相似，则合理程度越高)；并最后根据合理程度进行下载控制。在确定下载的合理程度的时候，使用了下载模型这样的数据模型来辅助进行判断，提高了判断的准确程度。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本发明实施例所提供的数据下载控制方法的基本流程图；

图2示出了本发明实施例所提供的数据下载控制方法的第一个细节流程图；

图3示出了本发明实施例所提供的数据下载控制方法的第二个细节流程图；

图4示出了本发明实施例所提供的数据下载控制方法的第二个细节流程图。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

相关技术中，已经出现了各种针对用户的下载行为进行检测和进行控制的方法，但这种控制方法通常较为单一，通常只是查看用户的下载量/次数是否过大，如果过大，则对该用户的下载行为进行管控，进而避免过多的恶意下载行为。但是这种下载检测、控制的方式过于单一，黑客容易进行规避，并且，对于分布式碎片数据存储而言并不很适用。

进而，本申请提供了分布式碎片数据存储系统的数据下载控制方法，如图1所示，该方法包括：

S101，获取目标用户进行下载的第一实时下载情况；

S102，调取下载模型；

S103，根据下载模型确定第一实时下载情况的合理程度；

S104，根据合理程度进行下载控制。

首先对分布式碎片数据存储系统进行说明。本申请所提供的分布式碎片数据存储系统指的是由至少两个碎片云所组成的存储系统，其中，至少两个碎片云中均是存储有碎片数据。需要说明的是，本申请所提供的技术方案主要是针对碎片数据的分布式云存储系统而设计的。其中，碎片数据指的是将一个完整数据拆分后得到的多个碎片式的数据，且，单独的碎片数据是无法表达特定含义，或者说无法表达完整数据真实含义的。本申请所提供的方法，适用于针对用户操作的手机、平板电脑、台式电脑或者服务器等智能设备所执行下载操作时，对该下载行为进行控制。

具体而言，此处的碎片数据指的是将完整数据(如一篇文章、一句话、一个单词、一张图片、一段视频、一段音频等电子数据)拆分得到的完整数据的部分数据，并且碎片数据是无法反应出完整数据的含义的(任意两个碎片数据之间均是不相同的)。例如原字段(完整数据)为数字55，可以将55拆分为50和60两个字段(不能拆分为55和0)，那么50和60均无法反应原字段55的含义，这样便起到了将数据表中的字段的真实含义，同时通过50/2+60/2，便可以计算出55，这样以拆分的方式进行隐藏的功能；又如，可以将55拆分为5和11(不能拆分为55和1)，5*11＝55，也就还原出了原始的55。

又如，在某种场景下，汉字“我”的代码是8116，进而可以将8116拆分为1247和1881，进而，在用户取得了1247和1881这两个代码后，可以通过1247*3+1881*1来还原成8116，由于1881和1247本身还对应有其他的汉字，因此，在不知晓该代码已经被拆分过，且不知晓还原公式(X*3+Y*1)的前提下，用户是无法知晓完整数据的真正含义的。

此种碎片数据的使用目的在于：使得单独或多个的碎片数据无法表示原有共享数据的含义。实际上，碎片数据也可以理解为一种可还原的加密手段，但将碎片数据还原的前提是获取到全部的碎片数据(如拆分完整数据得到的碎片数据共有5个，则将碎片数据还原的一个前提便是获取到这5个碎片数据)，以及得到还原公式，或者对应的拆分公式(一般情况下，拆分公式和还原公式是完全对应的)。正是由于在进行碎片数据存储的时候，是将完整数据拆分成了多个碎片数据，并且，这多个碎片数据是分别存储在不同的碎片云中的，使得第三方无法轻易得到每个碎片数据，即使其得到了每个碎片数据，由于第三方并不知晓数据合成规则，导致其也无法还原得到完整数据。进而，如果正常用户想要取得完整数据(碎片数据无法表达实际含义，只有得到完整数据才能够表达实际含义，也就是只有取得完整数据才有意义)，就必然需要得到全部的碎片数据，因此正常用户进行下载的话，必然是多个碎片云中都会下载碎片数据，而不是只在一个碎片云中下载数据。

步骤S101中，第一实时下载情况指的是目标用户(众多用户中进行下载操作的一个)在碎片云中下载碎片数据的情况。通常情况下，第一实时下载情况指的是目标用户在某一个碎片云上进行下载的情况。

步骤S102中，通过调取下载模型来在步骤S103中，依据该下载模型判断第一实时下载情况的合理程度。一般情况下，下载模型中可以记录有处于合理下载情况的条件。比如，下载次数小于10次，下载的总时间长度小于2小时等等。如果第一实时下载情况中的数据不符合这些条件，则说明合理程度是较低的，或者说，不符合这些条件的数据阅读，则合理程度越低。某种情况下，下载模型中的条件可以是一个标准值，第一实时下载情况中的数据距离该标准值越远，则其合理程度越低。

下载模型中的条件可以是一个也可以是多个，如果只有一个，则只需要判断第一实时下载情况中的数据是否符合这一个条件即可。如果是多个，则通常需要先分别判断第一实时下载情况中的每个数据与相应的条件的匹配程度，之后再按照加权计算的方式来得到合理程度。

也就是第一实时下载情况和下载模型中优选均携带有多种类型的数据，进而，通过判断第一实时下载情况的每一个数据与下载模型中的条件的符合程度，来确定第一实时下载情况的合理程度。

即，第一实时下载情况具体而言，应当包含有以下的一种或多种类型的数据：目标用户/其他用户在指定碎片云上的数据的下载数量、目标用户/其他用户在指定时间内下载数据的数量、目标用户/其他用户下载指定数据的时间长度、目标用户/其他用户下载数据所在的时间段、目标用户/其他用户在同一个碎片云中下载数据的次序、目标用户/其他用户在同一个碎片云中读取数据的位置。当然，下载模型中应当也对应的有这些类型的数据。

上述这些类型的数据，每一个都具有一定的参考价值，具体而言，目标用户在指定碎片云上的数据的下载数量指的是目标用户自己之前的历史下载数量，一般情况下，用户的下载行为是相对固定的，也就是每次下载的数量是大致相同的，因此，某一次目标用户的下载数量急剧增加，总分可以认为这种下载行为的合理程度较低。类似的，其他用户在指定碎片云上的数据的下载数量指的是除目标用户以外的用户的历史下载数量，通过参考其他用户的下载数量，也可以判断出目标用户的行为是否是合理的(一般情况下，用户的下载数量应当是大致相同的)。

类似的，在指定时间内下载数据的数量、下载指定数据的时间长度、下载数据所在的时间段、下载数据的次序等都可以作为条件来对辅助约定合理程度。在同一个碎片云中下载数据的次序指的是，系统可以预先将数据进行拆分，并将拆分后形成的多个数据按照预定的位置分别存储在不同的位置(该存储的位置，应当告知用户，或者是与用户约定好的)，而后，用户在请求下载时，则应当按照预定的次序进行下载，如果没有按照预定的次序进行下载，则会降低最终的合理程度。比如，系统共得到三个碎片数据，分别是A、B、C，这三个碎片数据分别存储在了第一个碎片云的1号区域(A碎片数据所在的区域)；2号区域(B碎片数据所在的区域)；3号区域(C碎片数据所在的区域)。系统和用户预先约定了应当按照如下的顺序下载数据，3号区域、2号区域、1号区域，因此，如果目标用户按照3号区域、2号区域、1号区域的数据来下载碎片数据，则说明目标用户的行为是合理的，如果目标用户按照1号区域、3号区域、2号区域的数据来下载碎片数据，则合理程度则可以认为是最低的；如果目标用户按照1号区域、2号区域、3号区域的数据来下载碎片数据，则合理程度可以认为是中等的(2号区域的下载次序是正确的)。

上述内容说明了，当下载模型中有一个条件时，应当依据第一实时下载情况符合这一个条件的程度来直接确定合理程度；以及，当下载模型中有多个条件时，应当依据第一实时下载情况符合中的数据分别符合多个条件的情况来先确定各个数据的匹配程度，而后，按照加权计算的方式，确定最终的合理程度。

步骤S104中，在确定了合理程度之后，就可以依据合理程度进行下载控制了。简单来讲，即合理程度越高，控制的力度越小，采取的控制手段越简单。比如，合理程度最高的时候，可以直接任由目标用户进行下载即可；合理程度中等的时候，需要对目标用户的下载行为进行进一步的监控；合理程度最低的时候，应当直接拒绝目标用户的任何下载请求。

为了更有针对性/更有效的对目标用户的行为进行监控，可以将下载模型进行具体化的限定。进而，下载模型可以分为三类，第一类是针对不同的用户建立的，也就是，不同的用户所调取的下载模型是不同的。第二类是针对不同的碎片云建立的，也就是，用户在A碎片云上下载数据时，调取到的下载模型与用户在B碎片云上所调取的下载模型是不同的。第三类是综合前两类，也就是针对不同的用户和不同的碎片云建立的，也就是1号用户在A碎片云上下载时，所调取的下载模型与2号用户在A碎片云上下载时，所调取的下载模型是不同的；同时1号用户在A碎片云上下载时，所调取的下载模型与1号用户在B碎片云上下载时，所调取的下载模型是不同的。

对于上述第一类的情况，主要是建立下载模型时所使用的数据是不相同的，第一类情况在建立模型时，更侧重于使用用户自己的历史下载行为数据来生成模型。比如可以将历史下载数据分为两种，第一种是自己(目标用户)曾经的下载行为数据和他人(除目标用户以外的其他用户)曾经的下载行为数据。由于自己的下载行为数据的参考意义更大，因此在建立下载模型时，应当更多的考虑自己的数据，也就是第一种是目标用户曾经的下载行为数据对建立下载模型的影响程度要大于其他用户曾经的下载行为数据对建立下载模型的影响程度。

也就是，如图2所示，本申请所提供的方法还包括：

S201，获取目标用户在不同碎片云上进行下载的第一历史下载情况；

S202，根据第一历史下载情况对目标用户所对应的下载模型进行更新，调取的下载模型包括目标用户所对应的下载模型。

此处的更新有两个含义，分别是当没有下载模型时，建立下载模型，和在已有下载模型时，对已有的下载模型进行调整。

类似的，对于上述第二类的情况，主要是建立下载模型时所使用的数据是不相同的，第二类情况在建立模型时，更侧重于使用指定的碎片云被下载的情况。比如可以将历史下载数据分为两种，第一种是指定碎片云过去被请求下载的情况数据和其他碎片云(除指定碎片云以外的其他碎片云)过去被请求下载的情况数据。由于指定碎片云的下载行为数据的参考意义更大，因此在建立下载模型时，应当更多的考虑指定碎片云的数据，也就是第一种是指定碎片云过去被请求下载的情况数据对建立下载模型的影响程度要大于其他碎片云过去被请求下载的情况数据对建立下载模型的影响程度。

也就是，如图3所示，本申请所提供的方法还包括：

S301，获取不同用户在指定的碎片云上进行下载的第二历史下载情况；

S302，根据第二历史下载情况对指定的碎片云所对应的下载模型进行更新；调取的下载模型包括指定的碎片云所对应的下载模型。

此处的更新有两个含义，分别是当没有下载模型时，建立下载模型，和在已有下载模型时，对已有的下载模型进行调整。

对于第三类情况，则是对上述两类情况的综合。也就是，即区分不同的用户也区分不同的碎片云，进而，本申请所提供的方法，如图4所示，还包括：

S401，获取目标用户在指定的碎片云上进行下载的第三历史下载情况；

S402，根据第三历史下载情况对指定的碎片云所对应的下载模型进行更新；调取的下载模型包括即与指定的碎片云相对应，也与目标用户相对应的下载模型。

此处的更新有两个含义，分别是当没有下载模型时，建立下载模型，和在已有下载模型时，对已有的下载模型进行调整。

上述三类情况，并不是在建立下载模型的时候只考虑单一的一种数据，而是更侧重的考虑这一种数据，比如第一类情况中，并不是只考虑目标用户曾经的下载行为数据，还会考虑其他用户的下载行为数据，也就是，第一类情况中，下载模型是依据目标用户曾经的下载行为数据(历史下载情况)和其他用户的下载行为数据生成的，只是生成下载模型的过程中，目标用户曾经的下载行为数据的权值更大。类似的，第二类也是在生成下载模型时，指定碎片云过去被请求下载的情况数据的权值要大于其他碎片云过去被请求下载的情况数据的权值。

实际操作中，系统可以同时建立上述三类模型，使用时优先使用第三类模型，即与指定的碎片云相对应，也与目标用户相对应的下载模型，第二适用的是第二类模型或第一类模型。这主要考虑的是，目标用户所对应的下载模型精度最高，但考虑到有些用户是新用户，其历史下载数据过少，此时模型可信度较低，因此，此时的下载模型是不能使用的，此时，应当考虑使用针对碎片云所建立的下载模型或者是目标用户在其他碎片云上所建立的下载模型。

即，本申请所提供的方法中，步骤S102，调取下载模型包括：

判断即与指定的碎片云相对应，也与目标用户相对应的下载模型的可信度，若可信度超过预定的阈值，则调取即与指定的碎片云相对应，也与目标用户相对应的下载模型；

若可信度不超过预定的阈值，则调取目标用户所对应的下载模型；或调取指定的碎片云所对应的下载模型。

除了确定下载模型以外，系统在运行的时候，还需要实时的对下载模型进行更新，进而，本申请所提供的方法还包括：

根据合理程度的数值大小，确定合理程度所对应的计算权值；

根据计算权值和第一实时下载情况对调取得到的下载模型进行更新。

也就是对下载模型进行更新的时候，不只是直接更新，而是考虑合理程度的数值大小，来确定第一实时下载情况对下载模型的影响程度。此处合理程度与权值的对应关系可以由管理员进行设定，设定的依据可以是使用场景、用户群体的行为习惯、用户群体的可信度等等。

上述内容介绍了，用户在某个碎片云上进行下载时，如何进行下载控制，下面，本申请所提供的方案还提供了针对分布式碎片数据存储系统进行下载控制的具体内容，

进而，步骤S104包括：

步骤101，获取关于客户端的至少两个第二实时下载情况；每个第二实时下载情况分别用于描述客户端在不同的碎片云中下载碎片数据的情况；存储在不同碎片云中的碎片数据用于相配合的组合成完整数据；

步骤102，计算至少两个第二实时下载情况之间的匹配程度；

步骤103，根据匹配程度进行下载控制。

进而，在执行步骤101之前，碎片云中会预先存储碎片数据，且存储在不同碎片云中的碎片数据是可以用来组成呈一个或多个完整数据的。下面以碎片云(碎片云A和碎片云B)有两个为例进行说明。如预先可以在碎片云A中存储碎片数据1-10，在碎片云B中存储碎片数据11-20；其中，碎片数据1-3与碎片数据11-14是用来组合成语句X的，碎片数据4-6与碎片数据14-17是用来组合成语句Y的；碎片数据7-10与碎片数据18-20是用来组合成语句Z的。也就是说，碎片云A中的碎片数据可以分成三组，第一组是碎片数据1-3，用来组成语句X，第二组是碎片数据4-6，用来组成语句Y，第三组是碎片数据7-10，用来组成语句Z。用户在进行下载的时候，如果是想合成语句Z，则需要从碎片云A中下载碎片数据7-10，并在碎片云B中下载碎片数据18-20。类似的，如果共有3个碎片云，则可以将拆分完整数据得到的多个碎片数据存储在这三个碎片云上，如拆分得到10个碎片数据，则可以是1-4个碎片数据存在第一个碎片云上，5-8个碎片数据存在第二个碎片云上，9-10个碎片数据存在第三个碎片云上。

需要说明的是，本申请所提供的方法在执行的时候，至少会涉及两端，分别是碎片云和客户端(用户所操作的)，其中，客户端是直接与碎片云进行交互的(客户端分别与每个碎片云通讯连接)，进而下载碎片云中存储的碎片数据。执行步骤101之前，首先需要生成第二实时下载情况，第二实时下载情况通常是由碎片云将碎片数据下传给客户端的同时，直接生成的。一般来说，执行步骤101-步骤103的主体(当然也是执行其他步骤的主体)可以是碎片云(由于实现本方案所涉及的碎片云至少有两个，因此，通常可以将执行步骤101-步骤103的主体确定为至少两个碎片云中的一个，此时，执行步骤101-步骤103的碎片云应当分别与其他所有碎片云通讯连接)；类似的执行步骤101-步骤103的主体(当然也是执行其他步骤的主体)也可以是独立的第三方服务器等具有计算功能的网络端，此时，该计算功能的网络端分别与每个碎片云通讯连接。

需要说明的是，存储在多个碎片云上的碎片数据有两种情况，第一种情况，只使用存储在碎片云上的多个碎片数据就可以组合成完整数据，此种情况下，如果拆分完整数据得到的碎片数据共有10个，则可以将这10个碎片数据均存储在碎片云上。即，拆分完整数据所得到的碎片数据均存储在碎片云上。

第二种情况，只使用存储在碎片云上的多个碎片数据是无法组合成完整数据，此种情况下，如果拆分完整数据得到的碎片数据共有10个，则可以将这10个碎片数据中的8个存储在碎片云上，另两个存储在客户端/安全用户端(用户所使用的安全性较高的客户端)中。即，拆分完整数据所得到的多个碎片数据中，一部分存储在碎片云中，另一部分存储在客户端/安全用户端中。

步骤101中，关于客户端的第二实时下载情况指的是，客户端在某碎片云中下载碎片数据的情况，当然，一个第二实时下载情况描述的是客户端在一个碎片云中下载碎片数据的情况。其中，第二实时下载情况中具体可以有一种或多种下载情况说明数据。下载情况说明数据如：下载的碎片数据的标识(区分不同碎片数据的符号)、指定次数内下载碎片数据的数量(可以指个数，也可以是总大小)、指定时间内下载碎片数据的数量(可以指个数，也可以是总大小)、下载碎片数据的时间长度(开始下载第一个碎片数据至下载完最后一个碎片数据之间所经历的时间长度，也可以是开始访问碎片云至下载完最后一个碎片数据/停止访问碎片云之间所经历的时间长度)、下载碎片数据所在的时间段(如在10点-11点之间、15点30分-16点之间进行的下载)、在同一个碎片云中读取碎片数据的次序(如同一个碎片云中存储有拆分完整数据得到的4个碎片数据，即碎片数据A-D，此时读取碎片数据的次序指的就是读取这四个碎片数据的先后顺序，如顺序可以是ACDB，也可以是CBDA)、在同一个碎片云中读取碎片数据的位置(如同一个碎片云中有不同的存储区，客户端读取的是A存储区中的碎片数据，还是B存储区中的碎片数据)、用户标识(即区分不同用户/客户端的标识)。其中，读取的意思有两种，一种是下载前，将数据提取出来的过程，另一种指的是提取+下载的整个过程。

为了确定合理的匹配程度，应当有一个标准的第二实时下载情况，也就是记载了碎片云A中的哪些碎片数据对应着碎片云B中的哪些碎片数据，进而，使得计算匹配程度的时候有更为准确的依据。进而，步骤102，计算至少两个第二实时下载情况之间的匹配程度包括：

步骤1021，获取匹配列表，匹配列表中记载了预设的至少两个第二实时下载情况；

步骤1022，根据实际关联关系和预设关联关系的相似程度确定匹配程度；实际关联关系是根据获取的至少两个第二实时下载情况确定的，预设关联关系是根据预设的至少两个第二实时下载情况确定的。

也就是匹配列表中记载了预设的第二实时下载情况，并且，匹配列表中记载的预设的第二实时下载情况应当是与用户约定好的，或者是在确定好之后告知用户的。

优选的，该匹配列表中的信息(预设的至少两个第二实时下载情况)是在独立的可信第三方机构随机生成的，并且，在将碎片数据进行存储的时候，应当根据该匹配列表中的信息来进行存储(如碎片数据1-4存储在碎片云A中，碎片数据5-9存储在碎片云B中…)。

如前文中的说明，用户应当关联性的下载碎片数据，才能够使用这些碎片数据组合得到完整数据，因此，理论上，客户端下载碎片数据的情况应当是相匹配的。即，在确定了至少两个第二实时下载情况后，应当执行步骤102中，可以确定出至少两个第二实时下载情况之间的匹配程度。具体而言，匹配程度有三种具体情况，下面仅以第二实时下载情况中包含有下载的碎片数据的标识。

第一种情况，如将完整数据拆分后得到了6个碎片数据，碎片数据1-3(碎片数据的标识)存储在碎片云A上，碎片数据4-6(碎片数据的标识)存储在碎片云B上，那么客户端下载的时候应当是即下载碎片数据1-3，也下载碎片数据4-6。进而如果一个第二实时下载情况中包含有碎片数据1-3的代码，另一个第二实时下载情况中包含有碎片数据4-6的代码，并且这两个第二实时下载情况中均有且只有碎片数据的代码的话，则说明这两个第二实时下载情况之间的匹配程度是100％。此时，则说明客户端的下载碎片数据的行为是正常的，进而步骤103中，则应当对该客户端的下载行为进行放行。

第二种情况，相对应的，如将完整数据拆分后得到了6个碎片数据，碎片数据1-3存储在碎片云A上，碎片数据4-6存储在碎片云B上，那么客户端下载的时候应当是即下载碎片数据1-3，也下载碎片数据4-6。进而如果一个第二实时下载情况中包含有碎片数据1-3的代码，另一个第二实时下载情况中包含有碎片数据7的代码，并且这两个第二实时下载情况中均有且只有碎片数据的代码的话，则说明这两个第二实时下载情况之间的匹配程度是0％。此时，则说明客户端的下载碎片数据的行为是异常的，进而步骤103中，则应当对该客户端的下载行为进行管控(如拒绝该客户端的下载行为，或者将该客户端列入黑名单，或者是调取该客户端之前的下载历史并进行更进一步的判断)。

第三种情况，如将完整数据拆分后得到了6个碎片数据，碎片数据1-3存储在碎片云A上，碎片数据4-6存储在碎片云B上，那么客户端下载的时候应当是即下载碎片数据1-3，也下载碎片数据4-6。进而如果一个第二实时下载情况中包含有碎片数据1-3的代码，另一个第二实时下载情况中包含有碎片数据5和6的代码，并且这两个第二实时下载情况中均有且只有碎片数据的代码的话，则说明这两个第二实时下载情况之间的匹配程度是67％。此时，则说明客户端的下载碎片数据的行为是近似异常的(由于客户端可能出现了网络故障、数据处理故障，导致某些下载没有进行，即是由于系统处理故障而导致的下载异常，而不是人为主观上不期望下载，因此，应当有一定的容错率，而不是将所有匹配率不是100％的都人为是异常)，进而步骤103中，则应当对该客户端的下载行为进行进一步的确认。如调取该客户端之前的下载历史，来了解其之前是否有过下载异常或者近似异常的情况，如果经常下载异常，则可以将本次下载行为也视作异常，反之则可以放行，当然，网络维护人员可以依据具体情况来进行调整(如匹配程度超过60％则可以认为是正常行为，匹配程度40-60％认为是近似异常，小于40％则是异常行为)。

上述三种情况介绍了第二实时下载情况中携带了下载的碎片数据的标识时，计算匹配程度的方式，与该种方式相类似的，还可以依据一种或多种下载情况说明数据来计算匹配程度。如在碎片云上按照等量的方式均匀的存储碎片数据，那么匹配程度的数值就也可以按根据A与B的比值得出(理论上A与B应当相等，因此，二者相差越多，则匹配程度越低)，其中A是客户端在第一个碎片云上下载碎片数据的数量，B是客户端在第二个碎片云上下载碎片数据的数量。当然，如果不同碎片云上存储的碎片数据的数量是按照一定比值、或其他函数关系对应的，那么A与B的关系也应当对应的满足比值或者其他的函数关系，越偏离该比值或函数关系的话，则匹配程度越低。又如，客户端在指定次数内下载碎片数据的数量、指定时间内下载碎片数据的数量、下载碎片数据的时间长度均可以按照这种方式来计算匹配程度。

如果下载情况说明数据是下载碎片数据所在的时间段则通常需要本地与客户端预先约定好规则，比如，在第一个碎片云上下载碎片数据的时间段应当与在第二个碎片云上下载碎片数据的时间段相距X小时，在在第二个碎片云上下载碎片数据的时间段应当与在第三个碎片云上下载碎片数据的时间段相距X+1小时等等。如果偏离了这个规则，则偏离越大，匹配程度越差。

类似的，在同一个碎片云中读取碎片数据的次序，也是需要采取预先约定的方式进行。比如可以预先约定客户端应当在第一个碎片云中按照由前至后的顺序来读取，在第二个碎片云中按照由后至前的顺序来读取，如果偏离该读取方式，则匹配程度降低。在同一个碎片云中读取碎片数据的位置，则是指在碎片云中也存在不同的分区，每个分区中均存储有相同的数据，可以本地与客户端预先约定，如果在第X个碎片云中的第N个分区取碎片数据的话，则应当在第Y个碎片云中的对应的W个分区取碎片数据，其中X和Y为数值不等的自然数；N与W均为自然数，且呈预定的函数关系。即，如果在至少两个第二实时下载情况中的在碎片云中读取碎片数据的位置没有按照上述规则来取，则应当相应的降低匹配程度。

用户标识主要是区分是否是同一个客户端/终端设备所进行的下载行为，其目的确定同一个客户端是否在不同的终端设备上进行了下载行为，如客户端在终端A上从碎片云A上下载了碎片数据X，客户端在终端A上从碎片云B上下载了碎片数据Y，这样的话，就说明客户端可能存在恶意下载，此时如果A与B的距离相距越远(也可以采用其他的规则)，则匹配程度越低。

需要说明的是，上述内容列举出了单独使用一个下载情况说明数据来计算匹配程度的方式，还可以是依据上述下载情况说明数据中的至少两个来计算匹配程度，具体而言，可以先按照上述说明的方式分别依据各个下载情况说明数据来计算出多个子匹配值(即按照上述方式单独依据下载的碎片数据的标识计算出关于的匹配程度、按照上述方式单独依据指定次数内下载碎片数据的数量计算出关于的匹配程度等等)，而后，再按照加权计算的方式，依据得到的多个子匹配值来计算匹配程度，如可以按照如下公式计算匹配程度，F＝AX+BY+CZ，其中F是步骤102中的匹配程度，ABC均为权值，XYZ分别为依据不同的下载情况说明数据计算得到的子匹配值。

计算的方式/公式可以是由网络维护人员进行定义，此处不再做过多的限定。但需要说明的是，如果使用了下载的碎片数据的标识这一说明数据的话，一般是不需要出现指定次数内下载碎片数据的数量、指定时间内下载碎片数据的数量这两个数据的，因为出现了代码，通常就可以表征下载碎片数据的数量了，但某些情况下，同一个代码可能会代表多个碎片数据，此时，则还可以是指定次数内下载碎片数据的数量、指定时间内下载碎片数据的数量和下载的碎片数据的标识同时出现在第二实时下载情况中。当然，二者同时出现也可以起到校验的作用。

实际上，匹配程度可以按照最为简单的方式来进行确定，即，下载的碎片数据的标识、指定次数内下载碎片数据的数量、指定时间内下载碎片数据的数量、下载碎片数据的时间长度、下载碎片数据所在的时间段、在同一个碎片云中读取碎片数据的次序、在同一个碎片云中读取碎片数据的位置、用户标识这些下载情况说明数据可以是用户与云端预先约定好的，比如，在不同的碎片云中下载碎片数据的时间长度，或时间段应当是基本相同的，并且可以依据具体的差距来调整匹配程度。又如，客户端在不同的碎片云中应当按照既定的次序来读取(读取可以理解为下载、或者是浏览)碎片数据如在第一个碎片云中按照由前至后的顺序读取，则在另一个碎片云中应当按照由后之前的顺序读取。

上述内容介绍了依据碎片数据的特性(碎片数据只有全部取出后才能够组合成完整数据，因此，正常用户通常会将位于多个碎片云中的关于同一个完整数据的碎片数据按照既定的规则全部取出，来使其能够组合成完整数据，如果是黑客的话，则不会按照这既定的规则全部取出来)来对多个碎片云进行匹配监控方法。但发明人发现，如果每一次均按照此种方式进行判断的话，则对数据安全不利(主要是每次均需要得到至少两个第二实时下载情况，因此，需要对至少两个碎片云进行下载情况的监控，监控后还需要通过网络传输这些监控得到的信息，这期间容易泄露数据)，也增加系统负担。因此，发明人认为，可以采取先单独监控一个碎片云的情况，如果出现异常再进行匹配监控的方式。

具体的，本申请所提供的方法中，在步骤获取关于客户端的至少两个第二实时下载情况前还包括：

步骤501，获取关于客户端的至少一个第三实时下载情况；每个第三实时下载情况用于描述客户端在指定的碎片云中下载碎片数据的情况；

步骤502，根据第三实时下载情况满足预设条件的情况，确定是否执行步骤获取关于客户端的至少两个第二实时下载情况。

需要说明的是，第三实时下载情况和第二实时下载情况的内容可以是相同/相似的，但二者后续的作用却完全不同，第三实时下载情况的作用是判断客户端对某一个碎片云中的碎片数据的下载行为是否异常(依据一个第三实时下载情况进行独立判断)，第二实时下载情况的作用是判断客户端对某多个碎片云中的碎片数据的下载行为是否异常(依据至少两个第二实时下载情况进行组合、匹配式的判断)。

步骤502中，需要依据第三实时下载情况的具体情况来确定是否执行步骤101，也就是依据第三实时下载情况来执行相应操作的话，是有多种可能性的结果的，具体而言，有如下三种结果：

若第三实时下载情况满足预设的第一条件，则执行步骤获取关于客户端的至少两个第二实时下载情况；

若第三实时下载情况满足预设的第二条件，则对客户端的下载行为进行控制；

若第三实时下载情况满足预设的第三条件，则终止当前流程。

其中，第一条件、第二条件和第三条件的具体标准应当是没有交集的，即第三实时下载情况不应当同时满足这三个条件中的任意两个，当然，更不可能是同时满足这三个条件。实际操作中，第一条件、第二条件和第三条件的具体内容可以是网络维护人员依据具体的情况、场景来确定的。比如，第一条件、第二条件和第三条件可以是下载行为所持续的时间长度，如第一条件是2-3小时，第二条件是超过3小时，第三条件是小于两小时，进而，当符合第一条件的时候，说明下载行为是近似恶意的，执行步骤101-步骤103；当符合第一条件的时候，则说明下载行为是恶意的，此时应当对该下载行为进行及时的管控(如终止本次下载行为、将客户端列在黑名单中、在一定时间内拒绝客户端的所有下载请求等等)；当符合第一条件的时候，则说明下载行为是正常的，此时，应当终止监控的流程，等下一次客户端再进行新的下载行为时再进行监控。

下面列举出了几种具体的判断条件，即本申请所提供的方案中，还包括执行如下一个或多个判断步骤，并根据判断步骤的判断结果确定第三实时下载情况满足预设的第一条件、第二条件或第三条件：

判断客户端在指定的碎片云中的下载数量是否大于历史下载量阈值；

判断客户端在指定的碎片云中的下载数量是否大于标准下载量阈值；

判断客户端在指定的碎片云中进行下载操作时所在的时间段是否不与历史下时间段重合；

判断客户端在指定的碎片云中进行下载操作时所在的时间段是否不与标准下时间段重合；

判断客户端在指定的碎片云中进行下载操作时所使用的网络地址的数量是否超过标准值；

判断在目标网络地址的上登陆过的客户端的数量是否超过预设的标准值，目标网络地址是客户端在指定的碎片云中进行下载操作时所使用的网络地址。

需要说明的是，判断客户端在指定的碎片云中进行下载操作时所使用的网络地址的数量是否超过标准值指的是，客户端是否经常在不同的网络地址上进行下载，如果客户端经常在不同的网络地址上进行下载，这说明客户端登录可能存在异常。

判断在目标网络地址的上登陆过的客户端的数量是否超过预设的标准值，目标网络地址是客户端在指定的碎片云中进行下载操作时所使用的网络地址，指的是在指定的网络地址上，是否有很多不同的客户端登录过，如果是的话，则说明使用者是通过更换下载客户端的方式来恶意的从碎片云中下载碎片数据。

并且，根据判断步骤的判断结果确定第三实时下载情况满足预设的第一条件、第二条件或第三条件的具体确定规则可以是本地与用户预先约定好的。

相对应的，当符合不同条件的时候，还应当进行相应的操作，下面列举三个优选的操作。即，步骤根据匹配程度进行下载控制包括：

若匹配程度满足预设的第一条件，则在预定时间内拒绝客户端的下载请求；

若匹配程度满足预设的第二条件，则对客户端设置可执行下载操作的时间段，并将可执行下载操作的时间段向客户端发送；

若匹配程度满足预设的第三条件，则调取客户端的历史下载数据，并依据历史下载数据对客户端进行控制。

其中，设置可执行下载操作的时间段，作用是约束客户端的下载时间使得该用户端更容易被监管，也是将该客户端下载的时间放在网络压力较小的时间段(一种惩罚方式)。

依据历史下载数据对客户端进行控制指的是查看客户端历史下载数据后，查看客户端曾经是否有过不良记录，如果有过，则可以对其进行管控，如果没有过，则可以采取惩罚方式教轻的策略进行管控。整体来看，依据历史下载数据对客户端进行控制，主要体现的是相对控制的思想，即单纯依据当前的条件(第三实时下载情况)不好确定客户端是善意的还是恶意的，因此，需要调取历史数据进行辅助判断。

优选的，存储在不同的碎片云中的碎片数据的数量/大小是不相同的。这也能够避免恶意客户端在下载的时候，平均的在每个碎片云上都下载一些，进而规避管控。

为了保证匹配列表中的第二实时下载情况是相对安全的(不会被黑客窃取走)，用户与本地确定匹配列表中的第二实时下载情况的内容时，不应当将具体内容直接写在修改请求中。而是，本地与用户预先约定好可选方案，然后每次修改的时候，用户只需要将可选方案的代码发送出来，进而避免了直接发送具体内容，避免黑客截取到具体内容。

进而，本申请所提供的技术方案还包括：

获取安全用户端所发出的匹配信息修改请求；匹配信息修改请求中携带有选择代码；

在候选列表中选择与选择代码相对应的下载情况作为匹配列表中预设的第二实时下载情况；在本地和安全用户端中均存储有内容相同的候选列表，且在候选列表中记载有多个不同的下载情况信息。

其中，安全用户端可以是客户端(如果客户端的安全级别足够高)，也可以是独立于客户端的第三方机构。候选列表可以是本地与安全用户端协商形成的，也可以是本地形成后告知安全用户端，还可以是安全用户端形成之后发送给本地进行存储的。

具体的，候选列表的形式可以是如下表1所示，

表1

选择代码	下载情况信息的内容
		1001	AAAAAA
1002	BBBBBB
		1003	CCCCCC
1004	DDDDDD

进而，在本地接收到安全用户端所发出的匹配信息修改请求后，直接根据匹配信息修改请求中的选择代码来查找相应的下载情况信息，并将查找到的下载情况信息作为匹配列表中预设的第二实时下载情况。这种确定预设的第二实时下载情况的方式，在本地与安全用户端之间没有进行实际内容的交互(即没有在匹配信息修改请求中携带下载情况信息的内容)，而是携带了代码，这样即使有第三方窃取到该匹配信息修改请求也不会知晓验证的规则，保证了安全性。

与上述方法相对应的，本申请还提供了数据下载控制系统，包括：监控服务器、至少两个碎片云和客户端；每个碎片云均分别与监控服务器和客户端通讯连接；

监控服务器用于执行如上述的方法；

客户端用于向碎片云发起下载碎片数据的请求；

碎片云用于向客户端发出存储在本地的碎片数据，以及向监控服务器传输下载情况。

功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (8)

1.分布式碎片数据存储系统的数据下载控制方法，其特征在于，包括：

获取目标用户进行下载的第一实时下载情况；

调取下载模型；

根据下载模型确定所述第一实时下载情况的合理程度；

根据合理程度进行下载控制；

根据合理程度进行下载控制包括：

若所述合理程度低于预设的数值，则获取关于目标用户的至少两个第二实时下载情况；每个所述第二实时下载情况分别用于描述客户端在不同的碎片云中下载碎片数据的情况；

计算所述至少两个第二实时下载情况之间的匹配程度；

根据所述匹配程度进行下载控制；

步骤所述计算至少两个第二实时下载情况之间的匹配程度包括：

获取匹配列表，匹配列表中记载了预设的至少两个第二实时下载情况；

根据至少两个第二实时下载情况确定实际关联关系；

根据实际关联关系和预设关联关系的相似程度确定匹配程度；实际关联关系是根据获取的至少两个第二实时下载情况确定的，预设关联关系是根据预设的至少两个第二实时下载情况确定的。

2.根据权利要求1所述的方法，其特征在于，还包括：

获取所述目标用户在不同碎片云上进行下载的第一历史下载情况；

根据第一历史下载情况对目标用户所对应的下载模型进行更新，所述调取的下载模型包括所述目标用户所对应的下载模型。

3.根据权利要求1所述的方法，其特征在于，还包括：

获取不同用户在指定的碎片云上进行下载的第二历史下载情况；

根据第二历史下载情况对所述指定的碎片云所对应的下载模型进行更新；所述调取的下载模型包括所述指定的碎片云所对应的下载模型。

4.根据权利要求1所述的方法，其特征在于，还包括：

根据合理程度的数值大小，确定所述合理程度所对应的计算权值；

根据所述计算权值和第一实时下载情况对所述调取得到的下载模型进行更新。

5.根据权利要求1所述的方法，其特征在于，所述第一实时下载情况的类型包括以下的一种或多种：

目标用户/其他用户在指定碎片云上的数据的下载数量、目标用户/其他用户在指定时间内下载数据的数量、目标用户/其他用户下载指定数据的时间长度、目标用户/其他用户下载数据所在的时间段、目标用户/其他用户在同一个碎片云中下载数据的次序、目标用户/其他用户在同一个碎片云中读取数据的位置。

6.根据权利要求1所述的方法，其特征在于，根据合理程度进行下载控制包括：

所述碎片云中所存储的数据为碎片数据，存储在不同碎片云中的碎片数据用于相配合的组合成完整数据。

7.根据权利要求1所述的方法，其特征在于，步骤所述根据匹配程度进行下载控制包括：

若所述匹配程度满足预设的第一条件，则在预定时间内拒绝所述客户端的下载请求；

若所述匹配程度满足预设的第二条件，则对目标用户设置可执行下载操作的时间段，并将所述可执行下载操作的时间段向目标用户发送；

若所述匹配程度满足预设的第三条件，则调取所述客户端的历史下载数据，并依据所述历史下载数据对客户端进行控制。

8.分布式碎片数据存储系统的数据下载控制装置，其特征在于，包括：

获取模块，用于获取目标用户进行下载的第一实时下载情况；

调取模块，用于调取下载模型；

确定模块，用于根据下载模型确定所述第一实时下载情况的合理程度；

控制模块，用于根据合理程度进行下载控制；

所述控制模块，包括：

判断单元，若所述合理程度低于预设的数值，则用于获取关于目标用户的至少两个第二实时下载情况；每个所述第二实时下载情况分别用于描述客户端在不同的碎片云中下载碎片数据的情况；

计算单元，用于计算所述至少两个第二实时下载情况之间的匹配程度；

下载单元，用于根据所述匹配程度进行下载控制；

所述计算单元，包括：

列表获取子单元，用于获取匹配列表，匹配列表中记载了预设的至少两个第二实时下载情况；

第一确定子单元，用于根据至少两个第二实时下载情况确定实际关联关系；

第二确定子单元，用于根据实际关联关系和预设关联关系的相似程度确定匹配程度；实际关联关系是根据获取的至少两个第二实时下载情况确定的，预设关联关系是根据预设的至少两个第二实时下载情况确定的。

Images