CN113179301A - 文件的下载方法和装置、存储介质、电子装置 - Google Patents

Abstract

本申请公开了一种文件的下载方法和装置、存储介质、电子装置。其中，该方法包括：接收第一终端的第一文件请求，第一终端中登录有在业务平台上使用的第一帐号，第一文件请求用于第一帐号请求获取目标文件，目标文件中记录有第一帐号使用第一虚拟资源从业务平台换取的业务服务，业务服务用于表示在发生指定事件的情况下业务平台向第二帐号提供第二虚拟资源；生成与第一文件请求对应的下载任务，并将下载任务加入至任务队列，下载任务用于从业务平台下载目标文件；按照下载任务在任务队列中的位置执行下载任务；在下载任务执行成功的情况下，向第一终端返回目标文件。本申请解决了相关技术中文件下载请求的并发量较大的技术问题。

Description

文件的下载方法和装置、存储介质、电子装置

技术领域

本申请涉及互联网领域，具体而言，涉及一种文件的下载方法和装置、存储介质、电子装置。

背景技术

保险的电子保单和电子发票是保险公司的系统生成的，保险代理平台负责将文件下载下来，并存储下载，在客户端展示给用户，在用户下载的时候发送给用户。

如图1所示，相关技术中用户可在小程序中点击下载，直接通过下载组件下载并等待文件下载到手机上，用户需要持续等待文件下载，下载完后直接使用。

在以上方案中，存在的问题很明显，就是当大量用户进行并发请求的时候，增加了保险公司系统压力：由于第一次资料的下载会调用保险公司的接口来制作文件，如果存在大量的第一次请求调用保险公司的接口，这样会给保险公司的系统带来很大的压力；影响用户下载体验：电子保单和电子发票制作是一个耗时的过程，如果大量的请求直接跟用户建立长连接很容易出现超时而下载失败的情况，从而导致用户体验很差；系统稳定性下降：带宽是非常重要的资源，如果仅仅是因为一个下载功能导致系统稳定性下降，将会给其他系统的其它功能造成更大的损失。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种文件的下载方法和装置、存储介质、电子装置，以至少解决相关技术中文件下载请求的并发量较大的技术问题。

根据本申请实施例的一个方面，提供了一种文件的下载方法，包括：接收第一终端的第一文件请求，第一终端中登录有在业务平台上使用的第一帐号，第一文件请求用于第一帐号请求获取目标文件，目标文件中记录有第一帐号使用第一虚拟资源从业务平台换取的业务服务，业务服务用于表示在发生指定事件的情况下业务平台向第二帐号提供第二虚拟资源；生成与第一文件请求对应的下载任务，并将下载任务加入至任务队列，下载任务用于从业务平台下载目标文件；按照下载任务在任务队列中的位置执行下载任务；在下载任务执行成功的情况下，向第一终端返回目标文件。

根据本申请实施例的另一方面，还提供了一种文件的下载装置，包括：接收单元，用于接收第一终端的第一文件请求，其中，第一终端中登录有在业务平台上使用的第一帐号，第一文件请求用于第一帐号请求获取目标文件，目标文件中记录有第一帐号使用第一虚拟资源从业务平台换取的业务服务，业务服务用于表示在发生指定事件的情况下业务平台向第二帐号提供第二虚拟资源；生成单元，用于生成与第一文件请求对应的下载任务，并将下载任务加入至任务队列，其中，下载任务用于从业务平台下载目标文件；下载单元，用于按照下载任务在任务队列中的位置执行下载任务；返回单元，用于在下载任务执行成功的情况下，向第一终端返回目标文件。

根据本申请实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的程序，程序运行时执行上述的方法。

根据本申请实施例的另一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器通过计算机程序执行上述的方法。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方法中任一实施例的步骤。

在本申请实施例中，将下载任务加入至任务队列，按照下载任务在任务队列中的位置执行下载任务；在下载任务执行成功的情况下，向第一终端返回目标文件，该方案可以通过任务队列释放用户并发请求的压力，由于任务队列始终是串行执行下载任务，从而可以将之前短时间内大量的并发请求转换为长时间连续的请求，也即可以控制到达下载接口的请求量，可以解决相关技术中文件下载请求的并发量较大的技术问题，进而达到降低并发量的技术效果。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是相关技术中的文件下载界面的示意图；

图2是根据本申请实施例的文件的下载方法的硬件环境的示意图；

图3是根据本申请实施例的一种可选的文件的下载方法的流程图；

图4是根据本申请实施例的一种可选的文件的下载方法的流程图；

图5是根据本申请实施例的一种可选的文件的下载装置的示意图；

以及

图6是根据本申请实施例的一种终端的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本申请实施例进行描述的过程中出现的部分名词或者术语适用于如下解释：

保险电子保单：电子保单是指保险公司遵循PKI体系(所有与数字证书相关的各种概念和技术，是Public Key Infrastructure的简称)的数字签名软件和企业数字证书为客户签发的具有保险公司电子签名的电子化保单，保险人与被保险人订立保险合同的正式书面证明，保险单是保险合同成立的证明。

