一种资源处理的方法、装置、计算机设备及存储介质
技术领域
本公开涉及互联网技术领域,具体而言,涉及一种资源处理的方法、装置、电子设备及存储介质。
背景技术
目前,要想将第一应用平台中的资源配送至第二应用平台,通常采用的方式是利用第二应用平台的账号在第一应用平台进行登录,即,通过第一应用平台和第二应用平台之间共用的登录账号,来实现跨平台的资源配送。
但是,在无法利用第二应用平台的账号在第一应用平台登录时,比如,第一应用平台和第二应用平台没有共用的账号时,如何实现跨平台的资源配送是目前亟待解决的问题。
发明内容
本公开实施例至少提供一种资源处理的方法、装置、电子设备及存储介质,可以实现跨平台的资源配送。
第一方面,本公开实施例提供了一种资源处理的方法,应用于第一应用平台的服务器,所述方法包括:
响应针对第二应用平台的资源配送指令,获取发起所述资源配送指令的目标用户在所述第一应用平台的第一账号;
从预设绑定库中,查询在所述第二应用平台是否存在与所述第一账号存在绑定关系的第二账号;
若存在,按照所述资源配送指令,将所述目标用户在所述第一应用平台的目标资源配送至所述目标用户在所述第二应用平台的所述第二账号。
一种可选的实施方式中,所述方法还包括:
若在所述第二应用平台不存在与所述第一账号存在绑定关系的第二账号,向所述目标用户的用户端发送提示信息,所述提示信息用于提示所述目标用户将所述第一账号与所述目标用户在所述第二应用平台的第二账号进行绑定。
一种可选的实施方式中,所述方法还包括:
接收所述目标用户的用户端发送的绑定指令;
生成第一绑定码,并将携带有所述第一绑定码的绑定信息发送给所述目标用户的用户端;
在接收到所述用户端通过所述第二应用平台中的目标交互页面发送的第二绑定码和所述目标用户在所述第二应用平台的第二账号,并确认所述第二绑定码与所述第一绑定码一致后,在所述预设绑定库中建立所述第一账号与所述第二账号之间的绑定关系。
一种可选的实施方式中,所述绑定信息中还携带有用于跳转到所述目标交互页面的标识码。
一种可选的实施方式中,生成第一绑定码之后,所述方法还包括:
将所述第一绑定码与所述第一账号关联存储在缓存数据库中;
在接收到所述用户端通过所述第二应用平台中的目标交互页面发送的第二绑定码和所述目标用户在所述第二应用平台的第二账号,并确认所述第二绑定码与所述第一绑定码一致后,在所述预设绑定库中建立所述第一账号与所述第二账号之间的绑定关系,包括:
在接收到所述用户端发送的第二绑定码和所述第二账号后,在所述缓存数据库查找是否存在所述第二绑定码;
若存在所述第二绑定码,且在所述缓存数据库中与所述第二绑定码关联的所述第一应用平台的用户账号为所述第一账号,在所述预设绑定库中建立所述第一账号与所述第二账号之间的绑定关系。
一种可选的实施方式中,在所述缓存数据库查找是否存在所述第二绑定码之前,所述方法还包括:
确定所述第二绑定码的格式满足预设格式要求。
一种可选的实施方式中,所述方法还包括:
在当前时间与所述第一绑定码的生成时间之间的时间间隔超过设定时长后,在所述缓存数据库中删除关联存储的所述第一绑定码与所述第一账号。
一种可选的实施方式中,若所述第一账号与所述第二账号存在绑定关系,所述方法还包括:
响应于所述目标用户的用户端发送的解绑指令,解除所述预设绑定库中所述第一账号与所述第二账号之间的绑定关系。
第二方面,本公开实施例还提供一种资源处理的装置,应用于第一应用平台的服务器,所述装置包括:
获取模块,用于响应针对第二应用平台的资源配送指令,获取发起所述资源配送指令的目标用户在所述第一应用平台的第一账号;
查询模块,用于从预设绑定库中,查询在所述第二应用平台是否存在与所述第一账号存在绑定关系的第二账号;
配送模块,用于若存在,按照所述资源配送指令,将所述目标用户在所述第一应用平台的目标资源配送至所述目标用户在所述第二应用平台的所述第二账号。
一种可选的实施方式中,所述装置还包括:
发送模块,用于若在所述第二应用平台不存在与所述第一账号存在绑定关系的第二账号,向所述目标用户的用户端发送提示信息,所述提示信息用于提示所述目标用户将所述第一账号与所述目标用户在所述第二应用平台的第二账号进行绑定。
一种可选的实施方式中,所述装置还包括建立模块;所述建立模块,用于根据以下步骤建立所述第一账号与所述第二账号之间的绑定关系:
接收所述目标用户的用户端发送的绑定指令;
生成第一绑定码,并将携带有所述第一绑定码的绑定信息发送给所述目标用户的用户端;
在接收到所述用户端通过所述第二应用平台中的目标交互页面发送的第二绑定码和所述目标用户在所述第二应用平台的第二账号,并确认所述第二绑定码与所述第一绑定码一致后,在所述预设绑定库中建立所述第一账号与所述第二账号之间的绑定关系。
一种可选的实施方式中,所述绑定信息中还携带有用于跳转到所述目标交互页面的标识码。
一种可选的实施方式中,所述建立模块包括:
存储单元,用于将所述第一绑定码与所述第一账号关联存储在缓存数据库中;
查找单元,用于在接收到所述用户端发送的第二绑定码和所述第二账号后,在所述缓存数据库查找是否存在所述第二绑定码;
建立单元,用于若存在所述第二绑定码,且在所述缓存数据库中与所述第二绑定码关联的所述第一应用平台的用户账号为所述第一账号,在所述预设绑定库中建立所述第一账号与所述第二账号之间的绑定关系。
一种可选的实施方式中,所述建立模块还包括:
确定单元,用于确定所述第二绑定码的格式满足预设格式要求。
一种可选的实施方式中,所述建立模块还包括:
删除单元,在当前时间与所述第一绑定码的生成时间之间的时间间隔超过设定时长后,在所述缓存数据库中删除关联存储的所述第一绑定码与所述第一账号。
一种可选的实施方式中,所述装置还包括:
解除模块,用于响应于所述目标用户的用户端发送的解绑指令,解除所述预设绑定库中所述第一账号与所述第二账号之间的绑定关系。
第三方面,本公开实施例还提供一种计算机设备,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当计算机设备运行时,所述处理器与所述存储器之间通过总线通信,所述机器可读指令被所述处理器执行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
第四方面,本公开实施例还提供一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器运行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
本公开实施例提供的资源处理的方法、装置、计算机设备及存储介质,在第一应用平台和第二应用平台之间没有共用的账号时,通过事先在预设绑定库中建立的第一应用平台中的第一账号和第二应用平台的第二账号之间的绑定关系,可以实现将第一应用平台中的资源配送至第二应用平台,并提升资源配送的效率。
进一步,本公开实施例提供的资源处理的方法,还可以在接收到用户端通过第二应用平台中的目标交互页面发送的第二绑定码和目标用户在第二应用平台的第二账号,并确认第二绑定码与第一绑定码一致后,在预设绑定库中建立第一账号与第二账号之间的绑定关系,这样,可以实现建立第一应用平台中的第一账号和第二应用平台中的第二账号之间的绑定关系,以便实现将第一应用平台中的资源配送至第二应用平台。
为使本公开的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本公开实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,此处的附图被并入说明书中并构成本说明书中的一部分,这些附图示出了符合本公开的实施例,并与说明书一起用于说明本公开的技术方案。应当理解,以下附图仅示出了本公开的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1示出了本公开实施例所提供的一种资源处理的方法的流程图;
图2a-图2c示出了账号绑定过程中终端界面的示意图;
图3示出了本公开实施例所提供的一种资源处理的装置的示意图之一;
图4示出了本公开实施例所提供的一种资源处理的装置的示意图之二;
图5示出了本公开实施例所提供的资源处理的装置中,建立模块的具体示意图;
图6示出了本公开实施例所提供的一种电子设备的示意图。
图示说明:
300-资源处理的装置;310-获取模块;320-查询模块;330-配送模块;340-发送模块;350-建立模块;351-存储单元;352-查找单元;353-建立单元;354-确定单元;355-删除单元;360-解除模块。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合本公开实施例中附图,对本公开实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本公开一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围,而是仅仅表示本公开的选定实施例。基于本公开的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本公开保护的范围。
经研究发现,要想将第一应用平台中的资源配送至第二应用平台,通常采用的方式是利用第二应用平台的账号在第一应用平台进行登录,通过第一应用平台和第二应用平台之间共用的登录账号,来实现跨平台的资源配送。但是,在无法利用第二应用平台的账号在第一应用平台登录时,比如,第一应用平台和第二应用平台没有共用的账号时,如何实现跨平台的资源配送是目前亟待解决的问题。
基于上述研究,本公开提供了一种资源处理的方法、装置、计算机设备及存储介质,其中,该方法应用于第一应用平台的服务器,该方法包括响应针对第二应用平台的资源配送指令,获取发起资源配送指令的目标用户在第一应用平台的第一账号,进而,从预设绑定库中,查询在第二应用平台是否存在与第一账号存在绑定关系的第二账号,进一步地,若存在,按照资源配送指令,将目标用户在第一应用平台的目标资源配送至目标用户在第二应用平台的第二账号。本公开实施例通过事先在预设绑定库中建立的第一应用平台中的第一账号和第二应用平台的第二账号之间的绑定关系,可以实现将第一应用平台中的资源配送至第二应用平台,并提升资源配送的效率。
针对以上方案所存在的缺陷,均是发明人在经过实践并仔细研究后得出的结果,因此,上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案,都应该是发明人在本公开过程中对本公开做出的贡献。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
下面以执行主体为服务器为例对本公开实施例提供的资源处理的方法加以说明。
实施例一
参见图1所示,为本公开实施例提供的资源处理的方法的流程图,资源处理的方法,应用于第一应用平台的服务器,所述方法包括步骤S101~S103,其中:
S101:响应针对第二应用平台的资源配送指令,获取发起所述资源配送指令的目标用户在所述第一应用平台的第一账号。
其中,资源可以包括视频、图像、虚拟货币、代金券、优惠券等。
在具体实施中,第一应用平台的服务器在接收到目标用户的用户端发送的针对第二应用平台的资源配送指令时,即,在接收到将资源配送至第二应用平台的资源配送指令时,先获取发送该配送指令的目标用户在第一应用平台的第一账号,以便知晓目标用户要将第一应用平台中的哪个账号对应的资源配送至第二应用平台。
这里,第一应用平台和第二应用平台是两个不同的应用平台,第一应用平台可以是短视频类应用程序、新闻资讯类应用程序、直播类应用程序等,第二应用平台可以为即时通讯服务类应用程序、具有支付功能类应用程序等。
需要说明的是,若目标用户想要将在第一应用平台的第一账号中的资源,分配给目标用户在第二应用平台的账号时,可以通过用户端向第一应用平台的服务器发送资源配送指令,这里,资源配送指令包括要配送至第二应用平台的平台信息,以便知晓目标用户要将第一应用平台中的第一账号对应的资源配送至哪个应用平台,以及,第一应用平台的服务器在接收到资源配送指令时,获取发起该资源配送指令的目标用户在第一应用平台的第一账号,以便将第一应用平台的第一账号的资源配送至目标用户在第二应用平台的账号中。
S102:从预设绑定库中,查询在所述第二应用平台是否存在与所述第一账号存在绑定关系的第二账号。
在具体实施中,第一应用平台的服务器在接收到针对第二应用平台的资源配送指令后,除了要获取发起该资源配送指令的目标用户在第一应用平台的第一账号之外,还需要知晓目标用户要将第一应用平台中的第一账号的资源配送给第二应用平台的哪个账号,具体地,可以从预设绑定库中,查询与第一账号存在绑定关系的属于第二应用平台的第二账号,以便将第一应用平台的第一账号的资源配送至目标用户在第二应用平台的第二账号中。
需要说明的是,预设绑定库是预先建立的,预设绑定库中存储有多对存在绑定关系的第一应用平台中的账号与第二应用平台中的账号。
S103:若存在,按照所述资源配送指令,将所述目标用户在所述第一应用平台的目标资源配送至所述目标用户在所述第二应用平台的所述第二账号。
在具体实施中,第一应用平台的服务器若从预设绑定库中,查询到与第一账号存在绑定关系的属于第二应用平台的第二账号,说明目标用户事先已经建立了其在第一应用平台中的第一账号和目标用户在第二应用平台中的第二账号之间的绑定关系,此时,可以直接执行资源配送指令,将目标用户在第一应用平台的目标资源配送至目标用户在第二应用平台的第二账号中,这里,该资源配送指令携带有指示将第一账号中的什么资源、资源数量的指示信息,这样,可以根据指示信息确定出要进行配送的目标资源。
这里,还存在从预设绑定库中,没有查询到与目标用户在第一应用平台中的第一账号存在绑定关系的属于第二应用平台的第二账号的情况,下面对这种情况进行阐述,也即,若在所述第二应用平台不存在与所述第一账号存在绑定关系的第二账号,向所述目标用户的用户端发送提示信息,所述提示信息用于提示所述目标用户将所述第一账号与所述目标用户在所述第二应用平台的第二账号进行绑定。
在具体实施中,第一应用平台的服务器从预设绑定库中,若没有查询到与第一账号存在绑定关系的属于第二应用平台的第二账号,说明目标用户事先没有建立其在第一应用平台中的第一账号和目标用户在第二应用平台中的第二账号之间的绑定关系,此时,第一应用平台的服务器可以向目标用户的用户端发送提示信息,以提示目标用户需要在建立第一应用平台中的第一账号和目标用户在第二应用平台中的第二账号之间的绑定关系后,才能进行资源配送。
进一步地,对建立第一应用平台中的第一账号与第二应用平台中的第二账号之间的绑定关系的过程进行阐述,绑定过程包括以下步骤:
步骤a:接收所述目标用户的用户端发送的绑定指令。
在具体实施中,目标用户可能在接收到提示需要建立第一应用平台中的第一账号和第二应用平台中的第二账号之间的绑定关系后,才能进行资源配送的提示信息后,通过用户端发送绑定指令;或,目标用户在没有接收到提示信息的情况下,但看到第一应用平台中的绑定账号说明,也可能向第一应用平台的服务器发送绑定指令。
步骤b:生成第一绑定码,并将携带有所述第一绑定码的绑定信息发送给所述目标用户的用户端。
在具体实施中,第一应用平台的服务器在接收到目标用户的用户端发送的绑定指令后,生成第一绑定码,这里,第一绑定码可以通过随机ID生成器生成,并保证生成的第一绑定码是全局唯一的,即保证每次生成的绑定码均不同,进一步地,在生成第一绑定码后,将携带有第一绑定码的绑定信息发送给目标用户的用户端,以便目标用户通过第一绑定码完成账号绑定过程。
这里,第一绑定码可以由预设位数的数字组成,第一绑定码也可以由预设位数的数字和字母组成,第一绑定码还可以是其他形式的构成。
步骤c:在接收到所述用户端通过所述第二应用平台中的目标交互页面发送的第二绑定码和所述目标用户在所述第二应用平台的第二账号,并确认所述第二绑定码与所述第一绑定码一致后,在所述预设绑定库中建立所述第一账号与所述第二账号之间的绑定关系。
在具体实施中,第一应用平台的服务器在向目标用户的用户端发送第一绑定码后,在接收到用户端通过第二应用平台中的目标交互页面发送的第二绑定码时,可以获取到目标用户在第二应用平台中第二账号的账号标识,进而,确定目标用户在第二应用平台中的第二账号,在获取到第二绑定码和目标用户在第二应用平台中的第二账号后,需要对第二绑定码进行验证,验证目标用户的用户端发送的第二绑定码,是否与第一绑定码一致,这里,第一绑定码为第一应用平台的服务器在接收目标用户的用户端发送的绑定指令后生成的绑定码,若第一绑定码和第二绑定码一致,说明目标用户通过目标交互页面发送的第二绑定码与生成的第一绑定码一致,此时,第二绑定码的验证通过,并在预设绑定库中建立第一账号与第二账号之间的绑定关系。
这里,目标交互页面属于第二应用平台,用于第一应用平台和第二应用平台之间的交互,目标用户通过操作用户端进入第二应用平台的目标交互页面来实现发送第二绑定码,通常,目标用户在接收到第一绑定码后,复制第一绑定码,并通过用户端在目标交互页面发送复制的第一绑定码(第二绑定码),通过对第二绑定码是否与第一绑定码一致,来对第二绑定码进行验证。
需要说明的是,可以采用上述同样的方式建立其他用户在第一应用平台的账号,和该用户在第二应用平台的账号之间的绑定关系,并将存在绑定关系的每个用户在第一应用平台中的账号,与该用户在第二平台中的账号关联存储在预设绑定库中。这样,通过事先在预设绑定库中建立的第一应用平台中的账号和第二应用平台的账号之间的绑定关系,可以实现将第一应用平台中的资源配送至第二应用平台,通过这种方式,可以方便快捷地进行资源的配送,可以提升资源配送的效率。
进一步地,为了便于目标用户进行绑定,可以在目标交互页面的标识码也发送给目标用户的用户端,以引导目标用户在第二应用平台中的目标交互页面上操作,具体地,可以在携带有第一绑定码的绑定信息中携带有用于跳转到目标交互页面的标识码。
在具体实施中,目标用户在接收到携带有目标交互页面的标识码的绑定信息后,扫描目标交互页面的标识码,在扫描识别出该标识码后,可以直接跳转到目标交互页面,这样,目标用户无需自行搜索目标交互页面,通过该标识码,就可以快速进入到目标交互页面。这里,标识码包括但不限于一维码、二维码、条形码。
一示例中,标识码为二维码,目标用户在获取到目标交互页面的标识码,可以通过第二应用平台中的扫码功能进行扫码,也可以通过目标用户的终端设备中的扫码功能进行扫码,从而识别出目标交互页面的标识码,并获取进入目标交互页面的链接,通过连接进入目标交互页面;或直接在识别出标识码后跳转至目标交互页面。
进一步地,下面对第二绑定码的验证过程进行阐述,也即,对确定第一绑定码和第二绑定码是否一致的过程进行阐述,具体地,第一应用平台的服务器在接收到目标用户的用户端发送的绑定指令,并生成第一绑定码后,将第一绑定码与目标用户在第一应用平台中的第一账号进行关联存储在缓存数据库中,这里,可以以键值对的形式进行关联存储,具体地,以第一绑定码为“键”、第一账号为“值”,以及以第一绑定码为“值”、第一账号为“键”存储至缓存数据库中,这样,可以在接收到用户端发送的第二绑定码和第二账号后,在缓存数据库查找是否存在第二绑定码,若存在,说明第二绑定码是第一应用平台的服务器生成的绑定码,进一步地,判断第二绑定码是否与第一绑定码一致,具体地,以第二绑定码为“键”,在缓存数据库中查询与第二绑定码关联的“值”的用户账号,若该用户账号和目标用户在第一应用平台中的第一账号为同一账号,说明第二绑定码与第一绑定码一致,即,验证第二绑定码成功,则在预设绑定库中建立第一账号与第二账号之间的绑定关系,其中,第一应用平台的服务器每次生成的每个绑定码都是全局唯一的。
其中,可以将目标用户在第一应用平台的第一账号和目标用户在第二应用平台的第二账号关联存储至预设绑定库中,还可以将第一账号、第二账号,以及用于第一账号和第二账号进行绑定的绑定码关联存储至预设绑定库。
进一步地,可能存在有的用户通过用户端发送的绑定码不是第一应用平台生成的情况,比如,绑定码的格式不对的情况,所以,在根据缓存数据库的查询校验第二绑定码之前,可以先对第二绑定码的格式进行判断,这样,若第二绑定码的格式不符合预设格式要求,说明第二绑定码为非法绑定码,第二绑定码不是第一应用平台的服务器生成的,则直接返回给用户端验证未通过的消息,不再查询缓存数据库,这样,可以减少对缓存数据库访问的次数,可以减轻缓存数据库的压力;若第二绑定码的格式符合预设格式要求,则再通过查询缓存数据库来对第二绑定码进行验证。
进一步地,如果绑定码生成后固定不变,会有一定的被其他用户盗取的风险,比如,如用户A在绑定账号过程中绑定码泄露后,被非法用户B获取,直接将用户A在第一应用平台中的账号,与用户B在第二应用平台中的账号进行了绑定,如果用户A没有发觉,用户A在第一应用平台的资源就有配送至用户B在第二应用平台中的账号中,出于上述考虑,本公开还为生成的绑定码设置了有效时间,若在生成的绑定码在有效时间内未使用,则将重新生成新的绑定码,并替换掉缓存数据库中原先对应存储的绑定码,具体地,在当前时间与第一绑定码的生成时间之间的时间间隔超过设定时长后,在缓存数据库中删除关联存储的第一绑定码与第一账号,即,在生成的绑定码失效时,会将失效的绑定码连同绑定的用户账号从缓存数据库中删除。
具体实施中,若检测到生成的第一绑定码的生成时间与当前时间之间的时间间隔超过设定时长后,说明第一绑定码失效,具体地,在缓存数据库中删除关联存储的第一绑定码与第一账号,若接收到目标用户通过用户端发送的第二绑定码,若第二绑定码是用户复制的生成的第一绑定码,将不能在缓存数据库中查询到第二绑定码,此时,会生成新的第一绑定码,需要目标用户通过用户端重新发送与新生成的第一绑定码一致的第二绑定码,才可以完成对目标用户在第一应用平台中的第一账号和第二应用平台中的第二账号之间的绑定关系的建立。
进一步地,若目标用户之前建立了在第一应用平台中的第一账号与第二应用平台的第二账号之间的绑定关系,但目标用户想要将第一应用平台中的资源分配至第二应用平台中的其他账号,或者,目标用户发现之前的绑定有误,都可以对之前绑定的第二账号与第一账号进行解绑,以便在解绑后,将第一账号与第二应用平台中的其他账号进行绑定,在目标用户想要解除第一账号与第二账号的绑定时,具体地,响应于所述目标用户的用户端发送的解绑指令,解除所述预设绑定库中所述第一账号与所述第二账号之间的绑定关系。
在具体实施中,在接收到目标用户的用户端发送的解绑指令,从预设绑定库中查询到与目标用户的第一账号存在绑定关系的第二应用平台中的第二账号后,解除预设绑定库中第一账号与第二账号之间的绑定关系,具体地,可以从预设绑定库中将第一账号,以及与第一账号之间存在绑定关系的第二账号删除,也可以将预设绑定库中将第一账号与第二账号之间的绑定状态由绑定状态改为解绑状态。
这里,预设绑定库中,只允许第一平台中的账号与第二应用平台中的一个账号之间存在绑定关系,具体实现方式为,在预设绑定库中,将第一应用平台中的账号、绑定码、第二应用平台中的账号相关联存储时,将该绑定码的字段设置为uniqueKey,即全局唯一。
参见图2a-图2c所示,为本公开实施例提供的账号绑定过程中终端界面的示意图,其中,图2a示出了账号绑定过程中展示目标交互页面的标识码的示意图,图2b示出了账号绑定过程中展示生成的第一绑定码的示意图,图2c示出了账号绑定过程中用户端通过目标交互页面发送的第二绑定码的示意图。
这里,结合图2a-图2c对本公开实施例所提供的资源处理方法中的账号绑定过程进行阐述,这里,以第一应用平台的服务器和目标用户的用户端之间进行交互的形式进行阐述,包括以下步骤:
步骤(1):目标用户通过用户端向第一应用平台的服务器发送绑定指令。
步骤(2):第一应用平台的服务器在接收到绑定指令后,生成第一绑定码。
步骤(3):在目标用户的用户端上展示用于跳转到目标交互页面的标识码,以及账号绑定步骤说明,详见图2a。
步骤(4):目标用户通过用户端打开第二应用平台,并通过第二应用平台上的“扫一扫”功能扫描标识码,可以得到进入目标交互页面的链接,点击链接后,可以直接跳转至目标交互页面。
步骤(5):在目标用户的用户端上展示生成的第一绑定码,以及账号绑定步骤说明,详见图2b。
步骤(6):第一应用平台的服务器在接收到用户端通过第二应用平台中的目标交互页面发送的第二绑定码,以及获取到目标用户在第二应用平台的第二账号之后,确认第二绑定码与第一绑定码是否一致,若一致,则确定第一应用平台中的第一账号与第二应用平台中的第二账号绑定成功,并提示可以通过第一应用平台进行资源配送,以及提示若绑定有误,可以进行解绑操作,详见图2c。
其中,步骤(4)和步骤(5)的顺序可以进行调换。
在本公开实施例中,响应针对第二应用平台的资源配送指令,获取发起资源配送指令的目标用户在第一应用平台的第一账号,进而,从预设绑定库中,查询在第二应用平台是否存在与第一账号存在绑定关系的第二账号,进一步地,若存在,按照资源配送指令,将目标用户在第一应用平台的目标资源配送至目标用户在第二应用平台的第二账号。本公开实施例通过事先在预设绑定库中建立的第一应用平台中的第一账号和第二应用平台的第二账号之间的绑定关系,可以实现将第一应用平台中的资源配送至第二应用平台,并提升资源配送的效率。
本领域技术人员可以理解,在具体实施方式的上述方法中,各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定,各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。
基于同一发明构思,本公开实施例中还提供了与资源处理的方法对应的资源处理的装置,由于本公开实施例中的装置解决问题的原理与本公开实施例上述资源处理的方法相似,因此装置的实施可以参见方法的实施,重复之处不再赘述。
实施例二
参照图3所示,为本公开实施例提供的一种资源处理的装置300的示意图,所述资源处理的装置300应用于第一应用平台的服务器,包括:获取模块310、查询模块320、配送模块330;其中,
获取模块310,用于响应针对第二应用平台的资源配送指令,获取发起所述资源配送指令的目标用户在所述第一应用平台的第一账号;
查询模块320,用于从预设绑定库中,查询在所述第二应用平台是否存在与所述第一账号存在绑定关系的第二账号;
配送模块330,用于若存在,按照所述资源配送指令,将所述目标用户在所述第一应用平台的目标资源配送至所述目标用户在所述第二应用平台的所述第二账号。
一种可能的实施方式中,如图4所示,所述资源处理的装置300还包括:
发送模块340,用于若在所述第二应用平台不存在与所述第一账号存在绑定关系的第二账号,向所述目标用户的用户端发送提示信息,所述提示信息用于提示所述目标用户将所述第一账号与所述目标用户在所述第二应用平台的第二账号进行绑定。
一种可能的实施方式中,如图4所示,所述资源处理的装置300还包括建立模块350;所述建立模块350,用于根据以下步骤建立所述第一账号与所述第二账号之间的绑定关系:
接收所述目标用户的用户端发送的绑定指令;
生成第一绑定码,并将携带有所述第一绑定码的绑定信息发送给所述目标用户的用户端;
在接收到所述用户端通过所述第二应用平台中的目标交互页面发送的第二绑定码和所述目标用户在所述第二应用平台的第二账号,并确认所述第二绑定码与所述第一绑定码一致后,在所述预设绑定库中建立所述第一账号与所述第二账号之间的绑定关系。
一种可能的实施方式中,所述绑定信息中还携带有用于跳转到所述目标交互页面的标识码。
一种可能的实施方式中,如图5所示,所述建立模块350包括:
存储单元351,用于将所述第一绑定码与所述第一账号关联存储在缓存数据库中;
查找单元352,用于在接收到所述用户端发送的第二绑定码和所述第二账号后,在所述缓存数据库查找是否存在所述第二绑定码;
建立单元353,用于若存在所述第二绑定码,且在所述缓存数据库中与所述第二绑定码关联的所述第一应用平台的用户账号为所述第一账号,在所述预设绑定库中建立所述第一账号与所述第二账号之间的绑定关系。
一种可能的实施方式中,如图5所示,所述建立模块350还包括:
确定单元354,用于确定所述第二绑定码的格式满足预设格式要求。
一种可能的实施方式中,如图5所示,所述建立模块350还包括:
删除单元355,在当前时间与所述第一绑定码的生成时间之间的时间间隔超过设定时长后,在所述缓存数据库中删除关联存储的所述第一绑定码与所述第一账号。
一种可能的实施方式中,如图4所示,所述资源处理的装置300还包括:
解除模块360,用于响应于所述目标用户的用户端发送的解绑指令,解除所述预设绑定库中所述第一账号与所述第二账号之间的绑定关系。
在本公开实施例中,响应针对第二应用平台的资源配送指令,获取发起资源配送指令的目标用户在第一应用平台的第一账号,进而,从预设绑定库中,查询在第二应用平台是否存在与第一账号存在绑定关系的第二账号,进一步地,若存在,按照资源配送指令,将目标用户在第一应用平台的目标资源配送至目标用户在第二应用平台的第二账号。本公开实施例通过事先在预设绑定库中建立的第一应用平台中的第一账号和第二应用平台的第二账号之间的绑定关系,可以实现将第一应用平台中的资源配送至第二应用平台,并提升资源配送的效率。
关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明,这里不再详述。
实施例三
基于同一技术构思,本申请实施例还提供了一种计算机设备。参照图6所示,为本申请实施例提供的计算机设备600的结构示意图,包括处理器601、存储器602、和总线603。其中,存储器602用于存储执行指令,包括内存6021和外部存储器6022;这里的内存6021也称内存储器,用于暂时存放处理器601中的运算数据,以及与硬盘等外部存储器6022交换的数据,处理器601通过内存6021与外部存储器6022进行数据交换,当计算机设备600运行时,处理器601与存储器602之间通过总线603通信,使得处理器601在执行以下指令:
一种可能的实施方式中,处理器601执行的指令中,
响应针对第二应用平台的资源配送指令,获取发起所述资源配送指令的目标用户在所述第一应用平台的第一账号;
从预设绑定库中,查询在所述第二应用平台是否存在与所述第一账号存在绑定关系的第二账号;
若存在,按照所述资源配送指令,将所述目标用户在所述第一应用平台的目标资源配送至所述目标用户在所述第二应用平台的所述第二账号。
在本公开实施例中,响应针对第二应用平台的资源配送指令,获取发起资源配送指令的目标用户在第一应用平台的第一账号,进而,从预设绑定库中,查询在第二应用平台是否存在与第一账号存在绑定关系的第二账号,进一步地,若存在,按照资源配送指令,将目标用户在第一应用平台的目标资源配送至目标用户在第二应用平台的第二账号。本公开实施例通过事先在预设绑定库中建立的第一应用平台中的第一账号和第二应用平台的第二账号之间的绑定关系,可以实现将第一应用平台中的资源配送至第二应用平台,并提升资源配送的效率。
实施例四
本公开实施例还提供一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器运行时执行上述方法实施例中所述的资源处理的方法的步骤。其中,该存储介质可以是易失性或非易失的计算机可读取存储介质。
本公开实施例所提供的资源处理的方法的计算机程序产品,包括存储了程序代码的计算机可读存储介质,所述程序代码包括的指令可用于执行上述方法实施例中所述的资源处理的方法的步骤,具体可参见上述方法实施例,在此不再赘述。
本公开实施例还提供一种计算机程序,该计算机程序被处理器执行时实现前述实施例的任意一种方法。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中,所述计算机程序产品具体体现为计算机存储介质,在另一个可选实施例中,计算机程序产品具体体现为软件产品,例如软件开发包(Software DevelopmentKit,SDK)等等。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统和装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。在本公开所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本公开各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上所述实施例,仅为本公开的具体实施方式,用以说明本公开的技术方案,而非对其限制,本公开的保护范围并不局限于此,尽管参照前述实施例对本公开进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应所述以权利要求的保护范围为准。