一种文件传输系统及方法、一种计算设备及存储介质与流程

本申请涉及互联网技术领域，特别涉及一种文件传输系统及方法、一种计算设备及存储介质。

背景技术：

现有游戏微端常用的文件下载方法如下：首先将数据文件按块(一般为场景或者资源绑定关系)进行打包并分发至cdn(contentdeliverynetwork，内容分发网络)，然后在客户端运行a场景时，后台自动下载b场景以及后续资源包到客户端。这种方法实现简单，不过存在以下几个缺点：

游戏体验不连贯：由于下载的基本单元较大，在b场景未完全下载时，游戏必须等待。

游戏管理存在一定风险：必须保证任何一个版本的所有文件严格按照上述模块分类并捆绑。如果出现某块基本单元中资源不全，或者绑定关系错误，那么客户端将无法正常运行。

游戏失败重试代价高：在某块数据文件的内容大的情况下，若下载数据有误，可能整个数据文件都需要重新下载。

对现有技术的上述缺点，结合新的客户端文件系统，本申请提出了一种新的文件传输系统及方法、一种计算设备及存储介质。

技术实现要素：

有鉴于此，本申请实施例提供了一种文件传输系统及方法、一种计算设备及存储介质，以解决现有技术中存在的技术缺陷。

本申请实施例公开了一种文件传输系统，包括：

传输模块，被配置为接收请求端对目标文件的下载请求，其中所述下载请求包括目标文件的标识信息；

管理模块，被配置为根据所述目标文件的标识信息，确定目标文件的存储位置，所述目标文件的存储位置包括缓存、磁盘或者服务器；

在所述目标文件的存储位置为缓存的情况下，所述管理模块还被配置为将缓存中的所述目标文件经由传输模块返回至请求端；

在所述目标文件的存储位置为磁盘的情况下，所述管理模块向请求端发送通知消息，所述通知消息包括所述目标文件在磁盘中的存储位置信息；

在所述目标文件的存储位置为服务器的情况下，所述管理模块，还被配置为将下载请求转换为目标文件的下载指令，所述系统还包括：下载模块，被配置为根据所述下载指令向服务器请求所述目标文件，并将接收到的所述目标文件推送至所述缓存。

可选地，所述系统还包括：调度模块；

下载模块进一步被配置为根据所述下载指令向服务器请求所述目标文件，并将接收到的所述目标文件推送至所述调度模块；

所述调度模块，被配置为接收由所述下载模块推送的所述目标文件，并将所述目标文件推送至缓存。

可选地，在所述目标文件的存储位置为服务器的情况下，

所述管理模块，还被配置为判断所述下载指令是否在下载队列，若是，所述调度模块被配置为设置下载指令在下载队列中的优先级；

若否，判断所述下载指令是否在调度队列，若是，将下载指令推送至下载队列；若否，将下载指令添加至调度队列。

可选地，在所述调度模块确定所述缓存当前被占用容量小于所述缓存的第一阈值，且所述下载模块中当前同时下载文件的数量小于第二阈值的情况下，

所述调度模块，还被配置为将在调度队列中优先级最高的下载指令推送至下载队列。

可选地，在所述调度模块确定所述缓存当前被占用容量超过所述缓存的第一阈值，或所述下载模块中当前同时下载文件的数量超过第二阈值的情况下，

所述调度模块，还被配置为暂停下载队列向下载模块推送下载指令，或降低下载队列向下载模块推送下载指令的速度。

可选地，所述系统还包括：

存储模块，被配置为在确定缓存实际的执行值大于第三阈值的情况下，将缓存中的目标文件推送至所述磁盘。

可选地，所述传输模块采用单个进程接收多个请求端的下载请求，并将下载请求推送至所述管理模块；

所述传输模块通过单个进程向多个请求端推送目标文件或通知消息。

可选地，所述下载模块，还被配置为根据网络环境确定下载引擎和下载策略。

可选地，所述下载模块具体被配置为：

在不同的网络环境下，通过切换下载引擎和重试不同的下载策略，以确定最优的下载引擎和下载策略；

动态监测各个下载策略的错误情况，停用错误率高的下载策略；

