CN113301390A

CN113301390A - 一种调用虚拟资源的数据处理方法、装置、服务器

Info

Publication number: CN113301390A
Application number: CN202110560261.9A
Authority: CN
Inventors: 李舜民
Original assignee: Beijing Dajia Internet Information Technology Co Ltd
Current assignee: Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2021-05-21
Filing date: 2021-05-21
Publication date: 2021-08-24
Anticipated expiration: 2041-05-21
Also published as: CN113301390B

Abstract

本公开关于一种调用虚拟资源的数据处理方法、装置、服务器。一个方法实施例中，接收目标虚拟资源的调用请求；根据所述调用请求，在存储所述虚拟资源的发放记录的发放记录表进行查询；若查询到目标发放记录，则获取对应的任务的执行状态；根据所述执行状态，相应的执行所述调用请求的预设操作。本公开实施例改变了现有的通过常规redis数据缓存/存储式和Zset数据结构来实现获取虚拟资源的方式，通过虚拟资源发放记录的发放记录表来实现更加高效、可靠的虚拟资源调用和发放，更加简易、高效、可靠的实现虚拟资源发放的幂等性，提供***处理性能。

Description

一种调用虚拟资源的数据处理方法、装置、服务器

技术领域

本公开涉及计算机数据处理技术领域，尤其涉及一种调用虚拟资源的数据处理方法、装置、服务器。

背景技术

视频直播时可以进行内容分享，销售产品或服务，还可以实现用户(包括主播)之间的互动，因此，各种各样的直播活动受到越来越多用户的喜爱和关注。

在直播活动中，用户和主播可以得到各种荣誉奖励，例如进场特效、勋章、特效头像框、主播荣誉称号等。这些荣誉奖励可以由直播服务方的服务器发放给满足荣誉发放条件的用户。目前，常规的方式主要是通过redis(一种开源的缓存/存储实现方案)临时存储准备发放的荣誉奖励zset(有序集合，一种redis的数据结构)列表，然后通过排序过滤的方式拿到用户奖励。而这种方式在实现幂等时的约束条件较多，实现较为复杂，且常常出现少量参数变化就会导致不符合幂等要求进而重新触发资源调用请求的情况，影响***吞吐性能。

发明内容

本公开提供一种调用虚拟资源的数据处理方法、装置、服务器，以至少解决相关技术中幂等实现复杂的技术问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种调用虚拟资源的数据处理方法，包括：

接收目标虚拟资源的调用请求，所述调用请求包括虚拟资源调用方的第一识别标识、发起所述调用请求的业务的第二识别标识；

根据所述调用请求，在存储所述虚拟资源的发放记录的发放记录表进行查询，所述虚拟资源的发放记录包括虚拟资源发送至的使用方的第三识别标识、发起调用所述虚拟资源的业务的第四识别标识；

若查询到所述第三识别标识与所述第一识别标识相同且所述第四识别标识与所述第二识别标识相同的目标发放记录，则获取所述目标发放记录所对应的任务的执行状态；

根据所述执行状态，相应的执行所述调用请求的预设操作。

可选的，所述方法中，所述发起所述调用请求的业务的第二识别标识包括所述业务的业务类型标识，所述发放记录中的第四识别标识包括所述业务类型标识；

所述在存储所述虚拟资源的发放记录的发放记录表进行查询包括：在存储所述虚拟资源的发放记录的发放记录表查询与所述第二识别标识所包括的业务类型标识相同的第四识别标识。

可选的，所述方法中，所述在存储所述虚拟资源发放记录的发放记录表进行查询之后，还包括：

若未查询到所述目标发放记录，则加载所述目标虚拟资源，并将所述目标虚拟资源发放至所述虚拟资源调用方；

将所述目标虚拟资源的发放记录更新到所述发放记录表中。

可选的，所述方法中，若所述执行状态为处理成功，则取消所述调用请求。

可选的，所述方法中，还包括：

当所述任务的执行状态为处理失败或处理中时，等待预设时长；

在经过所述预设时长后，重新获取所述任务的执行状态，根据所述执行状态执行相应的处理；

当重新获取的所述任务的执行状态为处理失败或处理中的总次数达到重加载阈值，则初始化所述任务，并重新执行所述任务。

可选的，所述方法中，所述加载所述目标虚拟资源包括：