电子发票：同普通发票一样，采用税务局统一发放的形式给商家使用，发票号码采用全国统一编码，采用统一防伪技术，分配给商家，在电子发票上附有电子税务局的签名。

消息队列：消息队列是在消息的传输过程中保存消息的容器，全称为MessageQueue消息队列(简称MQ)，是一种应用程序对应用程序的通信方法，MQ是消费-生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取队列中的消息进行消费。

对象存储：对象存储是用来描述解决和处理离散单元的方法的通用术语。对象在一个层结构中不会再有层级结构，是以扩展元数据为特征的。

根据本申请实施例的一方面，提供了一种文件的下载方法的方法实施例，该方法可以应用于理财、保险等业务场景下。

可选地，在本实施例中，上述文件的下载方法可以应用于如图2所示的由终端201(即使用理财、保险等业务服务的终端，如下文提及的第一终端、第二终端等)和服务器203(该服务器为提供保险、理财等业务服务的服务器，若用户和提供服务的平台之间还存在代理，那么该服务器包括代理服务器和服务平台的服务器)所构成的硬件环境中。如图2所示，服务器203通过网络与终端201进行连接，可用于为终端或终端上安装的客户端提供服务(如保险服务、理财服务等服务)，可在服务器上或独立于服务器设置数据库205，用于为服务器203提供数据存储服务，上述网络包括但不限于：广域网、城域网或局域网，终端201并不限定于PC、手机、平板电脑等。

本申请实施例的文件的下载方法可以由服务器203来执行(后续以此为例进行说明)，也可以由服务器203和终端201共同执行。图3是根据本申请实施例的一种可选的文件的下载方法的流程图，该方法可以包括以下步骤：

步骤S302，服务器接收第一终端的第一文件请求，第一终端中登录有在业务平台上使用的第一帐号，第一文件请求用于第一帐号请求获取目标文件，目标文件中记录有第一帐号使用第一虚拟资源从业务平台换取的业务服务，业务服务用于表示在发生指定事件的情况下业务平台向第二帐号提供第二虚拟资源。

上述虚拟资源为货币、数字货币、代金券等资源；上述帐号(包括第一帐号和第二帐号)为在业务服务中使用的帐号，如帐户标识、手机号、身份证号等信息中的一个或者多个，第一帐号为购买业务服务(如购买理财产品或者保险产品)的用户，第二帐号为在业务服务中受益的用户；上述指定事件为在业务服务中指定的触发提供向第二帐号提供第二虚拟资源的事件，如理财产品发生增值、发生保险产品中规定的出保事件。

第一帐号和第二帐号可以是同一帐号，相当于用户自己购买业务服务并在业务服务中受益；第一帐号和第二帐号可以是不同帐号，相当于第一帐号的用户购买业务服务以使得第二帐号的用户在业务服务中受益，例如，用户A用自己的货币为自己购买保险产品并指定用户B是受益人，用户A用自己的货币为用户B购买保险产品并指定某用户(可以是用户B或者另一用户)是受益人，还可以是用户A用自己的货币为用户B购买理财产品。

步骤S304，服务器生成与第一文件请求对应的下载任务，并将下载任务加入至任务队列，下载任务用于从业务平台下载目标文件。

上述任务队列用于保存所有待执行的任务，并按照在队列中的顺序执行下载任务。

步骤S306，服务器按照下载任务在任务队列中的位置执行下载任务。

例如，任务队列中从头到尾依次保存有任务1、任务2，…，任务n，目前正在执行的任务是任务m(m小于n，且n和m都是正整数)，当任务m执行完成后，所执行的任务是任务(m+1)。

步骤S308，在下载任务执行成功的情况下，服务器向第一终端返回目标文件。

通过上述步骤，将下载任务加入至任务队列，按照下载任务在任务队列中的位置执行下载任务；在下载任务执行成功的情况下，向第一终端返回目标文件，该方案可以通过任务队列释放用户并发请求的压力，由于任务队列始终是串行执行下载任务，从而可以将之前短时间内大量的并发请求转换为长时间连续的请求，也即可以控制到达下载接口的请求量，可以解决相关技术中文件下载请求的并发量较大的技术问题，进而达到降低并发量的技术效果。下文结合具体步骤进一步详述本申请的技术方案。

步骤1，用户需要下载电子保单、电子发票等目标文件时，在第一终端上进入业务平台，如该平台的交互应用、交互小程序、交互网页等，通过与业务平台的交互传递自己的下载意向，此时，服务器会接收到第一终端的第一文件请求。

可选地，在接收第一终端的第一文件请求之后，可向第一终端发送第一提示信息，第一提示信息用于提示目标文件预计在等待目标时长后下载成功，如提示用户预计6小时内下载成功。