动态监测各个下载引擎的下载速度，降低下载速度慢的下载引擎优先级。

可选地，所述下载引擎包括：对等网络p2p、命令行统一资源定位器curl、比特流bt和视窗互联网wininet；

所述下载策略包括：超文本传输协议http2.0、http1.1和https。

可选地，在下载策略为http2.0、目标文件为批量流式小文件的情况下，

所述传输模块具体被配置为：采用单个进程通过多个线程接收所述请求端批量发起的对于所述目标文件的下载请求。

可选地，在所述下载引擎为bt的情况下，所述下载模块具体被配置为：

获取对应的种子文件，其中，种子文件按固定大小将其索引的全部目标文件划分成多个片段，并分别记录各个片段的校验信息；

将下载请求转换为各个片段的下载指令，根据所述下载指令分别向服务器请求并校验每个所述目标片段的数据，最后将校验后的目标片段拼合形成所述目标文件。

另一方面，本申请还提出了一种文件传输方法，包括：

接收请求端对目标文件的下载请求，其中所述下载请求包括目标文件的标识信息；

根据所述目标文件的标识信息，确定目标文件的存储位置，所述目标文件的存储位置包括缓存、磁盘或者服务器；

在所述目标文件的存储位置为缓存的情况下，将缓存中的所述目标文件返回至请求端；

在所述目标文件的存储位置为磁盘的情况下，向请求端发送通知消息，所述通知消息包括所述目标文件在磁盘中的存储位置信息；

在所述目标文件的存储位置为服务器的情况下，将下载请求转换为目标文件的下载指令，根据所述下载指令向服务器请求所述目标文件，并将接收到的所述目标文件推送至所述缓存。

可选地，在所述目标文件的存储位置为服务器的情况下，

判断所述下载指令是否在下载队列，若是，设置下载指令在下载队列中的优先级；

若否，判断所述下载指令是否在调度队列，若是，将下载指令推送至下载队列；若否，将下载指令添加至调度队列。

可选地，在确定所述缓存当前被占用容量小于所述缓存的第一阈值，且当前同时下载文件的数量小于第二阈值的情况下，

将在调度队列中优先级最高的下载指令推送至下载队列。

可选地，在确定所述缓存当前被占用容量超过第一阈值，或当前同时下载文件的数量超过第二阈值的情况下，

暂停下载队列推送下载指令，或降低下载队列推送下载指令的速度。

可选地，根据所述标识信息确定目标文件在磁盘中的存储位置，根据存储位置将缓存中的文件存储至所述磁盘。

可选地，还包括：

在确定缓存实际的执行值大于第三阈值的情况下，将缓存中的文件存储至所述磁盘。

可选地，采用单个进程接收多个请求端的下载请求；

通过单个进程向多个请求端推送目标文件或通知消息。

可选地，根据网络环境确定下载引擎和下载策略。

可选地，根据网络环境确定下载引擎和下载策略，包括：

在不同的网络环境下，通过切换下载引擎和重试不同的下载策略，以确定最优的下载引擎和下载策略；

动态监测各个下载策略的错误情况，停用错误率高的下载策略；

动态监测各个下载引擎的下载速度，降低下载速度慢的下载引擎优先级。

可选地，所述下载引擎包括：对等网络p2p、命令行统一资源定位器curl、比特流bt和视窗互联网wininet；

所述下载策略包括：超文本传输协议http2.0、http1.1和https。

可选地，在所述下载策略为http2.0、所述目标文件为批量流式小文件的情况下，接收请求端对目标文件的下载请求，包括：

采用单个进程通过多个线程接收所述请求端批量发起的对于所述目标文件的下载请求。

可选地，在所述下载引擎为bt的情况下，

将下载请求转换为目标文件的下载指令，根据所述下载指令向服务器请求所述目标文件，包括：

获取对应的种子文件，其中，种子文件按固定大小将其索引的全部目标文件划分成多个片段，并分别记录各个片段的校验信息；

将下载请求转换为各个片段的下载指令，根据所述下载指令分别向服务器请求并校验每个所述目标片段的数据，最后将校验后的目标片段拼合形成所述目标文件。