从数据库的缓存中读取所述目标虚拟资源，所述数据库用于存储虚拟资源，所述缓存为执行调用虚拟资源的数据处理方法的设备在所述设备本地缓存的数据。

可选的，所述方法中，从数据库的缓存中读取所述目标虚拟资源之前或之后，还包括：

基于监听到的所述数据库的更新事件对所述缓存进行重加载。

可选的，所述方法中，当预期的调用请求的数量达到并发阈值时，所述基于监听到的所述数据库的更新事件对所述缓存进行重加载包括：

在延迟缓存时长后，基于监听到的所述数据库的更新事件对所述缓存进行重加载。

根据本公开实施例的第二方面，还供一种调用虚拟资源的数据处理装置，包括：

请求接收模块，其被配置为，接收目标虚拟资源的调用请求，所述调用请求包括虚拟资源调用方的第一识别标识、发起所述调用请求的业务的第二识别标识；

去重模块，其被配置为，根据所述调用请求，在存储所述虚拟资源的发放记录的发放记录表进行查询，所述虚拟资源的发放记录包括虚拟资源发送至的使用方的第三识别标识、发起调用所述虚拟资源的业务的第四识别标识；

第一处理模块，其被配置为，若查询到所述第三识别标识与所述第一识别标识相同且所述第四识别标识与所述第二识别标识相同的目标发放记录，则获取所述目标发放记录所对应的任务的执行状态；

策略执行模块，其被配置为，根据所述执行状态，相应的执行所述调用请求的预设操作。

可选的，所述装置还包括：

第二处理模块，其被配置为，在存储所述虚拟资源发放记录的发放记录表进行查询之后，若未查询到所述目标发放记录，则加载所述目标虚拟资源，并将所述目标虚拟资源发放至所述虚拟资源调用方；

记录添加模块，其被配置为，将所述目标虚拟资源的发放记录更新到所述发放记录表中。

可选的，所述装置中，所述发起所述调用请求的业务的第二识别标识包括所述业务的业务类型标识，所述发放记录中的第四识别标识包括所述业务类型标识；

所述去重模块在存储所述虚拟资源的发放记录的发放记录表进行查询包括：在存储所述虚拟资源的发放记录的发放记录表查询与所述第二识别标识所包括的业务类型标识相同的第四识别标识。

可选的，所述装置中，所述策略执行模块在所述执行状态为处理成功时，取消所述调用请求。

可选的，所述装置中，所述策略执行模块在所述任务的执行状态为处理失败或处理中时，等待预设时长；在经过所述预设时长后，重新获取所述任务的执行状态，根据所述执行状态执行相应的处理；当重新获取的所述任务的执行状态为处理失败或处理中的总次数达到重加载阈值，则初始化所述任务，并重新执行所述任务。

可选的，所述装置中，所述装置还包括缓存，用于从数据库的缓存中读取所述目标虚拟资源，所述数据库用于存储虚拟资源，所述缓存为执行调用虚拟资源的数据处理方法的设备在所述设备本地缓存的数据。

可选的，所述装置中，所述装置还包括：

缓存更新模块，其被配置为，从数据库的缓存中读取所述目标虚拟资源之前或之后，基于监听到的所述数据库的更新事件对所述缓存进行重加载。

可选的，所述装置中，所述装置还包括：

并发优化模块，其被配置为，当预期的调用请求的数量达到并发阈值时，延迟缓存时长；

所述缓存更新模块在延迟所述缓存时长后，基于监听到的所述数据库的更新事件对所述缓存进行重加载。

根据本公开实施例的第三方面，还提供一种服务器，包括：

至少一个处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现本公开中实施于服务器的任一项实施例所述的方法。

根据本公开实施例的第四方面，还提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令服务器的处理器执行时，使得所述服务器能够执行本公开中实施于服务器的任一项所述的方法。

根据本公开实施例的第五方面，还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现本公开中实施于服务器的任一项实施例所述的方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