步骤2，服务器生成与第一文件请求对应的下载任务，并将下载任务加入至任务队列。

对于每个下载任务，可以保存多个字段，如保存队列标识的字段、用户标识(即用户帐号)的字段、每个文件的文件类型的字段、文件下载状态的字段、下载重试次数的字段、累计重试总时间的字段等。

可选地，为了便于监控每个文件的下载状态，在保存下载任务时可将目标文件中每个文件的下载状态与下载任务关联后保存至任务队列，下载状态在初始时为未下载。

在该方案中，可以实现系统性能瓶颈的切换，用户并发请求的压力，由下载模块的带宽压力变成了系统接口请求的压力了，这样就可以优化接口或者通过基础的扩容来解决问题，下载性能的限制变成了消息队列的接收和处理的限制。

对于队列中的下载任务，可将用户标识_保单标识(userID_policyID)作为任务的关键字key，对于首次在任务队列中新增任务的用户，这类用户的每次任务记录都会记录到数据库mysql中。由于所有的下载任务都会加入到任务消息队列中，为了提高队列的运行效率，可以限制同一用户的单日下载次数(如为3)，且如果用户之前的任务没有处理完成就新增下载任务，可将用户新增的任务给删除掉。通过这种限流方式可以减少对业务平台的请求压力。

步骤3，按照下载任务在任务队列中的位置执行下载任务，包括以下步骤31-步骤39。

步骤31，在下载任务为任务队列中的第一个任务的情况，从任务队列中取出该下载任务并直接执行。

步骤32，在下载任务不是任务队列中的第一个任务的情况，在位于下载任务之前且与该下载任务相邻的那个任务执行完的情况下，从任务队列中取出下载任务。

步骤33，获取业务平台提供的与下载任务匹配的链接地址，以按照链接地址下载目标文件。

在一个可选的实施方式中，可先按照链接地址发送目标文件的下载请求，有的平台通过该链接地址可以直接下载文件，此时，平台的响应包括以下几种情况：1)直接返回目标文件；2)返回告知目标文件还在制作中的通知；3)超时未反馈，此时可能是服务器或者平台发生故障。

在另一个可选的实施方式中，有的平台通过该链接地址并不能直接下载文件，在按照链接地址发送目标文件的下载请求后，会接收到一个返回的响应内容；可按照响应内容中的下载地址访问目标网页，以通过目标网页下载目标文件，目标网页的响应结果与上述类似。

步骤34，判断目标文件是否下载成功。正常的文件一般会大于某个阈值，因此可以通过文件大小判断是否下载成功。

可先获取目标文件的文件大小；在文件大小大于第二阈值(如2KB)的情况下，确定目标文件下载成功；在文件大小不大于第二阈值的情况下，确定目标文件下载失败。

步骤35，在目标文件下载成功的情况下，将目标文件转存至存储器中。

可选地，对于下载成功的目标文件，可按照如下内容生成目标文件对应的数据对象：用于标识目标文件的文件标识、目标文件、用于表示数据对象的存放方式和存放位置的元数据、用于描述数据对象的属性信息；然后将数据对象转存至存储器，该存储器可以为本地网盘或者云盘。

步骤36，在按照链接地址下载目标文件之后，在目标文件中存在下载失败的第一文件和下载成功的第二文件的情况下，将与下载任务关联的第二文件的下载状态修改为已下载，并保持第一文件的下载状态为未下载不变；然后将修改下载状态后的下载任务重新加入到任务队列，以等待再次执行。

可选地，在目标文件中第一文件下载失败且第二文件下载成功的情况下，向第一终端发送第二提示信息，第二提示信息用于提示第一文件未下载成功且第二文件下载成功。

进一步地，将修改下载状态后的下载任务重新加入到任务队列，以等待再次执行，包括，将下载状态未下载的下载任务重新加入至任务队列，以重新下载第二文件；将下载状态为下载成功的第一文件反馈给第一终端。

步骤37，创建系数集合(即系数的取值集合)，如{1,2,3,4，…，2^(cout-1)},cout表示重试次数，每次重试时，可随机从系数集合中选取目标系数，如选出4。

步骤38，将目标系数乘以参考延迟时长(可认为是预先设定的一个单位的延迟时长，如20毫秒)，得到第一延迟时长(如4*20＝80毫秒)。进一步地，参考延迟时长可根据业务平台支持的并发能力动态调整，例如，业务平台在单位时间内支持的并发数为m，而待处理的任务数(即待处理的文件的下载请求书)为n，那么参考延迟时长可以设定为k*n/m，其中，k为预先设定的系数，一般取值大于1的系数，具体可以根据系统冗余相关设置确定。

步骤39，确定累计延迟时长，累计延迟时长为下载任务每次已执行的延迟时长的累计和。

在第一延迟时长与累计延迟时长之和小于第一阈值(如500毫秒)的情况下，如第一延迟时长为80毫秒，累计延迟时长为400毫秒，二者之和480毫秒是小于500毫秒的，故在距离前一次执行下载任务的间隔时间达到第一延迟时长的情况下，再次执行下载任务。