另一方面，本申请还提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述文件传输方法的步骤。

另一方面，本申请还提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现所述文件传输方法的步骤。

本申请提供的一种文件传输系统及方法、一种计算设备及存储介质，在确定目标文件的不同存储位置的情况下，根据目标文件的存储位置，能够将目标文件快速的传送至请求端。特别是在游戏文件下载的过程中，不但能保证目标文件的快速传送，同时能够保证用户对游戏的优质体验。

附图说明

图1是本申请实施例的计算设备的结构框图；

图2是本申请实施例的文件传输方法的示意性流程图；

图3是本申请实施例的a.txt文件在片段中的位置示意图；

图4是本申请实施例的文件传输系统结构示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在本申请中，提供了一种文件传输系统及方法、一种计算设备及存储介质，在下面的实施例中逐一进行详细说明。

图1是示出了根据本说明书一实施例的计算设备100的结构框图。该计算设备100的部件包括但不限于存储器110和处理器120。处理器120与存储器110通过总线130相连接，数据库150用于保存数据。

计算设备100还包括接入设备140，接入设备140使得计算设备100能够经由一个或多个网络160通信。这些网络的示例包括公用交换电话网(pstn)、局域网(lan)、广域网(wan)、个域网(pan)或诸如因特网的通信网络的组合。接入设备140可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(nic))中的一个或多个，诸如ieee802.11无线局域网(wlan)无线接口、全球微波互联接入(wi-max)接口、以太网接口、通用串行总线(usb)接口、蜂窝网络接口、蓝牙接口、近场通信(nfc)接口，等等。

在本说明书的一个实施例中，计算设备100的上述部件以及图1中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图1所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备100可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或pc的静止计算设备。计算设备100还可以是移动式或静止式的服务器。

其中，处理器120可以执行图2所示方法中的步骤。图2是示出了根据本申请一实施例的文件传输方法的示意性流程图，包括步骤202至步骤210。

步骤202：接收请求端对目标文件的下载请求，其中所述下载请求包括目标文件的标识信息。

步骤204：根据所述目标文件的标识信息，确定目标文件的存储位置，所述目标文件的存储位置包括缓存、磁盘或者服务器。

步骤206：在所述目标文件的存储位置为缓存的情况下，将缓存中的所述目标文件返回至请求端。

步骤208：在所述目标文件的存储位置为磁盘的情况下，向请求端发送通知消息，所述通知消息包括所述目标文件在磁盘中的存储位置信息。

步骤210：在所述目标文件的存储位置为服务器的情况下，将下载请求转换为目标文件的下载指令，根据所述下载指令向服务器请求所述目标文件，并将接收到的所述目标文件推送至所述缓存。

在确定目标文件的不同存储位置的情况下，根据目标文件的存储位置，能够将目标文件快速的传送至请求端。特别是在游戏文件下载的过程中，不但能保证目标文件的快速传送，同时能够保证用户对游戏的良好体验。

其中，所述目标文件以单个文件数据块为单元进行下载。如此在网络稳定的情况下，客户端只需要下载当前视野范围内所需要的文件数据块，无需下载整个目标文件，进而实现按需下载。

在按需下载的方式下，请求端仅需要下载完成每个场景必要的数据，就可以提前进入该场景，无需等待整个场景下载完才能够进入，同时也缩短了目标文件的下载等待周期。另外，按需下载无需场景与对应的资源进行准确的捆绑，且无论目标文件处于哪个场景中，在需要的使用目标文件时，目标文件能够准确无误的被调取出来进行使用。

同样，在下载数据发现错误的情况下，仅需要重新下载对应的单元；另外在本地文件有缺失或者错误的情况下，也能通过及时的下载对本地文件进行热修复。

而在向cdn上传大量的文件数据块或向请求端分发大量的文件数据块的过程中，管理大量的文件数据块成本高，耗时久，且容易出现传输错误，为解决这一问题，将大量的文件数据块合并为少量大文件，即桶(bucket)，然后将少量桶上传到cdn。