本公开实施例中，服务器可以接收终端发来的调用目标虚拟资源的调用请求，所述调用请求包括虚拟资源调用方的第一识别标识、发起所述调用请求的业务的第二识别标识，可以根据所述调用请求，在存储所述虚拟资源的发放记录的发放记录表进行查询，所述虚拟资源的发放记录包括虚拟资源发送至的使用方的第三识别标识、发起调用所述虚拟资源的业务的第四识别标识；若查询到所述第三识别标识与所述第一识别标识相同且所述第四识别标识与所述第二识别标识相同的目标发放记录，则获取所述目标发放记录所对应的任务的执行状态，然后可以根据所述执行状态，相应的执行所述调用请求的预设操作。本公开实施例改变了现有的通过常规redis数据缓存/存储式和Zset数据结构来实现获取虚拟资源的方式，通过包括指定标识字段的调用请求和存储虚拟资源发放记录的发放记录表来实现更加高效、可靠的虚拟资源调用和发放，更加简易、高效、可靠的实现虚拟资源发放的幂等性，提供***处理性能。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的应用环境图。

图2是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的流程图。

图3是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的流程图。

图4是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的流程图。

图5是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的流程图。

图6是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的流程图。

图7是根据一示例性实施例示出的一种调用虚拟资源的数据处理装置框图。

图8是根据一示例性实施例示出的一种调用虚拟资源的数据处理装置的框图。

图9是根据一示例性实施例示出的一种调用虚拟资源的数据处理装置的框图。

图10是根据一示例性实施例示出的一种调用虚拟资源的数据处理装置的框图。

图11是根据一示例性实施例示出的一种服务器的内部结构图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

本公开所提供的一种调用虚拟资源的数据处理方法，可以应用于如图1所示的应用环境中。其中，终端110可以通过网络连接与服务器120进行交互。服务器120可以向终端110发送虚拟资源，如各种荣誉奖励、荣誉特效等，终端110接收到虚拟资源之后可以在APP界面中进行展示，如试穿道具、进场特效、头像框。服务器120可以向一个或多个终端110发放虚拟资源，一个虚拟资源也可以被多个终端110获得。一般的，在直播场景中，虚拟资源通常对于一个终端的一个账户只发送一次，虚拟资源也可以设置为过期或者不过期等。例如虚拟资源仅在某次直播场景中有效，一旦该直播结束，虚拟资源在用户一侧就会标记为过期，不再呈现荣誉特效等。当然，其他的实施场景中，可以通过设置的虚拟资源的过期时间来重复发送给一个直播对象。本公开实施例中所述的终端110可以包括但不限于各种个人计算机、笔记本电脑、智能手机、平板电脑、可穿戴设备、车载设备、医疗设备等。本公开实施例中所述的服务器120可以包括但不限于独立的服务器、服务器集群、分布式处理服务器、区块链服务器、云计算平台等以及必要的数据库或缓存等。

所述的幂等或幂等性，通常是指对资源的操作，无论操作一次还是多次，其资源本身不发生变化。如对于终端一侧的账户来说，对于相同操作发起的一次请求或者多次请求的返回结果是一致的，服务器不会因为基于同一操作的多次请求而重复下发某个虚拟资源。例如，因为某个直播账户是充值会员，已经给该直播账户发放了进场特效，则不会因为用户的再次请求或服务器再次识别出该账户是充值会员而重复发一次相同的进场特效。下面以在视频直播中场景中直播平台给直播账户发放荣誉奖励的应用场景为例对本公开的一些实施例进行说明。

图2是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的流程图，如图2所示，所述方法可以用于服务器120中，可以包括以下步骤。

在步骤S202中，接收目标虚拟资源的调用请求，所述调用请求包括虚拟资源调用方的第一识别标识、发起所述调用请求的业务的第二识别标识。

虚拟资源可以存储在服务器或与服务器可调用加载的存储单元中。服务器一侧可以预先存储多个虚拟资源，具体的可以根据不同的业务场景设计相应的虚拟资源，如主播认证展示、进场特效、皮肤、荣誉称号等。在单次执行过程中，调用请求所需要的虚拟资源可以称为目标虚拟资源。调用请求可以是由与提供虚拟资源的直播平台相连接的其他服务器发起，如荣誉奖励发放服务器，或者所述服务器120中的荣誉奖励发放组件，或者发起远程过程调用(Remote Procedure Call Protocol，RPC)的其他设备/组件/终端。

在步骤S204中，根据所述调用请求，在存储所述虚拟资源的发放记录的发放记录表进行查询，所述虚拟资源的发放记录包括虚拟资源发送至的使用方的第三识别标识、发起调用所述虚拟资源的业务的第四识别标识。