在第一延迟时长与累计延迟时长之和不小于第一阈值的情况下，如第一延迟时长为80毫秒，累计延迟时长为450毫秒，二者之和530毫秒是大于500毫秒的，故可将第一阈值减去累计延迟时长，得到第二延迟时长50毫秒，并在距离前一次执行下载任务的间隔时间达到第二延迟时长的情况下，再次执行下载任务。

上述方案实现了下载任务的自动重试，由于代理平台(如保险代理平台)对接不同的业务平台(如保险公司的平台)，不同的业务平台制作电子保单和电子发票的耗时都是不同的，而且经常因为系统原因导致请求失败，本方案会使用以上方案进行重试，有效的结合失败率的情况来设置重试的间隔时间。

可选地，在目标文件中存在未下载成功的文件且等待时长达到目标时长之后，向第一终端发送第三提示信息，第三提示信息用于提示目标文件中存在未下载成功的文件，用户可以明日再试或者自行联系客服。

持续执行以上步骤，直至所有文件均下载完成或者超时。

以将上述方案应用于保险为例，在用户向保险公司请求下载电子保单和电子发票后，将下载到的电子保单和电子发票存储到云对象存储中，方便后续用户使用文件的时候能够快速获取。

如果只有其中一种文件类型下载成功，会给用户发送一次邮件提示"电子保单(电子发票)下载成功，还有电子发票(电子保单)未下载，请稍后注意查看邮件"；并将任务重新发送到任务队列中，等到到达重试时间时再次执行；如果全部文件下载成功，会将所有电子保单和电子发票都发送给用户；如果全部文件下载失败，会在6小时后发送邮件告知用户，这个时候一般是保司系统原因导致制作电子保单或电子发票较慢，会提示用户第二天重新尝试下载或者找客服向保司加急制作电子文件。

可选地，在每天晚上11点，把当天6h还没有生成电子保单或电子发票的数据，并带上调用数据，再统计出来，发给对应的保险公司，查看具体原因。

步骤4，在下载任务执行成功的情况下，向第一终端返回目标文件，如果用户想要查看电子保单，可以在小程序上直接查看。

步骤5，对于保存的目标文件，在再次被请求时可以不再去平台获取，而直接从存储器中获取，在向第一终端返回目标文件之后，接收第二终端的第二文件请求，第二文件请求用于请求获取目标文件；从存储器中获取目标文件；向第二终端返回目标文件。

作为一种可选的实施例，下文以将本申请的技术方案应用于保险业务为例进行详细说明，如图4所示。

在保险代理平台向保险公司请求制作电子保单和电子发票，并提供电子保单和电子发票给用户的过程中，可以采用本申请的技术方案，实现文件的中间传输和存储，不包含制作电子保单和电子发票的过程。所有的下载任务会放到一个消息队列(即任务队列)中进行处理；如果下载不成功，则使用计算重试时间进行有限时间内的任务重试，重试任务会重新放到消息队列中，只是设置了延迟时间delayTime；当文件下载成功后，会将文件存储到分布式对象存储中，并将存储地址url存储到数据库mysql与用户保单数据存放一起；最后可通过邮件的方式，将压缩好的文件发送给用户。具体实现步骤如下：

步骤S1，用户可在小程序中点击“下载”按钮，以请求下载电子保单和电子发票。

保险电子保单和电子发票是保险公司的系统生成的，保险代理平台负责将文件下载下来，并存储下载，在客户端展示给用户，在用户下载的时候发送给用户。

步骤S2，用户在小程序中点击下载之后，可输入电子邮箱，此时后台会将用户的本次下载任务放到发送任务的消息队列中，并直接给用户返回“邮件会在6小时内发送到您邮箱，请注意查收！”的提示，用户会在小程序界面中看到该提示。

用户在前端小程序中点击下载后，除了会直接返回用户提示“附件将会在未来6小时内发送到邮箱，请注意查收”外，还会把用户的下载任务添加到一个消息队列中，每个任务都会带上附件类型(POLICY电子保单，INVOICE电子发票)和下载情况(0表示未下载，1表示已下载)。可通过将用户下载电子保单和电子发票的任务，放到发送任务的消息队列中，来处理用户的请求。

步骤S3，若文件未生成，则循环执行：向保险公司请求文件数据，接收请求返回的数据。

消息队列的数据格式如下：字段1：队列ID(queueID)；字段2：用户ID(UID)；字段3：平台保单号(PolicyID)；字段4：文件类型1(电子保单POLICY)；字段5：文件类型1下载情况(0未下载；1已下载)；字段6：文件类型2(电子发票INVOCIE)；字段7：文件类型2下载情况(0未下载；1已下载)；字段8：重试次数count；字段9：重试总时间totalTime。