在向请求端分发大量的文件数据块的过程中，通过请求端目标文件中的元信息推算出文件数据块在cdn的位置，即确定文件数据块位于哪个桶中，并确定文件数据块相对于桶的偏移和文件大小。然后通过httprange(hypertexttransferprotocolrange，超文本协议范围)技术或者定制的p2p(peer-to-peer，点对点)下载技术从服务器拉取对应的文件数据块。

例如，一个桶中有100个文件数据块，如果发现第30文件数据块错误，仅需要重新下载第30个文件数据块即可，无需整个桶下载。据统计，游戏中大部分文件数据块在几kb到几百kb之间，少数达到1mb以上，因此正常网络环境下重新下载时间非常短。

可选地，在所述目标文件的存储位置为服务器的情况下，

判断所述下载指令是否在下载队列，若是，设置下载指令在下载队列中的优先级；

若否，判断所述下载指令是否在调度队列，若是，将下载指令推送至下载队列；若否，接收下载指令，并将下载指令推送至下载队列。

在确定下载指令在下载队列的情况下，通过提高所述目标文件对应的下载指令在下载队列的优先级，以使所述目标文件能够优先下载。

在确定下载指令在调度队列的情况下，将目标文件对应的下载指令从调度队列推送至下载队列，并提高所述下载指令在下载队列的优先级，以使所述目标文件能够优先下载。

在确定下载指令既不在调度队列，又不在下载队列的情况下，通过从服务器获取目标文件，将目标文件的下载指令推送至下载队列，并提高所述下载指令在下载队列的优先级，以使所述目标文件能够优先下载。

可选地，在确定所述缓存当前被占用容量小于所述缓存的第一阈值，且当前同时下载文件的数量小于第二阈值的情况下，

将在调度队列中优先级最高的下载指令推送至下载队列。

通过上述方法能够充分利用下载队列对应的下载引擎，从而提高下载引擎的下载速度。

由于请求端对不同文件的响应需求是不同的，例如在游戏中，地形数据要求最先下载，而装饰类物件可以略微延迟下载，因此引入多级动态优先级，为满足客户端高实时响应的需要，所述下载队列包括：立即下载队列，预下载队列和空闲下载队列。

其中，立即下载队列中的下载指令的优先级大于预下载队列中的下载指令的优先级，预下载队列中的下载指令的优先级大于空闲下载队列空闲下载队列。

位于立即下载队列中的下载指令需要立即下载对应的目标文件，且请求端需要同步等待目标文件的返回。一般在打开某个目标文件发现本地缺失时，所述目标文件对应的下载指令会添加到立即下载队列中。

位于预下载队列中的下载指令对应着非即时需要的目标文件，例如游戏中视野周围的树木等资源。且所述预下载队列会在立即下载队列为空时，顺次批量下载其中的下载指令对应的目标文件。

位于空闲下载队列中的下载指令对应着客户端当前非必需的目标文件，例如下一个场景的资源。且所述空闲下载队列会在立即下载队列以及预下载队列为空的时候，顺次批量下载其中的下载指令对应的目标文件。

对于已经推送至调度队列中的下载指令，请求端可以随时变更调度队列中的下载指令的优先级，包括响应优先级。

在游戏运行的过程中，为了保证客户端能够快速加载流式资源，例如npc(non-playercharacter，非玩家角色)和建筑物件，我们采用了lod(levelsofdetail，多细节层次)的资源下载和加载机制。具体地，每个模型物件的贴图都分为低精度，中精度，高精度等多个叠加层，而在加载的过程中，每个模型物件的贴图按照从低到高的次序下载并加载到场景中展示，人物和建筑物件表现为从一般清晰到十分清晰的逐渐过渡，从而无需等待所有资源下载完毕才能看到模型物件在场景中的位置。

可选地，在确定所述缓存当前被占用容量超过第一阈值，或当前同时下载文件的数量超过第二阈值的情况下，

暂停下载队列推送下载指令，或降低下载队列推送下载指令的速度。

通过上述方法能够使下载队列平缓的推送下载指令，进而保证用户对游戏的良好体验。

例如，第一阈值为32mb，第二阈值为256；在所述缓存的当前被占用容量超过32mb，或当前同时下载文件的数量超过256个的情况下，暂停下载队列推送下载指令，或降低下载队列推送下载指令的速度，以使所述缓存的当前被占用容量低于32mb，或当前同时下载文件的数量少于256个，进而使得下载队列平缓的推送下载指令。