在本公开的一些实施例中，虚拟资源存储在数据库中，这个数据库可以是关系型数据库，如MySQL、oracle等。关系型数据库可以以表的数据结构来持久化存储虚拟资源。本公开实施例中，可以存储有虚拟资源的发放记录表，所述发放记录表中可以记录有各个虚拟资源的发放记录，如虚拟资源发送至的使用方的第三识别标识、发起调用所述虚拟资源的业务的第四识别标识等。当然，还可以存储其他数据表，或者所述发放记录表还可以记录其他的数据信息。例如，本实施例的一些应用场景中，关系型数据库中可以包括以下几张表：

1.奖品表(虚拟资源表)，可以存储以荣誉奖励的形式发送给账户的虚拟资源，如进场特效、头衔、七夕头像框(30天)等荣誉奖励。一个荣誉奖励可以被多个直播对象获得。

2.奖励表(发放记录表)，可以存储发放给各个账户荣誉奖励的发放记录。如记录某个直播账户获得七夕头像框(30天)，并且该荣誉奖励于2020年12月31日过期等的相关信息。

3.发放记录表，可以存储服务器发放虚拟资源的记录信息，可以包括已经发放的虚拟资源记录信息，也可以包括虚拟资源正在处理中或失败的记录信息，一些实施方式中也可以包括需要发放但还未发放的记录信息等。

在本公开采用了发放记录表来管理虚拟资源发放的实施例中，可以采用若干预先设定的标识来唯一确定虚拟资源的发放记录，如虚拟资源发送至的使用方的第三识别标识、发起调用所述虚拟资源的业务的第四识别标识等，能够明确识别出是因为什么业务发送给某个账户。这样，当该账号基于同样的业务触发同样的虚拟资源调用时，可以在发放记录表中快速查询到已经基于同样的业务发送过该账户所需的虚拟资源(或该所需的虚拟资源正处于处理中、已经发送但发送失败等执行状态)，则可以不再重复调取、加载该虚拟资源。发放记录表可以存储多个发放记录，每条发放记录可以有虚拟资源发送至的使用方的第三识别标识、发起调用所述虚拟资源的业务的第四识别标识等，如使用userId+bizId作为关键字符来组成发放记录的标识，其中userId为使用方的标识，即第三识别标识，actId为活动标识，bizId为业务标识，如七夕活动直播使用的30天头像框。

一般，默认的，发放记录表中的每条发放记录会存储所述虚拟资源的唯一标识。如头像框的标识为“Head_fram”，虚拟资源的标识可以为“Head_fram”，同样的，两个进场特效的虚拟资源的标识可以分别为“Effects_1”、“Effects_2”。

所述发起调用所述虚拟资源的业务，可以表征发起调用请求的原因或基于什么事件发送给使用方，如可以所述的业务的第四标识可以是业务类型。例如，识别出某个直播对象为充值会员，则在一场视频直播中需要为其发放充值会员专属的头像框(一种荣誉奖励的虚拟资源)，那么该业务可以为“直播对象为充值会员”。当然，这个业务还可以包括其他的事件，如送礼物、完成某些任务等。

这样，本公开的一些实施方式中，可以将根据具体的业务来制定相应的幂等规则(包括调用请求的字段、发放记录的字段、查找或匹配方式等)，将幂等规则与业务关联起来，进一步提供实现幂等处理的灵活性。因此，本公开的另一示例性实施例中，

所述发起所述调用请求的业务的第二识别标识包括所述业务的业务类型标识，所述发放记录中的第四识别标识包括所述业务类型标识；

当然，发放记录还可以包括其他标识信息或为其他的数据结构形式，如“req:xx,xxxx,name＝user1，vip＝yes，type＝Head_fram,xx，Live-video＝178256”。本公开也不排除所述第三识别标识、第四识别标识，以及前述的第一识别标识、第二识别标识等也可以为采取其他的方式进行组合或字段拆分等生成的标识信息。这样，本公开的一些实施中，可以基于发放记录唯一确定基于什么触发事件需要将哪个虚拟资源发送给哪个账户。