消息队列的特殊格式的主要作用如下：1)用于区分不同用户的不同保单的下载任务；2)记录任务被执行的次数和总耗时，用来计算下一次重试时间，或确定是否已截止重试；3)记录文件下载情况，用来查看完成了部分文件下载还是全部文件的下载。

保险代理平台会对接不同的保险公司，保险公司的系统能力参差不齐，不同的产品需要向不同的承保公司请求制作电子发票和电子保单。

1)有的保险公司会直接返回“电子保单或电子发票制作中”，这个时候需要将下载任务重新放回队列中，计算重试时间。

结合消息队列中任务的数据结构，可按照如下方式计算重试时间：

步骤S31，将重试总耗时时间设置为limitTime。

步骤S32，根据队列中重试的次数count，确定取值集合{1，2，3，…，2^(count-1)}。

步骤S33，在集合中随机取出值记为R，下次重试的时间为R*基本退避时间。

由于场景中重试事件并不是网络问题引起的，而是业务本身，所以基本退避时间不是默认值(如51.2us)，可根据不同保险公司动态设置为特定的基本退避时间t，重试时间定义为delayTime。

步骤S34，如果任务的字段totalTime>＝limittime，则停止任务；如果totalTime<limittime且totalTime+delayTime>＝limittime，则取delayTime＝limitTime-totalTime，根据截止时间来计算最后一次重试时间。

步骤S35，重复上述步骤，直到任务执行结束，结束条件为完成全部文件的下载或者重试总耗时超过limitTime。

例如，将重试总耗时时间设置为1000us，基本退避时间为11us，根据队列中重试的次数，计算出取值集合{1，2，3，…，20}；

第1次重试时，在取值集合中随机取出一个数值2，进而确定本次重试时间为2*11＝22us；本次重试结束后，重试总时间为22us；

第2次重试时，在取值集合中随机取出一个数值5，进而确定本次重试时间为5*11＝55us，由于55us+22us<1000us，直接按照55us进行延时重试处理；本次重试结束后，重试总时间为77us；

…；

第i次重试时，在取值集合中随机取出一个数值7，进而确定本次重试时间为7*11＝77us，前一次得到的重试总时间为988us，由于77us+988us>1000us，进而确定实际的重试时间为1000-988＝12us，按照12us进行延时重试处理；本次重试结束后，重试总时间为1000us，结束重试。

有的保险公司会直接返回对应电子保单或电子发票的下载地址，但是这个时候并未真正的生成电子发票或电子保单，打开是一个提示“电子发票制作中”的网页，所以这个时候需要判断文件(如pdf文件)的大小，若文件大小小于2k，会被认为下载失败，任务会被放入队列中进行重试；如果文件大小大于等于2k，则视为下载成功。

步骤S4，将下载的文件存储到云中，并接收云端反馈的“存储成功”的响应。

当从保险公司下载电子保单或电子发票成功后，会将文件存储到云对象存储中，由于电子保单文件和电子发票的文件类型是pdf，属于非结构化数据，于是选择"对象存储"作为文件存储方式。

对象存储是将数据当做对象，包含：数据ID(用于唯一标识对象)、数据(对象的主体)、元数据(表示对象存放方式、存放位置的数据)、属性(定义的其他描述对象的数据)，可按照Hash等索引的方式，直接将数据存放到磁盘的磁道和扇区，无目录结构，通过OSD(object-based storage device)对象存储设备提供文件处理的接口。

本方案提供的ID示例如下：

PG02/POLICY/4f7f27acb……92477637.pdf。

地址(存储ID)会存储到数据库mysql中，方便后续用户使用。如果mysql中的地址是空的，则会重新向保险公司请求电子保单或电子发票，有时候用户的姓名或者身份证号修改了，则会这样操作，重新生成电子保单。

步骤S5，将文件进行压缩，得到压缩包。

步骤S6，通过系统将带有附件的邮件发送到用户预留的邮箱中。

如果当前只制作成功了其中一个文件(电子保单或电子发票)，系统会给用户发送制作好的文件，并提示“电子保单(或电子发票)下载成功，还有电子发票(或电子保单)未下载，请稍后注意查收邮件！”。

如果6小时内两个文件没有完全下载，仍会发送邮件告知用户未完成全部附件的下载，这个时候一般是保险公司的系统原因导致制作电子保单或电子发票较慢，会提醒用户第二天尝试下载或找客服请求保险公司加急制作电子文件。

在本申请的技术方案中，可以用Golang(是一种静态强类型、编译型、并发型，并具有垃圾回收功能的编程语言)实现系统开发，在通过实验测试后，保证系统稳定性的情况下，可使用go协程(goroutine)技术，用户请求下载的时候会直接返回提示用户电子保单或发票制作中，每个用户的请求都会生成一个go的协程，来执行下载任务。