其中请求端包括客户端，在下载速度过快的情况下，会导致带宽占用过高，进而可能导致客户端延迟(ping值，从pc对网络服务器发送数据到接收到服务器反馈数据的时间)变高。为避免这一问题的出现，可定期检查ping值是否在合理的范围之内，若是，保持原有的下载目标文件的速度；若否，根据情况调整下载目标文件的速度。

例如，当ping值低于70ms时，增加下载目标文件的速度；当ping值高于120ms时，降低下载目标文件的速度；而当ping值在70-120ms内时，不改变下载目标文件的速度。如此能够实现缓慢提速和快速降速，以逐步试探理想的带宽上限并及时应对突发的高延迟，从而保证了客户端良好的运行性能。

可选地，所述方法还包括：

在确定缓存实际的执行值大于第三阈值的情况下，将缓存中的文件存储至所述磁盘。

其中所述第三阈值包括缓存当前被占用容量和缓存一次性存放文件的时间

例如，当缓存中当前被占用容量超过32mb时，缓存中的文件的数据将被一次性推送到磁盘中，以降低磁盘的i/o(输入/输出，input/output)的开销。

再例如，当缓存中一次性存放文件的时间为十秒时，缓存中的文件的数据将被一次性推送到磁盘中，以降低磁盘的i/o(输入/输出，input/output)的开销。

而在所述目标文件的存储位置为缓存的情况下，缓存中的所述目标文件直接返回至请求端，如此不会触发磁盘的i/o(输入/输出，input/output)的操作，进而能够降低磁盘的i/o(输入/输出，input/output)的开销。

可选地，所述方法采用单个进程接收多个请求端的下载请求；

通过单个进程向多个请求端推送目标文件或通知消息。

所述文件传输方法可作为一个独立的服务进程在后台运行，多个客户端在需要进行目标文件下载时，会通过进程间消息队列(interprocesscommunicationmessagequeue)推送下载请求，在收到下载请求，完成下载任务后，通过进程间消息队列推送目标文件或者通知消息至客户端。具体地，所有目标文件下载和目标文件写入操作，都是由单个进程执行，而目标文件数据的读取操作，由各个客户端进程自行完成。如此既避免了多个客户端同时进行目标文件写入，以造成写入冲突的问题，又能够统一调度不同客户端推送来的下载请求，同时保证了各个客户端读取数据的速度最大化，进而保证了客户端良好的运行性能。

可选地，根据网络环境确定下载引擎和下载策略。

由于外网环境错综复杂，不同环境下的最优下载机制并不完全相同。为提高不同网络环境下的下载速度与下载成功率，所述文件传输方法采用自适应多下载引擎策略，

所述多套下载引擎包括：p2p(peertopeer，对等网络)、curl(commandlineuniformresourcelocator，命令行统一资源定位器)、bt(bittorrent，比特流)和wininet(windowsinternet，视窗互联网)，所述多套下载策略包括：http2.0(hypertexttransferprotocol2.0，超文本传输协议2.0)、https(hypertexttransferprotocoloversecuresocketlayer或hypertexttransferprotocolsecure，超文本传输安全协议)和http1.1(hypertexttransferprotocol1.1，超文本传输协议1.1)。

在不同的网络环境下，通过切换下载引擎和重试不同的下载策略以确定最优的下载引擎和下载策略，进而提高下载速度与下载成功率。同时通过动态监测各个下载策略的错误情况以及下载引擎的下载速度，动态停用错误率高的下载策略，以降低下载速度慢的下载引擎优先级，从而达到自适应下载的目的。

在采用http2.0进行批量流式小文件的下载过程中，单个进程通过多个线程接收请求端(客户端)批量发起的对于流式小文件的下载请求，大大提高批量流式小文件的下载速度，经测试批量下载小文件的速度基本达到下载带宽的上限。

