文件上传方法、装置、终端、服务器、系统及存储介质
技术领域
本发明涉及文件上传技术领域,尤其涉及一种文件上传方法、装置、终端、服务器、系统及存储介质。
背景技术
随着互联网技术及移动设备的普及,人们创造和分享的信息量日益增加。网络存储,如网盘、云盘等各种应用程序,可以为用户提供只需一次上传,即可在多种终端上随时进行数据访问的高效信息处理方式。目前,各种应用程序各自为阵,采用不同的文件上传方法将文件存储在各自的服务器中,这种方式既不利于扩展和管理,同时也会造成大量重复数据。这些重复数据的存在,一方面在其上传过程中占用了大量网络带宽,另一方面对网络存储服务器造成了不必要的压力。
发明内容
本发明的目的在于提供一种文件上传方法、装置、终端、服务器、系统及存储介质,以解决上述背景技术中提出的问题。
根据本发明的一个方面,提供一种文件上传方法,所述方法应用于应用端,包括:
向服务端发起通道获取请求,接收服务端返回的文件上传服务节点地址;
计算待上传文件的哈希值,向所述文件上传服务节点发起秒传请求,所述秒传请求携带有待上传文件的哈希值;
若秒传成功,则接收所述文件上传服务节点返回的统一存储ID;
若秒传失败,则对待上传文件进行分片,得到若干分片,将所有分片上传至所述文件上传服务节点,待所有分片上传成功后,接收所述文件上传服务节点返回的统一存储ID;
将所述统一存储ID与所述上传文件的文件参数信息进行关联存储。
在本发明的一个实施例中,所述计算待上传文件的哈希值具体为:
判断待上传文件大小是否超过阈值;
如果是,读取待上传文件头部阈值大小的数据和尾部阈值大小的数据,将头部阈值大小的数据和尾部阈值大小的数据进行合并,计算合并后数据的哈希值;
如果否,则计算整个待上传文件的哈希值。
在本发明的一个实施例中,所述文件参数信息包括文件名、文件大小和文件类型。
在本发明的一个实施例中,获取待上传文件的MIME类型信息,将所述MIME类型信息发送至服务端。
在本发明的一个实施例中,所述通道获取请求携带有任务类别,所述任务类别包括普通任务和VIP任务。
根据本发明的一个方面,提供一种文件上传的方法,所述方法应用于服务端,包括:
接收应用端发起的通道获取请求,根据各上传服务节点的负载情况分配一空闲的文件上传服务节点,将所述文件上传服务节点地址返回至应用端;
接收应用端发起的秒传请求,将所述秒传请求中携带的哈希值与服务端中已存储文件的哈希值进行匹配;
若匹配成功,则获取匹配成功的文件的统一存储ID返回至应用端;
若匹配失败,则接收应用端发送的分片数据,将各分片数据组装成一个完整的文件,生成一统一存储ID,将所述统一存储ID返回至应用端。
在本发明的一个实施例中,所述方法还包括:
将所述完整的文件转存到对象存储服务中,接收对象存储服务返回的文件存储地址。
在本发明的一个实施例中,所述方法还包括:
将统一存储ID、文件哈希值和文件存储地址进行关联存储。
在本发明的一个实施例中,所述服务端包含有普通上传服务集群和VIP上传服务集群,所述通道获取请求携带有任务类别,所述任务类别包括普通任务和VIP任务,所述方法还包括:
若通道获取请求中的任务类别为普通任务,则获取普通上传服务集群中空闲的文件上传服务节点地址返回给应用端;
若通道获取请求中的任务类别为VIP任务,则获取VIP上传服务集群中空闲的文件上传服务节点地址返回给应用端。
根据本发明的一个方面,提供一种文件上传装置,包括:
通道获取模块,用于向服务端发起通道获取请求,接收服务端返回的文件上传服务节点地址;
秒传检测模块,用于计算待上传文件的哈希值,向所述文件上传服务节点发起秒传请求,所述秒传请求携带有待上传文件的哈希值;若秒传成功,则接收所述文件上传服务节点返回的统一存储ID;
切片上传模块,用于当秒传失败时,对待上传文件进行分片,得到若干分片,将所有分片上传至所述文件上传服务节点,待所有分片上传成功后,接收所述文件上传服务节点返回的统一存储ID。
信息存储模块,用于将所述统一存储ID与上传文件的文件ID进行关联存储。
在本发明的一个实施例中,所述文件上传装置用于执行实现上述任一项所述应用于应用端的文件上传方法的操作。
根据本发明的一个方面,提供一种终端,包括:
一个或多个处理器;
存储器,用于存储一个或多个程序,
当所述一个或多个程序被所述一个或多个处理器执行时,使得一个或多个处理器实现上述任一项所述应用于应用端的文件上传方法。
根据本发明的一个方面,提供一种文件上传装置,包括:
通道分配模块,用于接收应用端发起的通道获取请求,根据各上传服务节点的负载情况分配一空闲的文件上传服务节点,将所述文件上传服务节点地址返回至应用端;
秒传处理模块,用于接收应用端发起的秒传请求,将所述秒传请求中携带的哈希值与服务端中已存储文件的哈希值进行匹配;若匹配成功,则获取匹配成功的文件的统一存储ID返回至应用端;
上传处理模块,用于当哈希值匹配失败时,接收应用端发送的分片数据,将各分片数据组装成一个完整的文件,生成一统一存储ID,将所述统一存储ID返回至应用端。
在本发明的一个实施例中,所述文件上传装置用于执行实现上述任一项所述应用于服务端的文件上传方法的操作。
根据本发明的一个方面,提供一种服务器,包括:
一个或多个处理器;
存储器,用于存储一个或多个程序,
当所述一个或多个程序被所述一个或多个处理器执行时,使得一个或多个处理器实现上述任一项所述应用于服务端的文件上传方法。
根据本发明的一个方面,提供一种文件上传系统,所述系统包括一个或多个上述所述的终端和一个或多个上述所述的服务器,所述终端通过运行在其上的应用程序与所述服务器进行交互。
根据本发明的一个方面,提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现上述任一项所述应用于应用端的文件上传方法,或上述任一项所述应用于服务端的文件上传方法。
实施本发明实施例,将具有如下有益效果:
本发明实施例中应用端向服务端获取通道后,建立与文件上传服务节点的通讯。先对待上传文件先进行秒传检测,若秒传成功,则接收该待上传文件在服务端的统一存储ID;若秒传不成功,再进行切片上传,服务端将所有分片合成一个完整的文件后生成统一存储ID,将该统一存储ID返回给应用端;应用端将每个上传文件的统一存储ID与相应的文件参数信息进行关联保存;服务端将完整的文件转存到对象存储服务,对象存储服务返回文件存储地址给服务端,服务端将统一存储ID、文件哈希值、文件存储地址等关键信息进行关联保存。采用本发明的文件上传方法,使得所有非文件下载的文件访问业务可在各第三方应用的自身系统内处理,当处理文件下载业务时,只需向服务端传送统一存储ID即可将文件下载到本地,既保证了各第三方应用的业务独立性,又提高了文件上传下载的效率;服务端不对文件进行实质存储,仅存储上传或下载文件所需的关键信息,简化了服务端对文件的管理,同时避免了大量重复数据产生的网络带宽压力问题和存储压力问题的发生。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
其中:
图1为本发明实施例中一种文件上传方法的实施环境示意图;
图2为本发明一个实施例中一种文件上传方法的流程图;
图3为本发明另一个实施例中一种文件上传方法的流程图;
图4为本发明一个实施例中一种文件上传装置的结构图;
图5为本发明一个实施例中一种终端的结构图;
图6为本发明另一个实施例中一种文件上传装置的结构图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
如图1所示为本发明实施例中一种文件上传方法的实施环境示意图。该实施环境包括终端100和服务端200。
终端100可以是智能手机、平板电脑、笔记本电脑、台式电脑或者其他可运行应用程序的电子设备。应用端为运行在终端100上,预设有与服务端200进行对接实现文件上传功能的应用程序,如网盘、云盘、即时通讯等。
通过终端100与服务端200交互,用户在应用端对待上传文件发起文件上传指令,应用端将待上传文件秒传或切片上传至服务端200,得到上传文件的统一存储ID,将统一存储ID与文件参数信息进行关联存储。服务端200处理文件秒传和切片上传业务,为上传文件生成统一存储ID,并将完整的文件转存到对象存储服务中,维护一张秒传和下载所需的文件关键信息表实现各第三方应用发起的文件秒传和切片上传业务。
如图2所示,为本发明一个实施例中一种文件上传方法的流程图。优选的,该文件上传方法由应用端进行执行,该方法包括以下步骤:
步骤S201,向服务端发起通道获取请求,接收服务端返回的文件上传服务节点地址。
在本发明的一个实施例中,应用端在向服务端发起通道获取请求之前,将应用ID和密钥发送到服务端,服务端对其进行认证,若认证通过,则分配一个访问令牌给应用端。应用端在发起的通道获取请求中携带该访问令牌。
服务端根据通道获取请求为其分配空闲的通道,并将通道所在文件上传服务节点的地址返回给应用端。
在本发明的一个实施例中,所述通道获取请求携带有任务类别,所述任务类别包括普通任务和VIP任务。服务端在接收到通道获取请求之后,还用于根据任务类别,分配不同类型的文件上传服务节点给应用端。
步骤S202,计算待上传文件的哈希值,向所述文件上传服务节点发起秒传请求,所述秒传请求携带有待上传文件的哈希值。
计算待上传文件的哈希值是为了与服务端已存储的文件进行快速匹配,判断是否存在相同的文件。原文件一般很大,将整个原文件与服务端的每个文件进行比较是不现实的。方便起见,一般通过计算待上传文件的哈希值,将待上传文件的哈希值与服务端已存储文件的哈希值进行比较来确定服务端是否存在相同文件。
在本发明的一个实施例中,计算待上传文件的哈希值具体为:
判断待上传文件大小是否超过阈值;
如果是,读取待上传文件头部阈值大小的数据和尾部阈值大小的数据,将头部阈值大小的数据和尾部阈值大小的数据进行合并,计算合并后数据的哈希值;
如果否,则计算整个待上传文件的哈希值。
具体的,假设阈值为64KB,则如果文件大小少于64KB,则计算整个文件的哈希值,如果文件大于64KB,则获取从文件头开始的64KB和从文件尾往前的64KB,将二者合并在一起,再计算这个合并文件的哈希值。
步骤S203,若秒传成功,则接收所述文件上传服务节点返回的统一存储ID。
若秒传成功,表示服务端已存储有待上传文件,则应用端不需将待上传文件上传至服务端。
步骤S204,若秒传失败,则对待上传文件进行分片,得到若干分片,将所有分片上传至所述文件上传服务节点,待所有分片上传成功后,接收所述文件上传服务节点返回的统一存储ID。
若秒传失败,表示服务端未存储有待上传文件,则应用端按照预设的分片大小对待上传文件进行切片,得到若干分片。优先的,应用端按照分片顺序将各分片依次上传至文件上传服务节点,应用端在上传分片的时候携带有文件名、分片序号、分片总数、文件哈希值和分片数据流等信息,其中,分片数据流为二进制数据流。当所有的分片都完成上传后,应用端发送一个完成上传消息至文件上传服务节点,该完成上传消息中携带有文件名、文件哈希值、文件大小、文件MIME(Multipurpose Internet Mail Extensions,多用途互联网邮件扩展)类型信息等。多用途互联网邮件扩展,它是一个互联网标准,在1992年最早应用于电子邮件系统,但后来也应用到浏览器。服务器会将它们发送的多媒体数据的类型告诉浏览器,而通知手段就是说明该多媒体数据的MIME类型,从而让浏览器知道接收到的信息哪些是MP3文件,哪些是Shockwave文件等等。因此,应用端通过调用浏览器API(Application Programming Interface,应用程序编程接口)可以获取到待上传文件的MIME类型信息。每个MIME类型由两部分组成,前面是数据的大类别,例如声音audio、图象image等,后面定义具体的种类。如超文本标记语言文本的MIME类型为text/html,PNG图像的MIME类型为image/png。
文件上传服务节点根据应用端发送的分片数据、分片序号和分片总数组装成一个完整的文件。若文件上传服务节点在合并文件的时候,发现其中某个分片上传失败,则文件上传服务节点通知应用端对缺失的分片进行补片,应用端获取相应的分片发送至文件上传服务节点。
步骤S205,将统一存储ID与上传文件的文件参数信息进行关联存储。
不论是秒传还是切片上传,应用端在接收到统一存储ID后,都将统一存储ID与上传文件的文件参数信息进行关联存储。
在本发明的一个实施例中,该文件参数信息包括文件的基本信息,如文件名、文件大小和文件类型、MIME类型等。优选的,该文件参数信息还可包括与文件相关的业务信息,如文件所属用户ID、文件的目录结构信息和文件分类信息,其中,文件的目录结构信息可包括当前节点ID和父节点ID,文件分类信息主要涉及到资源的具体分类,如果是学习资源,则可以按学科、年级等进行分类,如果是影片,可以按喜剧、爱情剧、国产剧、美剧等进行分类。在实际应用中,应用端根据自己的需求对文件参数信息进行具体的设置,本发明不做限制。
上述实施例中应用端向服务端获取通道后,建立与文件上传服务节点的通讯。先对待上传文件先进行秒传检测,若秒传成功,则接收该待上传文件在服务端的统一存储ID;若秒传不成功,再进行切片上传,服务端将所有分片合成一个完整的文件后生成统一存储ID,将该统一存储ID返回给应用端;应用端将每个上传文件的统一存储ID与相应的文件参数信息进行关联保存;服务端将完整的文件转存到对象存储服务,对象存储服务返回文件存储地址给服务端,服务端将统一存储ID、文件哈希值、文件存储地址等关键信息进行关联保存。采用本发明的文件上传方法,使得所有非文件下载的文件访问业务可在各第三方应用的自身系统内处理,当处理文件下载业务时,只需向服务端传送统一存储ID即可将文件下载到本地,既保证了各第三方应用的业务独立性,又提高了文件上传下载的效率;服务端不对文件进行实质存储,仅存储上传或下载文件所需的关键信息,简化了服务端对文件的管理,同时避免了大量重复数据产生的网络带宽压力问题和存储压力问题的发生。
如图3所示,为本发明另一个实施例中一种文件上传方法的流程图。优选的,该文件上传方法由服务端进行执行,该方法包括以下步骤:
步骤S301,接收应用端发起的通道获取请求,根据各上传服务节点的负载情况分配一空闲的文件上传服务节点,将所述文件上传服务节点地址返回至应用端。
在本发明的一个实施例中,服务端在接收第三方应用发送的通道获取请求之前,接收第三方应用发送的认证请求,该认证请求携带有应用ID和密钥,服务端对其进行认证,若认证通过,则分配一个访问令牌给应用端。应用端在发起的通道获取请求中携带该访问令牌。
一般情况下,服务端包含一个或多个服务器,每个服务器对应为一个文件上传服务节点,每个文件上传服务节点包含多个通道。服务端接收到应用端发起的通道获取请求后,生成相应的通道请求任务加入到队列中,调度服务对队列中的各通道请求任务按照排队顺序进行一一处理。具体的,根据各文件上传服务节点的负载情况和预设的负载均衡策略,为每个通道获取请求分配位于同一文件上传服务节点的一个或多个空闲通道,并将空闲通道所属的文件上传服务节点返回给应用端。
在本发明的一个实施例中,服务端中各文件上传服务节点分成两类,一类为普通上传服务集群,另一类为VIP上传服务集群。服务端对通道获取请求携带有任务类别进行判断,若通道获取请求中的任务类别为普通任务,则获取普通上传服务集群中空闲的文件上传服务节点地址返回给应用端;若通道获取请求中的任务类别为VIP任务,则获取VIP上传服务集群中空闲的文件上传服务节点地址返回给应用端。
步骤S302,接收应用端发起的秒传请求,将所述秒传请求中携带的哈希值与服务端已存储文件的哈希值进行匹配。
具体的,服务端保存有一张文件信息记录表,所述文件信息记录表用于记录每个上传文件的关键信息,该关键信息至少包括统一存储ID、文件哈希值和文件存储地址,还可包括文件大小、文件类型、MIME类型、文件上传时间等。通过将秒传请求中的哈希值与服务端已存储文件的哈希值进行匹配,可以确定服务端是否存储有与待上传文件相同的文件。
步骤S303,若匹配成功,则获取匹配成功的文件的统一存储ID返回至应用端。
若匹配成功,则表示秒传成功,服务端将匹配成功的文件的统一存储ID返回至应用端,由应用端将统一存储ID与待上传文件的文件参数信息进行关联保存,服务端对于秒传的文件不做记录。
步骤S304,若匹配失败,则接收应用端发送的分片数据,将各分片数据组装成一个完整的文件,生成一统一存储ID,将所述统一存储ID返回至应用端。
若匹配失败,文件上传服务节点根据应用端发送的分片序号、分片总数、文件哈希值和分片数据流将各分片组装成一个完整的文件。若文件上传服务节点在合并文件的时候,发现其中某个分片上传失败,则文件上传服务节点通知应用端对缺失的分片进行补片,应用端获取相应的分片发送至文件上传服务节点。
在本发明的一个实施例中,文件上传服务节点接收应用端发送的文件上传完成的消息,该完成上传消息中携带有文件名、文件哈希值、文件大小、MIME类型信息等。文件上传服务节点根据MIME类型信息确定出上传文件的文件类型信息。比如,MIME类型为text/html,其文件类型为html,MIME类型为application/msword,其文件类型为doc。
在本发明的一个实施例中,文件上传服务节点将完整的文件转存到对象存储服务中。对象存储服务存储成功之后,返回文件存储地址到文件上传服务节点。
具体的,服务端针对每个文件设置有转存标志,在未接收到对象存储服务返回的文件存储地址之前,该转存标志设置为0;接收到对象存储服务返回的文件存储地址之后,该转存标志设置为1。
在本发明的一个实施例中,文件上传服务节点将统一存储ID、文件哈希值和文件存储地址进行关联存储。具体的,文件上传服务节点为上传文件生成一条文件信息记录并进行保存,所述文件信息记录至少包括统一存储ID、文件哈希值和文件存储地址,还可包括文件大小、转存标志、MIME类型、文件类型、文件上传时间等。
上述实施例中应用端向服务端获取通道后,建立与文件上传服务节点的通讯。先对待上传文件先进行秒传检测,若秒传成功,则接收该待上传文件在服务端的统一存储ID;若秒传不成功,再进行切片上传,服务端将所有分片合成一个完整的文件后生成统一存储ID,将该统一存储ID返回给应用端;应用端将每个上传文件的统一存储ID与相应的文件参数信息进行关联保存;服务端将完整的文件转存到对象存储服务,对象存储服务返回文件存储地址给服务端,服务端将统一存储ID、文件哈希值、文件存储地址等关键信息进行关联保存。采用本发明的文件上传方法,使得所有非文件下载的文件访问业务可在各第三方应用的自身系统内处理,当处理文件下载业务时,只需向服务端传送统一存储ID即可将文件下载到本地,既保证了各第三方应用的业务独立性,又提高了文件上传下载的效率;服务端不对文件进行实质存储,仅存储上传或下载文件所需的关键信息,简化了服务端对文件的管理,同时避免了大量重复数据产生的网络带宽压力问题和存储压力问题的发生。
如图4为本发明一个实施例中一种文件上传装置的结构图。优选的,所述文件上传装置部署在应用端,包括通道获取模块41、秒传检测模块42、切片上传模块43和信息存储模块44,其中:
通道获取模块41,用于向服务端发起通道获取请求,接收服务端返回的文件上传服务节点地址;
秒传检测模块42,用于计算待上传文件的哈希值,向所述文件上传服务节点发起秒传请求,所述秒传请求携带有待上传文件的哈希值;若秒传成功,则接收所述文件上传服务节点返回的统一存储ID;
切片上传模块43,用于当秒传失败时,对待上传文件进行分片,得到若干分片,将所有分片上传至所述文件上传服务节点,待所有分片上传成功后,接收所述文件上传服务节点返回的统一存储ID。
信息存储模块44,用于将所述统一存储ID与上传文件的文件ID进行关联存储。
在本发明的一个实施例中,应用端在向服务端发起通道获取请求之前,将应用ID和密钥发送到服务端,服务端对其进行认证,若认证通过,则分配一个访问令牌给应用端。应用端在发起的通道获取请求中携带该访问令牌。
服务端根据通道获取请求为其分配空闲的通道,并将通道所在文件上传服务节点的地址返回给应用端。
在本发明的一个实施例中,所述通道获取请求携带有任务类别,所述任务类别包括普通任务和VIP任务。服务端在接收到通道获取请求之后,还用于根据任务类别,分配不同类型的文件上传服务节点给应用端。
计算待上传文件的哈希值是为了与服务端已存储的文件进行快速匹配,判断是否存在相同的文件。原文件一般很大,将整个原文件与服务端的每个文件进行比较是不现实的。方便起见,一般通过计算待上传文件的哈希值,将待上传文件的哈希值与服务端已存储文件的哈希值进行比较来确定服务端是否存在相同文件。
在本发明的一个实施例中,计算待上传文件的哈希值具体为:
判断待上传文件大小是否超过阈值;
如果是,读取待上传文件头部阈值大小的数据和尾部阈值大小的数据,将头部阈值大小的数据和尾部阈值大小的数据进行合并,计算合并后数据的哈希值;
如果否,则计算整个待上传文件的哈希值。
具体的,假设阈值为64KB,则如果文件大小少于64KB,则计算整个文件的哈希值,如果文件大于64KB,则获取从文件头开始的64KB和从文件尾往前的64KB,将二者合并在一起,再计算这个合并文件的哈希值。
若秒传成功,表示服务端已存储有待上传文件,则应用端不需将待上传文件上传至服务端。
若秒传失败,表示服务端未存储有待上传文件,则应用端按照预设的分片大小对待上传文件进行切片,得到若干分片。优先的,应用端按照分片顺序将各分片依次上传至文件上传服务节点,应用端在上传分片的时候携带有文件名、分片序号、分片总数、文件哈希值和分片数据流等信息,其中,分片数据流为二进制数据流。当所有的分片都完成上传后,应用端发送一个完成上传消息至文件上传服务节点,该完成上传消息中携带有文件名、文件哈希值、文件大小、文件MIME(Multipurpose Internet Mail Extensions,多用途互联网邮件扩展)类型信息等。多用途互联网邮件扩展,它是一个互联网标准,在1992年最早应用于电子邮件系统,但后来也应用到浏览器。服务器会将它们发送的多媒体数据的类型告诉浏览器,而通知手段就是说明该多媒体数据的MIME类型,从而让浏览器知道接收到的信息哪些是MP3文件,哪些是Shockwave文件等等。因此,应用端通过调用浏览器API(Application Programming Interface,应用程序编程接口)可以获取到待上传文件的MIME类型信息。每个MIME类型由两部分组成,前面是数据的大类别,例如声音audio、图象image等,后面定义具体的种类。如超文本标记语言文本的MIME类型为text/html,PNG图像的MIME类型为image/png。
文件上传服务节点根据应用端发送的分片数据、分片序号和分片总数组装成一个完整的文件。若文件上传服务节点在合并文件的时候,发现其中某个分片上传失败,则文件上传服务节点通知应用端对缺失的分片进行补片,应用端获取相应的分片发送至文件上传服务节点。
不论是秒传还是切片上传,应用端在接收到统一存储ID后,都将统一存储ID与上传文件的文件参数信息进行关联存储。
在本发明的一个实施例中,所述文件上传装置用于执行实现如上述图2实施例所述的文件上传方法的操作。
上述实施例中应用端向服务端获取通道后,建立与文件上传服务节点的通讯。先对待上传文件先进行秒传检测,若秒传成功,则接收该待上传文件在服务端的统一存储ID;若秒传不成功,再进行切片上传,服务端将所有分片合成一个完整的文件后生成统一存储ID,将该统一存储ID返回给应用端;应用端将每个上传文件的统一存储ID与相应的文件参数信息进行关联保存;服务端将完整的文件转存到对象存储服务,对象存储服务返回文件存储地址给服务端,服务端将统一存储ID、文件哈希值、文件存储地址等关键信息进行关联保存。采用本发明的文件上传方法,使得所有非文件下载的文件访问业务可在各第三方应用的自身系统内处理,当处理文件下载业务时,只需向服务端传送统一存储ID即可将文件下载到本地,既保证了各第三方应用的业务独立性,又提高了文件上传下载的效率;服务端不对文件进行实质存储,仅存储上传或下载文件所需的关键信息,简化了服务端对文件的管理,同时避免了大量重复数据产生的网络带宽压力问题和存储压力问题的发生。
如图5所示为本发明一个实施例中一种终端的结构图,图5所示的终端500仅仅是一个示例,不应对本发明实施例的功能和使用范围带来任何限制。如图5所示,终端500以通用计算设备的形式表现。终端500的组件可以包括但不限于:一个或者多个处理器或者处理单元51,系统存储器52,连接不同系统组件(包括系统存储器52和处理单元51)的总线55。总线55表示几类总线结构中的一种或多种,包括存储器总线或者存储器控制器,外围总线,图形加速端口,处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说,这些体系结构包括但不限于工业标准体系结构(ISA)总线,微通道体系结构(MAC)总线,增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。
终端500典型地包括多种计算机系统可读介质。这些介质可以是任何能够被终端访问的可用介质,包括易失性和非易失性介质,可移动的和不可移动的介质。
系统存储器52可以包括易失性存储器形式的计算机系统可读介质,例如随机存取存储器(RAM)521和/或高速缓存存储器522。终端500可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例,存储系统523可以用于读写不可移动的、非易失性磁介质(图5未显示,通常称为“硬盘驱动器”)。尽管图5中未示出,可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器,以及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下,每个驱动器可以通过一个或者多个数据介质接口与总线55相连。存储器52可以包括至少一个程序产品,该程序产品具有一组(例如至少一个)程序模块,这些程序模块被配置以执行本发明各实施例的功能。
具有一组(至少一个)程序模块58的程序/实用工具56,可以存储在例如存储器52中,这样的程序模块58包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块58通常执行本发明所描述的实施例中的功能和/或方法。
终端500也可以与一个或多个外部设备700(例如键盘、指向设备、显示器600、摄像头等)通信,还可与一个或者多个使得用户能与该终端500交互的设备通信,和/或与使得该终端500能与一个或多个其它计算设备进行通信的任何设备(例如网卡,调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口53进行。并且,终端500还可以通过网络适配器54与一个或者多个网络(例如局域网(LAN),广域网(WAN)和/或公共网络,例如因特网)通信。如图所示,网络适配器54通过总线55与终端500的其它模块通信。应当明白,尽管图5中未示出,可以结合终端500使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
处理单元51通过运行存储在系统存储器52中的程序,从而执行各种功能应用以及数据处理,实现本发明实施例2所述的文件上传方法,例如:对待上传的文件先进行秒传检测,若秒传成功,接收服务端返回的统一存储ID;若秒传失败,则对待上传文件进行分片,得到若干分片,将所有分片上传至文件上传服务节点,待所有分片上传成功后,接收文件上传服务节点返回的统一存储ID;将所述统一存储ID与上传文件的文件参数信息进行关联存储。
如图6为本发明另一个实施例中一种文件上传装置的结构图。优选的,所述文件上传装置部署在服务端,包括通道分配模块61、秒传处理模块62、上传处理模块63,其中:
通道分配模块61,用于接收应用端发起的通道获取请求,根据各上传服务节点的负载情况分配一空闲的文件上传服务节点,将所述文件上传服务节点地址返回至应用端;
秒传处理模块62,用于接收应用端发起的秒传请求,将所述秒传请求中携带的哈希值与服务端中已存储文件的哈希值进行匹配;若匹配成功,则获取匹配成功的文件的统一存储ID返回至应用端;
上传处理模块63,用于当哈希值匹配失败时,接收应用端发送的分片数据,将各分片数据组装成一个完整的文件,生成一统一存储ID,将所述统一存储ID返回至应用端。
在本发明的一个实施例中,服务端在接收第三方应用发送的通道获取请求之前,接收第三方应用发送的认证请求,该认证请求携带有应用ID和密钥,服务端对其进行认证,若认证通过,则分配一个访问令牌给应用端。应用端在发起的通道获取请求中携带该访问令牌。
一般情况下,服务端包含一个或多个服务器,每个服务器对应为一个文件上传服务节点,每个文件上传服务节点包含多个通道。服务端接收到应用端发起的通道获取请求后,生成相应的通道请求任务加入到队列中,调度服务对队列中的各通道请求任务按照排队顺序进行一一处理。具体的,根据各文件上传服务节点的负载情况和预设的负载均衡策略,为每个通道获取请求分配位于同一文件上传服务节点的一个或多个空闲通道,并将空闲通道所属的文件上传服务节点返回给应用端。
在本发明的一个实施例中,服务端中各文件上传服务节点分成两类,一类为普通上传服务集群,另一类为VIP上传服务集群。服务端对通道获取请求携带有任务类别进行判断,若通道获取请求中的任务类别为普通任务,则获取普通上传服务集群中空闲的文件上传服务节点地址返回给应用端;若通道获取请求中的任务类别为VIP任务,则获取VIP上传服务集群中空闲的文件上传服务节点地址返回给应用端。
具体的,服务端保存有一张文件信息记录表,所述文件信息记录表用于记录每个上传文件的关键信息,该关键信息至少包括统一存储ID、文件哈希值和文件存储地址,还可包括文件大小、文件类型、MIME类型、文件上传时间等。通过将秒传请求中的哈希值与服务端已存储文件的哈希值进行匹配,可以确定服务端是否存储有与待上传文件相同的文件。
若匹配成功,则表示秒传成功,服务端将匹配成功的文件的统一存储ID返回至应用端,由应用端将统一存储ID与待上传文件的文件参数信息进行关联保存,服务端对于秒传的文件不做记录。
若匹配失败,文件上传服务节点根据应用端发送的分片序号、分片总数、文件哈希值和分片数据流将各分片组装成一个完整的文件。若文件上传服务节点在合并文件的时候,发现其中某个分片上传失败,则文件上传服务节点通知应用端对缺失的分片进行补片,应用端获取相应的分片发送至文件上传服务节点。
在本发明的一个实施例中,文件上传服务节点接收应用端发送的文件上传完成的消息,该完成上传消息中携带有文件名、文件哈希值、文件大小、MIME类型信息等。文件上传服务节点根据MIME类型信息确定出上传文件的文件类型信息。比如,MIME类型为text/html,其文件类型为html,MIME类型为application/msword,其文件类型为doc。
在本发明的一个实施例中,文件上传服务节点将完整的文件转存到对象存储服务中。对象存储服务存储成功之后,返回文件存储地址到文件上传服务节点。
具体的,服务端针对每个文件设置有转存标志,在未接收到对象存储服务返回的文件存储地址之前,该转存标志设置为0;接收到对象存储服务返回的文件存储地址之后,该转存标志设置为1。
在本发明的一个实施例中,文件上传服务节点将统一存储ID、文件哈希值和文件存储地址进行关联存储。具体的,文件上传服务节点为上传文件生成一条文件信息记录并进行保存,所述文件信息记录至少包括统一存储ID、文件哈希值和文件存储地址,还可包括文件大小、转存标志、MIME类型、文件类型、文件上传时间等。
在本发明的一个实施例中,所述文件上传装置用于执行实现如上述图3实施例所述的文件上传方法的操作。
上述实施例中应用端向服务端获取通道后,建立与文件上传服务节点的通讯。先对待上传文件先进行秒传检测,若秒传成功,则接收该待上传文件在服务端的统一存储ID;若秒传不成功,再进行切片上传,服务端将所有分片合成一个完整的文件后生成统一存储ID,将该统一存储ID返回给应用端;应用端将每个上传文件的统一存储ID与相应的文件参数信息进行关联保存;服务端将完整的文件转存到对象存储服务,对象存储服务返回文件存储地址给服务端,服务端将统一存储ID、文件哈希值、文件存储地址等关键信息进行关联保存。采用本发明的文件上传方法,使得所有非文件下载的文件访问业务可在各第三方应用的自身系统内处理,当处理文件下载业务时,只需向服务端传送统一存储ID即可将文件下载到本地,既保证了各第三方应用的业务独立性,又提高了文件上传下载的效率;服务端不对文件进行实质存储,仅存储上传或下载文件所需的关键信息,简化了服务端对文件的管理,同时避免了大量重复数据产生的网络带宽压力问题和存储压力问题的发生。
根据本发明的另一方面,提供一种服务器,其结构图参见图5。服务器包括存储器和一个或多个处理器;其中,存储器,用于存储一个或多个程序,当所述一个或多个程序被所述一个或多个处理器执行时,使得一个或多个处理器实现图3所述的文件上传方法,如:接收应用端发起的通道获取请求,根据各上传服务节点的负载情况为应用端分配一空闲的文件上传服务节点;接收应用端发起的秒传请求,将秒传请求中携带的哈希值与服务端中已存储文件的哈希值进行匹配;若匹配成功,则获取匹配成功的文件的统一存储ID返回至应用端;若匹配失败,则接收应用端发送的分片数据,将各分片数据组装成一个完整的文件,生成一统一存储ID,将所述统一存储ID返回至应用端。
根据本发明的另一方面,提供一种文件上传系统,其结构图参见图1。所述系统包括一个或多个如上述的终端和一个或多个如上所述的服务器,所述终端通过运行在其上的应用程序与所述服务器进行交互。
根据本发明的另一方面,提供一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序被储器执行时实现如上述任一实施例(例如图2或图3实施例)所述的文件上传方法。图2实施例中的文件上传方法对应为一种计算机可读存储介质,图3实施例中的文件上传方法对应为另一种计算机可读存储介质。这两种计算机可读存储介质可以采用一个或多个计算机可读介质的任何组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读信号介质包括但不限于电、磁、光、电磁、红外线、或半导体的习系统、装置或期间,或者任意以上的组合。计算机可读存储介质包括:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD_ROM)、光存储器件、磁存储器件、或者上述任意合适的组合。在本发明中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者其结合使用。
计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于无线、电线、光缆、RF等等,或者上述的任意合适的组合。可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码,程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++,还包括常规的过程式程序设计语言—诸如”C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
在上述描述的文件上传装置可以实现为用于执行本申请所描述功能的通用处理器、可编程逻辑控制器(PLC)、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件或者其任意适当组合。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory,ROM)或随机存储记忆体(Random AccessMemory,RAM)等。
以上所揭露的仅为本发明较佳实施例而已,当然不能以此来限定本发明之权利范围,因此依本发明权利要求所作的等同变化,仍属本发明所涵盖的范围。