每个用户的请求都会生成一个go的协程goroutine，来执行异步下载任务。goroutine类似Java的线程，但是消耗的资源非常少，一个goroutine消耗的内存大概是2KB，所以同时支持上万个协程的资源消耗也较低，因为保险代理平台对接不同的保险公司，考虑到保险公司系统支持并发的能力不同，不能没有限制的创建协程来处理下载任务，故而可以配置c1->n1(保险公司c1->最大线程数n1)。超过上限的任务，会添加到缓存redis中临时存储下来，等待执行。完成向保险公司请求制作电子文件、将文件存储到云存储、在mysql中存储用户对应文件的url的流程。这样等用户下次请求的时候，可以直接从云存储中下载文件，这样避免了对保险公司造成的压力。

在本申请的技术方案中，采用的文件传输方式是利用邮件发送压缩包，而非文件流；采用的处理机制是异步请求，而非同步请求；采用的重试机制是特定时间内系统自动重试，而不需要用户手动重新点击下载；并发量受消息队列的限制，不受带宽资源限制。

本方案通过“消息队列+邮件发送”的方式，来保证系统能够提供更加稳定的能力，在移动互联网时代，用户量越来越多，资源越来越稀缺，本方案将系统压力转移到消息队列的处理压力上，当前消息队列的处理能力已经是非常成熟的能力了，所以不存在太大的问题。另外加上一些辅助的柔性提示功能，就能够实现系统稳定性和用户体验上完美兼容。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

根据本申请实施例的另一个方面，还提供了一种用于实施上述文件的下载方法的文件的下载装置。图5是根据本申请实施例的一种可选的文件的下载装置的示意图，如图5所示，该装置可以包括：

接收单元51，用于接收第一终端的第一文件请求，其中，所述第一终端中登录有在业务平台上使用的第一帐号，所述第一文件请求用于所述第一帐号请求获取目标文件，所述目标文件中记录有所述第一帐号使用第一虚拟资源从所述业务平台换取的业务服务，所述业务服务用于表示在发生指定事件的情况下所述业务平台向第二帐号提供第二虚拟资源；

生成单元53，用于生成与所述第一文件请求对应的下载任务，并将所述下载任务加入至任务队列，其中，所述下载任务用于从所述业务平台下载所述目标文件。

下载单元55，用于按照所述下载任务在所述任务队列中的位置执行所述下载任务。

返回单元57，用于在所述下载任务执行成功的情况下，向所述第一终端返回所述目标文件。

需要说明的是，该实施例中的接收单元51可以用于执行本申请实施例中的步骤S302，该实施例中的生成单元53可以用于执行本申请实施例中的步骤S304，该实施例中的下载单元55可以用于执行本申请实施例中的步骤S306，该实施例中的返回单元57可以用于执行本申请实施例中的步骤S308。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图2所示的硬件环境中，可以通过软件实现，也可以通过硬件实现。

通过上述模块，将下载任务加入至任务队列，按照下载任务在任务队列中的位置执行下载任务；在下载任务执行成功的情况下，向第一终端返回目标文件，该方案可以通过任务队列释放用户并发请求的压力，由于任务队列始终是串行执行下载任务，从而可以将之前短时间内大量的并发请求转换为长时间连续的请求，也即可以控制到达下载接口的请求量，可以解决相关技术中文件下载请求的并发量较大的技术问题，进而达到降低并发量的技术效果。

可选地，下载单元还用于：在位于所述下载任务之前的任务执行完的情况下，从所述任务队列中取出所述下载任务；获取与所述下载任务匹配的链接地址，其中，所述链接地址为所述业务平台提供的；按照所述链接地址下载所述目标文件；在所述目标文件下载成功的情况下，将所述目标文件转存至存储器中。

可选地，生成单元还用于：将所述目标文件中每个文件的下载状态与所述下载任务关联后保存至所述任务队列，其中，所述下载状态在初始时为未下载。

可选地，下载单元还用于：在按照所述链接地址下载所述目标文件之后，在所述目标文件中存在下载失败的第一文件的情况下，将与所述下载任务关联的所述目标文件中第二文件的下载状态修改为已下载，并保持所述第一文件的下载状态为未下载，其中，所述第二文件为下载成功的文件；将修改下载状态后的所述下载任务重新加入到所述任务队列。

可选地，下载单元还用于：在按照下载任务在任务队列中的位置执行下载任务的过程中，在按照下载任务下载目标文件失败的情况下，将下载任务重新加入到任务队列中；从系数集合中选取目标系数，其中，系数集合中保存有预先确定的多个系数；将目标系数乘以参考延迟时长，得到第一延迟时长，并获取累计延迟时长，其中，累计延迟时长为下载任务每次已执行的延迟时长的累计和；在第一延迟时长与累计延迟时长之和，小于第一阈值的情况下，距离前一次执行下载任务的间隔时间达到第一延迟时长，再次执行下载任务；在第一延迟时长与累计延迟时长之和，不小于第一阈值的情况下，将第一阈值减去累计延迟时长，得到第二延迟时长，距离前一次执行下载任务的间隔时间达到第二延迟时长，再次执行下载任务。