获取调用请求后，可以先在虚拟资源的发放记录中查询是否有与调用请求重复的发放记录。若有，这个重复的发放记录可以称为目标发放记录。发放记录表中存储了服务器发放的虚拟资源的记录列表，每一个发放的虚拟资源的任务(或称为订单)可以作为发放记录表中的一条发放记录。服务器可以筛选出发放记录表中未发放的发放记录进行重发。

在步骤S206中，若查询到所述第三识别标识与所述第一识别标识相同且所述第四识别标识与所述第二识别标识相同的目标发放记录，则获取所述目标发放记录所对应的任务的执行状态。

在步骤S208中，根据所述执行状态，相应的执行所述调用请求的预设操作。

如果在发放记录表中查询到所述第三识别标识与所述第一识别标识相同且所述第四识别标识与所述第二识别标识相同的目标发放记录，则可以确定该调用请求与目标发放记录重复，该调用请求属于同一个使用方基于同样的业务请求的同样的虚拟资源，表示处理器在收到该调用请求之前已经处理过相同的调用请求。此时可以获取该目标发放记录所对应的任务的执行状态。然后可以根据所述执行状态，对所述调用请求执行预先设置的预设操作。如可以不再将该调用请求添加到虚拟资源的发放记录表中，保障虚拟资源发放的幂等性。

一般的，目标发放记录表中发放记录可以是以任务的形式被执行处理，处理后的状态可以包括处理成功、处理失败、处理中，或者类似的状态描述，为便于描述，处理的状态可以统一称为执行状态。其中，处理成功可以表示发放记录对应的虚拟资源已经成功发放给使用方。处理失败可以表示发放记录对应的虚拟资源未成功发放给使用方。处理中可以表示该发放记录已经被服务器接受，正在处理或流转，还未确定是否发放成功。处理状态可以根据处理结果相互转换，执行状态为处理中的发放记录在成功发送给使用方后可以更新为处理成功。

所述预设操作可以是预先设置的在发放记录表中查询到与所述调用请求重复的目标发放记录时执行的后续处理步骤。例如，若执行状态为处理失败，对应的预设操作可以为使用方延迟一段时间后再次重新尝试发放。如果是处理中，可能是服务器或平台内部运转可能出了一些问题，可以设置一个等待时间，如果超时后仍然没有处理成功或失败的结果，则可以将其标记为处理失败，或者由其他服务器处理。当然，对于处理失败或处理中的发放记录，若多次重试或等待超时后，可以发出报警，移交至其他设备或转到人工处理终端进行处理。

本公开实施例改变了现有的通过常规redis数据缓存/存储式和Zset数据结构来实现获取虚拟资源的方式，通过包括指定标识字段的调用请求和存储虚拟资源发放记录的发放记录表来实现更加高效、可靠的虚拟资源调用和发放，更加简易、高效、可靠的实现虚拟资源发放的幂等性。

图3是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的流程图，如图3所示，本公开的另一示例性实施例中，所述在存储所述虚拟资源发放记录的发放记录表进行查询之后，还包括：

S302：若未查询到所述目标发放记录，则加载所述目标虚拟资源，并将所述目标虚拟资源发放至所述虚拟资源调用方；

S304：将所述目标虚拟资源的发放记录更新到所述发放记录表中。

如果在发放记录表中没有查询到与所述调用请求重复的目标发放记录，则可以表示该调用请求不是重复的虚拟资源发放操作，可以加载相应的虚拟资源，并发送给对应的使用方。同时，可以将该调用请求对应的目标虚拟资源的发放记录添加到发放记录表中，调更新发放记录表。当然，所述目标虚拟资源的发放记录在发放记录表中也可以有相应的处理状态，具体的，可以根据调用请求的虚拟资源的发放处理结果进行确定。这样，由于数据记录表来管理和控制虚拟资源的发放和调用请求的处理响应，摒弃了常规的redis通过序列化奖励成二进制存进zset的value来实现幂等的方法，大大简化了幂等的实现要求，同时也可以保障幂等的可靠性，提升了整体虚拟资源发放***幂等性的可靠性和执行效率。

图4是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的流程图，如图4所示，本公开的另一示例性实施例中，所述方法还包括：

S402：若所述执行状态为执行成功，则取消所述调用请求。