标准bt(bittorrent，比特流)下载技术需要通过种子文件作为索引完成下载。具体地，获取对应的种子文件，其中，种子文件按固定大小将其索引的全部目标文件划分成多个片段，并分别记录各个片段的sha1(securehashalgorithm1，安全哈希算法1)校验信息；然后将下载请求转换为各个片段的下载指令，根据下载指令分别向服务器请求并校验每个所述目标片段的数据，最后将校验后的目标片段拼合，形成完整的目标文件。

针对大量小文件的应用场景下，种子文件片段大小必须足够小，否则会导致大量冗余的数据下载。比如，片段大小设置为1024kb，实际上只需要下载24kb的数据，那么将产生1000kb的浪费。然而，由于每个片段都需要记录sha1校验信息，那么对于一个总大小约80g的大型资源目录做种时，将产生100m以上的种子文件。另外，即使我们选择16kb作为片段大小，仍然有不少文件甚至不足16kb，或者其数据并不按16kb片段对齐，这仍然会导致一部分冗余数据下载。

结合图3，图3示出了根据本申请一实施例的a.txt文件在片段中的位置示意图；其中，a.txt文件的大小一共32kb，但是由于其跨越了3个片段，从左至右依次为片段1、片段2和片段3，且a.txt文件在每个片段中的大小分别是8kb，16kb和8kb，而每个片段的大小均为16kb，所以实际上需要下载48kb的数据，如此则会造成16kb的浪费。针对这一问题，经定制后的p2p能够通过客户端系统文件的查询和写入，使得种子文件中无需带有sha1校验信息，并且能够支持无冗余数据的下载，即能够实现不对齐的文件下载，例如对于a.txt文件a.txt会被分成3部分下载，分别是8kb、16kb和8kb，如此在对a.txt文件进行校验的过程中，仅需对a.txt文件对应的数据进行校验，无需对包含有a.txt文件的所有片段进行校验；使得定制后的p2p无需下载48kb的数据以完整下载a.txt文件；另外，定制后的p2p能够为每个下载请求增加一个优先级并且支持每个下载请求的优先级的动态变更。

另一方面，本申请还提出了一种文件传输系统，参见图4，图4示出了根据本申请一实施例的文件传输系统400结构示意图，包括：

传输模块402，被配置为接收请求端对目标文件的下载请求，其中所述下载请求包括目标文件的标识信息；

管理模块404，被配置为根据所述目标文件的标识信息，确定目标文件的存储位置，所述目标文件的存储位置包括缓存、磁盘或者服务器；

在所述目标文件的存储位置为缓存的情况下，所述管理模块还被配置为将缓存中的所述目标文件经由传输模块返回至请求端；

在所述目标文件的存储位置为磁盘的情况下，所述管理模块向请求端发送通知消息，所述通知消息包括所述目标文件在磁盘中的存储位置信息；

在所述目标文件的存储位置为服务器的情况下，所述管理模块，还被配置为将下载请求转换为目标文件的下载指令，所述系统还包括：下载模块408，被配置为根据所述下载指令向服务器请求所述目标文件，并将接收到的所述目标文件推送至所述缓存；

调度模块406，被配置为接收由所述下载模块推送的所述目标文件，并将所述目标文件推送至缓存；

存储模块412，被配置为在确定缓存实际的执行值大于第三阈值的情况下，将缓存中的文件存储至所述磁盘；

写入模块410，被配置为判断缓存实际的执行值是否大于第三阈值，若是，执行存储模块，若否，继续判断缓存实际的执行值是否大于第三阈值。

在所述管理模块确定目标文件的不同存储位置的情况下，根据目标文件的存储位置，能够将目标文件快速的传送至请求端。其中请求端包括客户端，特别是在游戏文件下载的过程中，不但能保证目标文件的快速传送，同时能够保证客户端的用户对游戏的良好体验。

可选地，下载模块进一步被配置为根据所述下载指令向服务器请求所述目标文件，并将接收到的所述目标文件推送至所述调度模块；

所述调度模块，被配置为接收由所述下载模块推送的所述目标文件，并将所述目标文件推送至缓存。

所述调度模块将下载模块从服务器下载的目标文件推送至缓存，不但能够使目标文件通过缓存返回至请求端，而且能够在下次需要请求目标文件时直接从缓存中获取，进而提高目标文件的获取速度，从而保证用户对游戏的良好体验。