可选地，下载单元还用于：在按照所述链接地址发送所述目标文件的下载请求后，接收返回的响应内容；按照所述响应内容中的下载地址访问目标网页，其中，所述目标网页用于下载所述目标文件；从所述目标网页下载所述目标文件；按照如下方式确定所述目标文件是否下载成功：获取所述目标文件的文件大小；在所述文件大小大于第二阈值的情况下，确定所述目标文件下载成功；在所述文件大小不大于所述第二阈值的情况下，确定所述目标文件下载失败。

可选地，下载单元还用于：将所述目标文件转存至存储器中包括：生成所述目标文件对应的数据对象，其中，所述数据对象包括用于标识所述目标文件的文件标识、所述目标文件、用于表示所述数据对象的存放方式和存放位置的元数据、用于描述所述数据对象的属性信息；将所述数据对象转存至所述存储器；

可选地，下载单元还用于：在向所述第一终端返回所述目标文件之后，接收第二终端的第二文件请求，所述第二文件请求用于请求获取所述目标文件；从所述存储器中获取所述目标文件；向所述第二终端返回所述目标文件。

可选地，本申请的装置还可包括：提示单元，用于在接收所述第一终端的所述第一文件请求之后，向所述第一终端发送第一提示信息，其中，所述第一提示信息用于提示所述目标文件预计在等待目标时长后下载成功；在所述目标文件中第一文件下载失败且第二文件下载成功的情况下，向所述第一终端发送第二提示信息，其中，所述第二提示信息用于提示所述第一文件未下载成功且所述第二文件下载成功；在所述目标文件中存在未下载成功的文件且等待时长达到所述目标时长之后，向所述第一终端发送第三提示信息，其中，所述第三提示信息用于提示所述目标文件中存在未下载成功的文件。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图2所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

根据本申请实施例的另一个方面，还提供了一种用于实施上述文件的下载方法的服务器或终端。

图6是根据本申请实施例的一种终端的结构框图，如图6所示，该终端可以包括：一个或多个(图6中仅示出一个)处理器601、存储器603、以及传输装置605，如图6所示，该终端还可以包括输入输出设备607。

其中，存储器603可用于存储软件程序以及模块，如本申请实施例中的文件的下载方法和装置对应的程序指令/模块，处理器601通过运行存储在存储器603内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的文件的下载方法。存储器603可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器603可进一步包括相对于处理器601远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

上述的传输装置605用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置605包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置605为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

其中，具体地，存储器603用于存储应用程序。

处理器601可以通过传输装置605调用存储器603存储的应用程序，以执行下述步骤：

接收第一终端的第一文件请求，其中，第一终端中登录有在业务平台上使用的第一帐号，第一文件请求用于第一帐号请求获取目标文件，目标文件中记录有第一帐号使用第一虚拟资源从业务平台换取的业务服务，业务服务用于表示在发生指定事件的情况下业务平台向第二帐号提供第二虚拟资源；

生成与第一文件请求对应的下载任务，并将下载任务加入至任务队列，其中，下载任务用于从业务平台下载目标文件；

按照下载任务在任务队列中的位置执行下载任务；

在下载任务执行成功的情况下，向第一终端返回目标文件。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图6所示的结构仅为示意，终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices，MID)、PAD等终端设备。图6其并不对上述电子装置的结构造成限定。例如，终端还可包括比图6中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图6所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(RandomAccess Memory，RAM)、磁盘或光盘等。

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行文件的下载方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

接收第一终端的第一文件请求，其中，第一终端中登录有在业务平台上使用的第一帐号，第一文件请求用于第一帐号请求获取目标文件，目标文件中记录有第一帐号使用第一虚拟资源从业务平台换取的业务服务，业务服务用于表示在发生指定事件的情况下业务平台向第二帐号提供第二虚拟资源；

生成与第一文件请求对应的下载任务，并将下载任务加入至任务队列，其中，下载任务用于从业务平台下载目标文件；

按照下载任务在任务队列中的位置执行下载任务；

在下载任务执行成功的情况下，向第一终端返回目标文件。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种文件的下载方法，其特征在于，包括：

接收第一终端的第一文件请求，其中，所述第一终端中登录有在业务平台上使用的第一帐号，所述第一文件请求用于所述第一帐号请求获取目标文件，所述目标文件中记录有所述第一帐号使用第一虚拟资源从所述业务平台换取的业务服务，所述业务服务用于表示在发生指定事件的情况下所述业务平台向第二帐号提供第二虚拟资源；

生成与所述第一文件请求对应的下载任务，并将所述下载任务加入至任务队列，其中，所述下载任务用于从所述业务平台下载所述目标文件；

按照所述下载任务在所述任务队列中的位置执行所述下载任务；

在所述下载任务执行成功的情况下，向所述第一终端返回所述目标文件。

2.根据权利要求1所述的方法，其特征在于，按照所述下载任务在所述任务队列中的位置执行所述下载任务包括：