执行状态可以包括处理成功、处理失败、处理中等。若执行状态为处理成功，则可以表示发放记录对应的虚拟资源已经成功发放给使用方，当前的对目标虚拟资源的调用请求已被执行过且记录在发放记录中，可以取消所述调用请求，不再基于同样的原因向同一个账户发放相同的虚拟资源。这样，基于数据记录表来管理和控制虚拟资源的发放和调用请求的处理响应，摒弃了常规的redis通过序列化奖励成二进制存进zset的value来实现幂等的方法，大大简化了幂等的实现要求，同时也可以保障幂等的可靠性，提升了整体虚拟资源发放***幂等性的可靠性和执行效率。

图5是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的流程图，如图5所示，本公开的另一示例性实施例中，所述方法还包括：

S502：当所述任务的执行状态为处理失败或处理中时，等待预设时长；

S504：在经过所述预设时长后，重新获取所述任务的执行状态，根据所述执行状态执行相应的处理；

S506：当重新获取的所述任务的执行状态为处理失败或处理中的总次数达到重加载阈值，则初始化所述任务，并重新执行所述任务。

本公开实施例中，如果目标发放记录对应的任务的执行状态为处理失败或处理中，则可以表示该任务已经被服务器接受，可能在服务器内部处理过程中出现问题，如任务队列拥堵、任务流程未执行完等。此时可以设置一个预设时长，等待服务器的内部处理。如果等待预设时长之后，处理成功，则可以按照前述执行状态为处理成功或其他预设操作进行后续处理。若仍然为处理失败或处理中，可以再次等待预设时长，然后再获取任务的执行状态，根据执行状态执行相应的处理。可以预先设置等待的次数，及处理识别和处理中的总次数。如果多次等待预设时长之后仍未处理成功，则可以重新初始化该任务，重新触发任务，重复分配资源和处理该任务。本公开实施例设置了任务在处理失败或处理中的重新触发机制，可以提高任务执行的成功率。当然，也可以设置在一次或多次处理失败后，可以产生报警信息，提示人工介入，核查处理失败的原因。

本公开的另一示例性实施例中，所述加载所述目标虚拟资源包括：

本公开的发放虚拟资源的实施方案中，虚拟资源可以是从本地数据库的缓存中读取的。所述缓存为执行调用虚拟资源的数据处理方法的设备在所述设备本地缓存的数据，如处理调用请求的处理服务器可以从多个数据库或其他服务器获取的各种数据资源全缓存到处理服务器，这样，处理服务器可以快速的访问到数据内容。本公开实施例将虚拟资源在服务器本地缓存，可以有效保障数据的读取效率和读取数据的一致性，并且可以有效支持高并发的请求。一些实施例中可以设置关系型数据库的缓存，如果缺少某些数据(如初始化时)可以回溯到关系型数据库。也可以设置缓存失效时间，例如可以设置为4小时。本实施例中从所述关系型数据中返回的数据结果是空结果，也可以对该空结果进行缓存。需要注意的是，这里缓存的空结果通常是指从关系型数据库查询返回的数据为空(不管是数据不存在，还是***故障)，把这个空结果进行缓存。这样可以防止数据穿透，提高***可靠性，降低在缓存中没有查询到结果时再回溯到关系型数据库中进行查询的发生概率。

图6是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的流程图，如图6所示，本公开的另一示例性实施例中，从数据库的缓存中读取所述目标虚拟资源之前或之后，还包括：

S602：基于监听到的所述数据库的更新事件对所述缓存进行重加载。

可以通过监听binlog(基于事务来记录二进制日志,一般每提交一次事务,就写入binlog)的修改，触发cache setter reload cache(缓存设置器重新加载缓存)，实现所述缓存的重加载。本公开实施例可以实现及时的***数据缓存，及时更新空结果的缓存，并且能够保证刚下发的数据在缓存中能被命中。

本公开的另一示例性实施例中，当预期的调用请求的数量达到并发阈值时，所述基于监听到的所述数据库的更新事件对所述缓存进行重加载包括：