可选地，在所述目标文件的存储位置为服务器的情况下，

所述管理模块，还被配置为判断所述下载指令是否在下载队列，若是，所述调度模块被配置为设置下载指令在下载队列中的优先级；

若否，判断所述下载指令是否在调度队列，若是，将下载指令推送至下载队列；若否，将下载指令添加至调度队列。

在管理模块确定下载指令在下载队列的情况下，通过提高所述目标文件对应的下载指令在下载队列的优先级，以使所述目标文件能够优先下载。

在管理模块确定下载指令在调度队列的情况下，将目标文件对应的下载指令从调度队列推送至下载队列，并提高所述下载指令在下载队列的优先级，以使所述目标文件能够优先下载。

在管理模块确定下载指令既不在调度队列，又不在下载队列的情况下，通过从服务器获取目标文件，将目标文件的下载指令推送至下载队列，并提高所述下载指令在下载队列的优先级，以使所述目标文件能够优先下载。

可选地，在所述调度模块确定所述缓存当前被占用容量小于所述缓存的第一阈值，且所述下载模块中当前同时下载文件的数量小于第二阈值的情况下，

所述调度模块，还被配置为将在调度队列中优先级最高的下载指令推送至下载队列。

通过调度模块将在调度队列中优先级最高的下载指令推送至下载队列，能够充分利用下载队列对应的下载引擎，从而提高下载引擎的下载速度

可选地，在所述调度模块确定所述缓存当前被占用容量超过所述缓存的第一阈值，或所述下载模块中当前同时下载文件的数量超过第二阈值的情况下，

所述调度模块，还被配置为暂停下载队列向下载模块推送下载指令，或降低下载队列向下载模块推送下载指令的速度。

通过确定所述缓存当前被占用容量超过所述缓存的第一阈值，或所述下载模块中当前同时下载文件的数量超过第二阈值的情况下，调度模块能够使下载队列平缓的推送下载指令，进而保证用户对游戏的良好体验。

可选地，所述传输模块采用单个进程接收多个请求端的下载请求，并将下载请求推送至所述管理模块；

所述传输模块通过单个进程向多个请求端推送目标文件或通知消息。

所述系统通过传输模块与请求端进行单写多读的多进程交互能够统一调度不同客户端推送来的下载请求，同时保证了各个客户端读取数据的速度最大化，进而保证了客户端良好的运行性能。

可选地，所述下载模块，还被配置为根据网络环境确定下载引擎和下载策略。

由于外网环境错综复杂，不同环境下的最优下载机制并不完全相同。所述下载模块采用自适应多下载引擎策略，其中包含有多套下载引擎和多套下载策略，能够提高不同网络环境下的下载速度与下载成功率。

可选地，所述下载模块408具体被配置为：

在不同的网络环境下，通过切换下载引擎和重试不同的下载策略，以确定最优的下载引擎和下载策略；

动态监测各个下载策略的错误情况，停用错误率高的下载策略；

动态监测各个下载引擎的下载速度，降低下载速度慢的下载引擎优先级。

可选地，所述下载引擎包括：对等网络p2p、命令行统一资源定位器curl、比特流bt和视窗互联网wininet；

所述下载策略包括：超文本传输协议http2.0、http1.1和https。

可选地，在下载策略为http2.0、目标文件为批量流式小文件的情况下，

所述传输模块402具体被配置为：采用单个进程通过多个线程接收所述请求端批量发起的对于所述目标文件的下载请求。

可选地，在所述下载引擎为bt的情况下，所述下载模块408具体被配置为：

获取对应的种子文件，其中，种子文件按固定大小将其索引的全部目标文件划分成多个片段，并分别记录各个片段的校验信息；

将下载请求转换为各个片段的下载指令，根据所述下载指令分别向服务器请求并校验每个所述目标片段的数据，最后将校验后的目标片段拼合形成所述目标文件。

本申请一实施例还提供一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现以下如前所述文件传输方法的步骤。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前所述文件传输方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的文件传输方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述文件传输方法的技术方案的描述。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。