在位于所述下载任务之前的任务执行完的情况下，从所述任务队列中取出所述下载任务；

获取与所述下载任务匹配的链接地址，其中，所述链接地址为所述业务平台提供的；

按照所述链接地址下载所述目标文件；

在所述目标文件下载成功的情况下，将所述目标文件转存至存储器中。

3.根据权利要求1所述的方法，其特征在于，在按照所述下载任务在所述任务队列中的位置执行所述下载任务的过程中，所述方法还包括：

在按照所述下载任务下载所述目标文件失败的情况下，将所述下载任务重新加入到所述任务队列中；

从系数集合中选取目标系数，其中，所述系数集合中保存有预先确定的多个系数；

将所述目标系数乘以参考延迟时长，得到第一延迟时长，并获取累计延迟时长，其中，所述累计延迟时长为所述下载任务每次已执行的延迟时长的累计和；

在所述第一延迟时长与所述累计延迟时长之和，小于第一阈值的情况下，距离前一次执行所述下载任务的间隔时间达到所述第一延迟时长，再次执行所述下载任务；

在所述第一延迟时长与所述累计延迟时长之和，不小于所述第一阈值的情况下，将所述第一阈值减去所述累计延迟时长，得到第二延迟时长，距离前一次执行所述下载任务的间隔时间达到所述第二延迟时长，再次执行所述下载任务。

4.根据权利要求2或3所述的方法，其特征在于，

所述方法还包括：按照如下方式将所述下载任务加入至所述任务队列中：将所述目标文件中每个文件的下载状态与所述下载任务关联后保存至所述任务队列，其中，所述下载状态在初始时为未下载；

在按照链接地址下载所述目标文件之后，所述方法还包括：在所述目标文件中存在下载失败的第一文件的情况下，将与所述下载任务关联的所述目标文件中第二文件的下载状态修改为已下载，并保持所述第一文件的下载状态为未下载，其中，所述第二文件为下载成功的文件；将修改下载状态后的所述下载任务重新加入到所述任务队列。

5.根据权利要求2所述的方法，其特征在于，

按照所述下载任务在所述任务队列中的位置执行所述下载任务包括：在按照所述链接地址发送所述目标文件的下载请求后，接收返回的响应内容；按照所述响应内容中的下载地址访问目标网页，其中，所述目标网页用于下载所述目标文件；从所述目标网页下载所述目标文件；

所述方法还包括按照如下方式确定所述目标文件是否下载成功：获取所述目标文件的文件大小；在所述文件大小大于第二阈值的情况下，确定所述目标文件下载成功；在所述文件大小不大于所述第二阈值的情况下，确定所述目标文件下载失败。

6.根据权利要求2所述的方法，其特征在于，

将所述目标文件转存至存储器中包括：生成所述目标文件对应的数据对象，其中，所述数据对象包括用于标识所述目标文件的文件标识、所述目标文件、用于表示所述数据对象的存放方式和存放位置的元数据、用于描述所述数据对象的属性信息；将所述数据对象转存至所述存储器；

在向所述第一终端返回所述目标文件之后，所述方法还包括：接收第二终端的第二文件请求，所述第二文件请求用于请求获取所述目标文件；从所述存储器中获取所述目标文件；向所述第二终端返回所述目标文件。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括以下至少之一：

在接收所述第一终端的所述第一文件请求之后，向所述第一终端发送第一提示信息，其中，所述第一提示信息用于提示所述目标文件预计在等待目标时长后下载成功；

在所述目标文件中第一文件下载失败且第二文件下载成功的情况下，向所述第一终端发送第二提示信息，其中，所述第二提示信息用于提示所述第一文件未下载成功且所述第二文件下载成功；

在所述目标文件中存在未下载成功的文件且等待时长达到所述目标时长之后，向所述第一终端发送第三提示信息，其中，所述第三提示信息用于提示所述目标文件中存在未下载成功的文件。

8.一种文件的下载装置，其特征在于，包括：

接收单元，用于接收第一终端的第一文件请求，其中，所述第一终端中登录有在业务平台上使用的第一帐号，所述第一文件请求用于所述第一帐号请求获取目标文件，所述目标文件中记录有所述第一帐号使用第一虚拟资源从所述业务平台换取的业务服务，所述业务服务用于表示在发生指定事件的情况下所述业务平台向第二帐号提供第二虚拟资源；

生成单元，用于生成与所述第一文件请求对应的下载任务，并将所述下载任务加入至任务队列，其中，所述下载任务用于从所述业务平台下载所述目标文件；

下载单元，用于按照所述下载任务在所述任务队列中的位置执行所述下载任务；

返回单元，用于在所述下载任务执行成功的情况下，向所述第一终端返回所述目标文件。

9.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，所述程序运行时执行上述权利要求1至7任一项中所述的方法。

10.一种电子装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器通过所述计算机程序执行上述权利要求1至7任一项中所述的方法。

Images