在另一些应用场景中，对于一些大型直播间，如果是在线人数非常多，预期调用请求的数量达到并发阈值，则可以对该场景下的虚拟资源下发进行优化。可以牺牲缓存一部分的一致性(如增加本地缓存的保留时长)来保障人数较多的直播间的虚拟资源下发处理性能。所述缓存时长可以根据在线人数或直播的一致性要求进行设置，如缓存3分钟后再更新。所述并发阈值可以根据预先的高并发条件进行设置，如在线人数达到10万人。所述的预期调用请求数据可以指虽然当前还没有达到高并发的并发阈值，但预期在某个时间段或一段时间后其调用请求数据可能会达到并发阈值。本实施中考虑到在视频直播的荣誉奖励的虚拟资源下发应用场景中，通过来说一个用户的荣誉奖励也变动小较小，因此可以牺牲缓存的一致性，降低数据更新的实时性来保证高并发的处理性能。这样，在大型或超大型直播间(如10万用户以上)的应用场景中，既可以保障虚拟资源发放的幂等性，还保障了数据的可靠性。

可以理解的是，本说明书中上述服务器一侧方法的各个实施例均采用递进的方式描述，各个实施例之间相同/相似的部分互相参见即可，每个实施例重点说明的都是与其它实施例的不同之处。相关之处参见其他方法实施例的描述说明即可。

应该理解的是，虽然附图中的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，附图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的步骤或者阶段的至少一部分轮流或者交替地执行。

基于上述所述的调用虚拟资源的数据处理方法实施例的描述，本公开还提供在调用虚拟资源的数据处理装置。所述装置可以包括使用了本说明书实施例所述方法的***(包括分布式***)、软件(应用)、模块、组件、服务器、客户端等并结合必要的实施硬件的装置。基于同一创新构思，本公开实施例提供的一个或多个实施例中的装置如下面的实施例所述。由于装置解决问题的实现方案与方法相似，因此本说明书实施例具体的装置的实施可以参见前述方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图7是根据一示例性实施例示出的一种调用虚拟资源的数据处理装置框图。所述装置可以为服务器，如前述的服务器120。具体的可以参照图7，该装置100可以包括:

请求接收模块702，其被配置为，接收目标虚拟资源的调用请求，所述调用请求包括虚拟资源调用方的第一识别标识、发起所述调用请求的业务的第二识别标识；

去重模块704，其被配置为，根据所述调用请求，在存储所述虚拟资源的发放记录的发放记录表进行查询，所述虚拟资源的发放记录包括虚拟资源发送至的使用方的第三识别标识、发起调用所述虚拟资源的业务的第四识别标识；

第一处理模块706，其被配置为，若查询到所述第三识别标识与所述第一识别标识相同且所述第四识别标识与所述第二识别标识相同的目标发放记录，则获取所述目标发放记录所对应的任务的执行状态；

策略执行模块708，其被配置为，根据所述执行状态，相应的执行所述调用请求的预设操作。

一示例性实施例如图8所示，图8是根据一示例性实施例示出的一种调用虚拟资源的数据处理装置框图，其中10为数据库缓存(或称为缓存)，虚线框表示可以包含在装置100中，也可以不包含在装置100中。参照图8，所述装置100还可以包括：

第二处理模块802，其被配置为，在存储所述虚拟资源发放记录的发放记录表进行查询之后，若未查询到所述目标发放记录，则加载所述目标虚拟资源，并将所述目标虚拟资源发放至所述虚拟资源调用方；

记录添加模块804，其被配置为，将所述目标虚拟资源的发放记录更新到所述发放记录表中。

本公开的所述装置100的另一示例性实施例中，所述发起所述调用请求的业务的第二识别标识包括所述业务的业务类型标识，所述发放记录中的第四识别标识包括所述业务类型标识；

所述去重模块704在存储所述虚拟资源的发放记录的发放记录表进行查询包括：在存储所述虚拟资源的发放记录的发放记录表查询与所述第二识别标识所包括的业务类型标识相同的第四识别标识。

本公开的所述装置100的另一示例性实施例中，所述策略执行模块708在所述执行状态为处理成功时，取消所述调用请求。

本公开的所述装置100的另一示例性实施例中，所述策略执行模块708在所述任务的执行状态为处理失败或处理中时，等待预设时长；

本公开的所述装置100的另一示例性实施例如图8所示，所述装置还包括缓存10，用于从数据库的缓存中读取所述目标虚拟资源，所述数据库用于存储虚拟资源，所述缓存为执行调用虚拟资源的数据处理方法的设备在所述设备本地缓存的数据。

一示例性实施例如图9所示，图9是根据一示例性实施例示出的一种调用虚拟资源的数据处理装置框图，其中10为数据库缓存(或称为缓存)，虚线框表示可以包含在装置100中，也可以不包含在装置100中，添加记录模块804未示出。参照图9，所述装置100还可以包括：

缓存更新模块902，其被配置为，从数据库的缓存中读取所述目标虚拟资源之前或之后，基于监听到的所述数据库的更新事件对所述缓存进行重加载。

一示例性实施例如图10所示，图10是根据一示例性实施例示出的一种调用虚拟资源的数据处理装置框图，其中10为数据库缓存(或称为缓存)，虚线框表示可以包含在装置100中，也可以不包含在装置100中，添加记录模块602未示出。参照图10，所述装置100还可以包括：

并发优化模块1002，其被配置为，当预期的调用请求的数量达到并发阈值时，延迟缓存时长；

所述缓存更新模块902在延迟所述缓存时长后，基于监听到的所述数据库的更新事件对所述缓存进行重加载。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，具体的可以参照相关方法实施例描述，此处将不做详细阐述说明。

在示例性实施例中，还提供了一种包括指令的计算机可读存储介质，例如包括指令的存储器Z04，上述指令可由设备Z00的处理器Z20执行以完成上述方法。例如，计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供一种计算机程序产品，包括计算机程序，所述计算机程序/指令被处理器执行时实现本说明书中任一项所述的调用虚拟资源的数据处理方法。

图11是根据一示例性实施例示出的一种调用虚拟资源的数据处理方法的设备Z00的框图。例如，设备Z00可以为一个或多个服务器的组合。参照图11，设备Z00包括处理组件Z20，其进一步包括一个或多个处理器，以及由存储器Z22所代表的存储器资源，用于存储可由处理组件Z20的执行的指令，例如应用程序。存储器Z22中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件Z20被配置为执行指令，以执行上述可以实施于服务器的在推荐流量中一种定向保量方的方法。

设备Z00还可以包括一个电源组件Z24被配置为执行设备Z00的电源管理，一个有线或无线网络接口Z26被配置为将设备Z00连接到网络，和一个输入输出(I/O)接口Z28。设备Z00可以操作基于存储在存储器Z22的操作***，例如Window12 12erver，Mac O12 X，Unix，Linux，FreeB12D或类似。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其它实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

需要说明的，上述所述的装置、设备、服务器等根据方法实施例的描述还可以包括其它的实施方式，具体的实现方式可以参照相关方法实施例的描述。同时各个方法以及装置、设备、服务器实施例之间特征的相互组合组成的新的实施例仍然属于本公开所涵盖的实施范围之内，在此不作一一赘述。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或描述的装置或单元相互之间的耦合、通信连接等可以是直接和/或间接耦合/连接的方式实现，可以是通过一些标准或自定义的接口、协议等，是电性，机械或其它的形式实现。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。

Claims

1.一种调用虚拟资源的数据处理方法，其特征在于，包括：

根据所述执行状态，相应的执行所述调用请求的预设操作。

2.根据权利要求1所述的方法，其特征在于，所述在存储所述虚拟资源发放记录的发放记录表进行查询之后，还包括：

将所述目标虚拟资源的发放记录更新到所述发放记录表中。

3.根据权利要求2所述的方法，其特征在于，所述加载所述目标虚拟资源包括：

4.根据权利要求3所述的方法，其特征在于，从数据库的缓存中读取所述目标虚拟资源之前或之后，还包括：

5.一种调用虚拟资源的数据处理装置，其特征在于，包括：

6.根据权利要求5所述的装置，其特征在于，所述装置还包括：

7.根据权利要求6所述的装置，其特征在于，所述装置还包括缓存，用于从数据库的缓存中读取所述目标虚拟资源，所述数据库用于存储虚拟资源，所述缓存为执行调用虚拟资源的数据处理方法的设备在所述设备本地缓存的数据。

8.一种服务器，其特征在于，包括：

至少一个处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至4中任一项所述的调用虚拟资源的数据处理方法。

9.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令服务器的处理器执行时，使得所述服务器能够执行如权利要求1至4中任一项所述的调用虚拟资源的数据处理方法。

10.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至4中任一项所述的调用虚拟资源的数据处理方法。