CN114461957A - 一种道具发放方法、装置、设备及存储介质 - Google Patents

Abstract

本申请实施例公开了一种道具发放方法、装置、设备及存储介质。本申请实施例提供的技术方案通过代理服务端统一接收业务端发出的道具发放请求，并道具发放请求保存到代理服务端的消息队列中，并从代理服务端的消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验，在道具发放请求通过资源发放核验时，调用道具发放请求对应的道具发放系统的道具发放接口，以使道具发放系统根据道具发放请求向目标客户端发放对应道具，向业务端提供统一的道具发放接口，业务系统不需要对接不同的道具发放系统的道具发放接口，降低业务端对道具发放的复杂度，降低对后期维护难度，提高道具发放效率。

Description

一种道具发放方法、装置、设备及存储介质

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种道具发放方法、装置、设备及存储介质。

背景技术

随着网络和计算机技术的发展，利用安装在移动终端上的应用程序进行的各项活动越来越多，并且应用程序在使用时，存在向应用程序发放道具的需求，例如向应用程序发放礼物、消耗物品等道具。目前，不同的应用程序一般是单独设置道具发放系统的道具发放接口，以供业务端进行调用，并进行活动过程中的道具发放。

但是，由于不同的应用程序对应的道具发放接口是不一样的，需要业务端分别对接不同的道具发放接口，但是不同的道具发放接口之间的接入逻辑都不一致，导致业务端的接入代码逻辑复杂，不利于后期维护。

发明内容

本申请实施例提供一种道具发放方法、装置、设备及存储介质，以解决现有技术中不同的道具发放接口之间的接入逻辑不一致导致业务端的接入代码逻辑复杂，不利于后期维护的技术问题，向业务端提供统一的道具发放接口，降低业务端对道具发放的复杂度，降低对后期维护难度。

在第一方面，本申请实施例提供了一种道具发放方法，包括：

接收代理服务端推送的道具发放请求，将所述道具发放请求保存在配置的消息队列中，所述代理服务端推送的道具发放请求由业务端提供；

从所述消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验；

根据通过资源发放核验的道具发放请求，调用对应道具发放系统的道具发放接口，以使所述道具发放系统根据所述道具发放请求向目标客户端发放对应道具。

在第二方面，本申请实施例提供了一种道具发放装置，包括请求获取模块、资源核验模块和道具发放模块，其中：

所述请求获取模块，用于接收代理服务端推送的道具发放请求，将所述道具发放请求保存在配置的消息队列中，所述代理服务端推送的道具发放请求由业务端提供；

所述资源核验模块，用于从所述消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验；

所述道具发放模块，用于根据通过资源发放核验的道具发放请求，调用对应道具发放系统的道具发放接口，以使所述道具发放系统根据所述道具发放请求向目标客户端发放对应道具。

在第三方面，本申请实施例提供了一种道具发放设备，包括：存储器以及一个或多个处理器；

所述存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面所述的道具发放方法。

在第四方面，本申请实施例提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如第一方面所述的道具发放方法。

本申请实施例通过代理服务端统一接收业务端发出的道具发放请求，并道具发放请求保存到代理服务端的消息队列中，并从代理服务端的消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验，在道具发放请求通过资源发放核验时，调用道具发放请求对应的道具发放系统的道具发放接口，以使道具发放系统根据道具发放请求向目标客户端发放对应道具，向业务端提供统一的道具发放接口，业务系统不需要对接不同的道具发放系统的道具发放接口，降低业务端对道具发放的复杂度，降低对后期维护难度，提高道具发放效率。

附图说明

图1是本申请实施例提供的一种道具发放方法的流程图；

图2是本申请实施例提供的另一种道具发放方法的流程图；

图3是本申请实施例提供的一种代理服务端上的道具发放下单流程示意图；

图4是本申请实施例提供的一种道具发放流程示意图；

图5是本申请实施例提供的一种道具发放系统的系统架构示意图；

图6是本申请实施例提供的一种道具发放装置的结构示意图；

图7是本申请实施例提供的一种道具发放设备的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图对本申请具体实施例作进一步的详细描述。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部内容。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时上述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。上述处理可以对应于方法、函数、规程、子例程、子程序等等。

图1给出了本申请实施例提供的一种道具发放方法的流程图，本申请实施例提供的道具发放方法可以由道具发放装置来执行，该道具发放装置可以通过硬件和/或软件的方式实现，并集成在道具发放设备中。

下述以道具发放装置执行道具发放方法为例进行描述。参考图1，该道具发放方法包括：

S101：接收代理服务端推送的道具发放请求，将道具发放请求保存在配置的消息队列中，代理服务端推送的道具发放请求由业务端提供。

其中，本实施例提供的代理服务端用于提供代理服务(Proxy服务)，代理服务端向各个业务端(业务系统)提供统一且通用的发放接口(API)，业务端在需要向目标客户端发送道具时，通过代理服务端提供的发放接口，向代理服务端发送道具发送请求。进一步的，代理服务端还配置有消息队列，消息队列用于保存道具发放请求，其中消息队列可以是RocketMQ队列。其中，代理服务端和消息队列可以是布置在同一服务器中，也可以是布置在不同服务器中(例如同一地区的不同服务器)。

代理服务端推送的道具发放请求由业务端提供，具体的，业务端根据所需要发送的道具以及目标客户端生成道具发放请求，并通过代理服务端提供的发放接口向代理服务端发送道具发放请求。代理服务端在接收到业务端上传的道具发放请求时，将道具发放请求保存在预先配置好的消息队列中，以等待道具发放装置从消息队列中进行消费并获取消息队列中的道具发放请求。其中，一个代理服务端可配置多个消息队列，同样的，一个消息队列可配置到多个代理服务端中，例如在一个地区中配置一个或多个消息队列，该地区的所有代理服务端统一配置该地区的一个或多个消息队列。可以理解的是，道具发放装置从消息队列中获取到的道具发放请求，可以是来自同一代理服务端，也可以是来自不同的代理服务端。

在一个实施例中，为了满足全球化的道具发放场景，代理服务端可支持各个地区独立部署，业务端可选择接入就近的代理服务端，当一个地区的代理服务端出现问题时，可将业务端的道具发放请求临时调度到其他地区的代理服务端，提高Proxy服务的可用性。

S102：从消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验。

本实施例提供的道具发放装置作为道具发放流程的Worker服务，负责对道具发放请求的资源发放逻辑，完成对道具发放请求的资源发放核验，以及执行后续的道具发放流程。其中，资源发放核验根据道具发放请求匹配到具体的资源发放实现，确定是否可按照道具发放请求向目标客户端发放对应的道具。

若道具发放请求未能通过资源发放核验，则停止对该道具发放请求的道具发放流程，并向业务端反馈对应的道具发放失败通知，并从消息队列中获取下一个道具发放请求进行资源发放核验。若道具发放请求通过资源发放核验，则跳转到步骤S103中，执行真正的道具发放接口。

需要进行解释的是，本方案提供的接收代理服务端推送的道具发放请求，将道具发放请求保存在配置的消息队列中的步骤，以及从消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验的步骤之间并没有确定的先后顺序，在实际执行过程中，S101和S102可以是有先后顺序的，也可以是同步执行的。

S103：根据通过资源发放核验的道具发放请求，调用对应道具发放系统的道具发放接口，以使道具发放系统根据道具发放请求向目标客户端发放对应道具。

示例性的，在资源发放请求通过资源发放核验时，确定道具发放请求所需要向目标客户端发放道具对应的道具发放系统的道具发放接口，并调用该道具发放接口，通知道具发放系统根据道具发放请求向目标客户端发放对应道具。其中，目标客户端安装有道具发放请求对应的应用程序，目标客户端在接收到道具发放系统发放的道具时，将在相应应用程序上更新对应道具的拥有数量，并在应用程序的运行界面上进行显示。

上述，通过代理服务端统一接收业务端发出的道具发放请求，并道具发放请求保存到代理服务端的消息队列中，并从代理服务端的消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验，在道具发放请求通过资源发放核验时，调用道具发放请求对应的道具发放系统的道具发放接口，以使道具发放系统根据道具发放请求向目标客户端发放对应道具，向业务端提供统一的道具发放接口，业务系统不需要对接不同的道具发放系统的道具发放接口，降低业务端对道具发放的复杂度，降低对后期维护难度，提高道具发放效率。

在上述实施例的基础上，图2给出了本申请实施例提供的另一种道具发放方法的流程图，该道具发放方法是对上述道具发放方法的具体化。参考图2，该道具发放方法包括：

S201：接收代理服务端推送的道具发放请求，将道具发放请求保存在配置的消息队列中，代理服务端推送的道具发放请求由业务端提供。

本实施例提供的代理服务端配置有流水数据库，该流水数据库用于保存业务端发送的道具发放请求，以及向道具发放装置所配置的消息队列提供道具发放请求。其中流水数据库可以是MySql数据库。其中，代理服务端和流水数据库可以是布置在同一服务器中，也可以是布置在不同服务器中(例如同一地区的不同服务器)。其中，代理服务端提供一组通用的发放接口，供业务端(例如web侧业务系统)接入使用，业务端只需要对接一次发放接口，后续就可以实现各种客户端的道具发放。同时为了方便原先业务端的迁移接入，代理服务端还提供一系列兼容原有的道具发放接口，这些道具发放接口可保持与原有格式一致，减小业务迁移成本，而复杂的接口转换逻辑可提交给代理服务端进行处理。为了满足全球化的应用场景，代理服务端还可支持各个大区独立部署，业务端可以选择就近的代理服务端接入，当一个大区的代理服务端出现问题，还可以临时调度到其他大区的代理服务端，提高代理服务的可用性。

在一个实施例中，代理服务端在接收到业务端发送的道具发放请求后，将道具发放请求发送至配置的流水数据库，以使流水数据库向消息队列推送接收到的道具发放请求。

具体的，代理服务端在接收到业务端发送的道具发放请求后，将道具发送请求作为订单流水保存到流水数据库中，由流水数据库取出订单流水(道具发放请求)，并向数据队列发送道具发送请求，若出现道具发放请求发送失败或异常的情况，流水数据库将按照设定的重试策略重新向数据队列发送道具发放请求，确保道具发放请求可正常发送至数据队列。

在一个实施例中，代理服务端向业务端提供通用的道具发放接口(即设定的通用接口)，并兼容原有的道具发放接口，业务端可根据实际需求选择调用通用的道具发放接口或原有的道具发放接口。基于此，代理服务端在将道具发放请求发送至配置的流水数据库之前，确定道具发放请求对应的道具发放接口是否为设定的通用接口；在道具发放接口为非通用接口时，代理服务端根据通用接口对道具发放请求进行参数转换。

具体的，代理服务端在接收到业务端发送的道具发放请求后，判断该道具发放请求对应的道具发放接口是否为设定的通用接口，若该道具发放请求对应的道具发放接口不是设定的通用接口，则根据通用接口对应的接口格式对接收到的道具发放请求进行参数转换。其中，道具发放请求携带有道具ID、发放数量、发放时间、目标用户等信息，对应的，在对道具发放请求进行参数转换时，按照通用接口的接口格式对道具发放请求携带的道具ID、发放数量、发放时间、目标用户等信息进行转换。

在一个实施例中，代理服务端在将道具发放请求发送至配置的流水数据库后，向业务端反馈道具发放请求的推送结果，告知业务端已将道具发放请求推送到流水数据库中，等到消息队列从流水数据库获取道具发放请求即可实现对应的道具发放。

本方案通过将道具发放请求保存到流水数据库中，由流水数据库负责道具发放请求向消息队列的发送与重试，保证道具发放请求正常发送至消息队列，完成对道具发放请求的有效响应。

在一个实施例中，代理服务端在将道具发放请求发送至配置的流水数据库之前，还可先对道具发放请求进行前置校验，若道具发放请求通过前置校验，则将道具发放请求发送到流水数据库，若未能通过前置校验，则停止响应该道具发放请求，并通知业务端前置校验失败。其中，对道具发放请求的前置校验可以是校验所要求发放的道具所对应的活动是否已经开始或结束、道具发放请求相关参数是否正常等。

图3是本申请实施例提供的一种代理服务端上的道具发放下单流程示意图，如图3所示，以Proxy代理服务执行道具发放下单流程为例，各个业务端可根据所需要发放的道具和目标客户端生成道具发放请求，并调用代理服务端提供的发放接口，代理服务端在接收到各个业务端发送的分别判断道具发放请求对应的道具发放接口是否为设定的通用接口，若不是通用接口，则对道具发放请求进行参数转换。在完成对道具发放请求的参数转换或对应的道具发放接口为设定的通用接口时，对道具发放请求进行前置校验。若前置校验失败，则停止对该道具发放请求的响应并通知对应的业务端前置校验失败；若前置校验成功，则根据道具发放请求生成流水订单并添加到流水数据库中，后续Proxy代理服务将会异步将流水数据库中保存的道具发放请求(订单流水)推送到道具发放装置的消息队列(例如RocketMQ队列)中，等待道具发放装置的后续处理。另外，在向消息队列推送道具发放请求的过程中出现异常时，将进入预先设定的异常处理流程，重新向消息队列推送道具发放请求，保证完成对道具发放请求的推送。

S202：确定道具发放请求对应的道具类型，并根据道具类型确定对道具发放请求的核验策略。

在从消息队列中获取道具发放请求后，需要去顶对道具发放请求进行资源发放核验所依据的核验策略，其中，不同的道具类型对应不同的核验策略。其中道具发放请求所请求发放的道具对应的道具类型可根据道具发放请求携带的道具ID进行确认。

在一个实施例中，核验策略包括剩余预算核验策略、黑名单核验策略和配置参数核验策略中的一种或多种的组合。其中剩余预算核验策略用于指示对应道具的发放量是否达到的预算额度，从而判断是否可按照道具发放请求发放道具；黑名单核验策略用于指示道具包发放请求对应的目标用户端是否在用户黑名单中，从而判断是否可按照道具发放请求发放道具；配置参数核验策略用于指示道具发放请求对应的配置参数是否正常，从而判断是否可按照道具发放请求发放道具。其中道具发放请求对应的配置参数可以是所要求发放的道具所对应的活动信息、目标用户端的用户信息、要求发放道具的时间、道具发放请求的格式等。其中，对道具发放请求的核验策略可以是单一的核验策略，也可以是多种核验策略的组合，在确定为多种核验策略的组合时，需要通过所确定的全部核验策略才认为通过资源发放核验。

示例性的，假设道具类型包括一般道具和有价值道具，可以理解的是，有价值道具相对于一般道具，其重要性更高，可对要求发放有价值道具的道具发放请求进行更严格的资源发放核验，即道具类型对应的重要性越高，其核验策略越严格。例如对发放数量要求不严格的一般道具的核验策略可以是包括黑名单核验策略和配置参数核验策略中的一种或两种的组合，而对发放数量要求严格的有价值道具的核验策略可以是包括剩余预算核验策略、黑名单核验策略和配置参数核验策略三种的组合。

在一个实施例中，在从消息队列中获取道具发放请求后，先对获取的道具发放请求进行后置校验，若道具发放请求未能通过后置校验，则停止响应该道具发放请求，并通知业务端后端校验失败，若道具发放请求通过后置校验，再进一步对道具发放请求进行资源发放核验。

S203：从消息队列中获取道具发放请求，基于确定的核验策略对获取的道具发放请求进行资源发放核验。

其中，核验策略包括剩余预算核验策略、黑名单核验策略和配置参数核验策略中的一种或多种的组合，基于此，本方案在基于确定的核验策略对获取的道具发放请求进行资源发放核验时，包括以下至少一种：

S2031：基于剩余预算核验策略，确定道具发放请求对应道具的预算额度，并判断预算额度是否满足道具发放请求对应道具的发放数量要求。

在基于剩余预算核验策略对获取的道具发放请求进行资源发放核验时，确定道具发放请求对应道具的预算额度，并判断预算额度是否满足道具发放请求对应道具的发放数量要求(判断剩余预算数量是否满足当前道具发放数量的要求)，若满足道具发放请求对应道具的发放数量要求，则确定道具发放请求通过剩余预算核验，否则确定道具发放请求未通过剩余预算核验，并向对应业务端发送道具发放完毕通知，暂停对应道具的发放，需要等待增加对应道具的预算额度之后才继续对应道具的发放，以减少道具的发放超出预算的情况。同时，在发放对应道具后，统计对应道具的发放数量，方便了解发放了多少有价值的道具，并更新该道具对应的剩余预算数量。

S2032：基于黑名单核验策略，确定道具发放请求对应的用户黑名单，并判断道具发放请求对应的目标客户端是否在用户黑名单中。

在基于黑名单核验策略对获取的道具发放请求进行资源发放核验时，获取该道具对应的黑名单，并判断道具发放请求对应的目标客户端是否被记录在用户黑名单中。若目标客户端未被记录在用户黑名单中，则确定道具发放请求通过黑名单核验，否则确定道具发放请求未通过黑名单核验，并向对应业务端发送黑名单通知，暂停对应道具的发放。

S2033：基于配置参数核验策略，确定道具发放请求对应的配置参数范围，并判断道具发放请求对应的配置参数是否在配置参数范围内。

在基于配置参数核验策略对获取的道具发放请求进行资源发放核验时，获取该道具发放请求所要求发放的道具对应的配置参数范围，并判断当前道具发放请求对应的配置参数是否在配置参数范围内，例如判断当前时间是都在所要求发放的道具所对应的活动时间范围内、目标用户端的用户信息是否正常、要求发放道具的时间是否在设定的道具发放时间范围内、道具发放请求的格式是否符合设定格式等。若道具发放请求对应的配置参数均在配置参数范围内，则确定道具发放请求通过配置参数核验，否则确定道具发放请求未通过配置参数核验，并向对应业务端发送参数异常通知，暂停对应道具的发放。

在一个实施例中，在道具发放装置中配置资源发放实现脚本，资源发放实现脚本可用于根据道具发放请求匹配响应的资源发放实现，执行对应的发放流程，并对道具发放请求进行资源发放核验。其中，不同的资源发放实现脚本对应不同的资源ID，可根据资源ID来确定需要加载的资源发放实现脚本，并基于加载的资源发放实现脚本进行资源发放核验。其中，业务端在发出道具发放请求的同时，附带上对应的资源ID，即道具发放请求同时携带有资源ID、道具ID、发放数量、发放时间、目标用户。

其中，资源可理解为道具发放系统的接口，一个资源可对应一种或多种道具，即一个资源可提供一种或多种不同的道具。本方案采用Java语言进行代理服务和道具发放装置的开发，在设计上利用Java语言中提供的接口可多继承的特性，将道具发放系统的道具发放抽象出一个通用接口，并定义为资源，任何对此接口的具体实现，均表示某一类具体的资源，这里可以用资源去描述某一个具体应用的道具发放接口，甚至只是某个应用的道具发放接口下的某个特定道具。资源发放实现脚本可以是Groovy脚本，资源的接入只需要按照设定的规则实现Groovy接口，同时也利用了Groovy可动态加载的特性，Groovy脚本的新增和修改都可以动态加载到系统，不需要重启道具发放装置。

S204：根据通过资源发放核验的道具发放请求，调用对应道具发放系统的道具发放接口，以使道具发放系统根据道具发放请求向目标客户端发放对应道具。

在道具发放请求通过资源发放核验时，调用对应道具发放系统的道具发放接口，由道具发放系统根据道具发放请求向目标客户端发放对应道具。其中，对应道具发放系统的道具发放接口可由资源发放实现脚本进行确定，即在资源发放实现脚本中记录有所需要调用的道具发放接口、接口调用方式以及对道具发放系统返回信息的处理方式。

在一个实施例中，在道具发放失败时，可利用RocketMQ队列的延时队列按照设定的重试时间间隔发起道具发放重试，还可以是放弃重新发放道具，并记录道具发放失败的信息，由运维人员进行处理。对于照设定的重试时间间隔发起道具发放重试，本方案在根据通过资源发放核验的道具发放请求，调用对应道具发放系统的道具发放接口之后，还包括：

S205：按照设定的重试时间间隔从消息队列中获取道具发放失败的道具发放请求，重新调用对应道具发放系统的道具发放接口。

具体的，道具发放装置照设定的重试时间间隔从消息队列中获取道具发放失败的道具发放请求，并重新对道具发放请求进行后置校验和资源发放核验。在道具发放请求通过后置校验和资源发放核验时，重新调用对应道具发放系统的道具发放接口，由道具发放系统重新根据道具发放请求向目标客户端发放对应道具，直至达到设定的重试次数。

在一个实施例中，可利用预先配置的可视化的监控系统对消息队列和流水数据库中的数据进行监控，并对消息队列和流水数据库中的数据进行汇总并形成报表，并对报表进行可视化展示。Worker服务将需要监控的信息上报到RocketMQ队列，可视化的监控系统采集RocketMQ队列中记录的数据后写入到预先配置的时序数据库(例如ClickHouse数据库)中，由时序数据库实现数据的可视化。

图4是本申请实施例提供的一种道具发放流程示意图，如图4所示，以Worker服务作为道具发放装置执行道具发放流程为例进行描述，Worker服务从RocketMQ队列拉取订单(即道具发放请求)，并对道具发放请求进行后置校验。在道具发放请求通过后置校验后，进一步基于Groovy脚本定于的各种资源实现，对道具发放请求进行资源发放核验，并在通过资源发放核验时，调用对应道具发放系统的道具发放接口，以执行对道具发放接口的实际发放调用，从而以使道具发放系统根据道具发放请求向目标客户端发放对应道具。而在道具发放过程中出现道具发放异常时，进入设定的异常处理流程，例如利用RocketMQ队列的延时队列按照设定的重试时间间隔发起道具发放重试，并在进行道具发放处理后，执行相关的处理结果通知流程(例如向业务端或运维端发送道具发放结果)。

图5是本申请实施例提供的一种道具发放系统的系统架构示意图，如图5所示，该道具发放系统采用微服务架构设计，并提供Proxy服务、Admin服务、Worker服务和Job服务4个核心服务，其中Proxy服务用于实现本方案提供的代理服务端的功能，Worker服务用于实现本方案道具发放装置的功能。具体的，Proxy服务提供了一组通用的发放接口，供web侧的业务系统(即业务端)接入使用，业务系统只需要对接一次，后续就可以实现各种应用程序下对目标客户端的道具发放。同时，为了方便旧的业务系统迁移接入，Proxy服务还提供一系列兼容原来应用程序道具发放的接口，这些接口和原有接口格式基本一致，业务系统不需要对接口代码进行过多的改变，减小业务迁移成本，而复杂的转换逻辑交由Proxy服务内部进行。Worker服务作为核心的发放处理引擎，主要任务是通过加载由groovy脚本定义的各种资源及活动相关配置，完成从RocketMQ队列消费Proxy服务传过来的订单数据(即道具发放请求)，执行对应的道具发放处理逻辑后，完成对目标客户端的道具发放。Proxy服务和Worker服务分别执行上述实施例中服务端和道具发放装置所实现的功能，并实现对业务系统发出的道具发放请求的响应以及对目标用户端的道具发放，本处不再赘述。

进一步的，Admin服务用于提供管理相关的接口，用于管理活动、资源等配置信息，同时也支持了部分开放接口，原有的业务系统可以通过这些开放接口同步原有的活动信息，从而继续使用原有系统，减少新系统的学习成本。其中Job服务用于执行与第三方系统核心数据同步任务等，比如和预算系统进行预算相关数据同步，同时也处理统计/监控上报等任务。同时，道具发放系统所依赖的组件包括MySql数据库、Redis数据库、RabbitMQ队列和ClickHouse数据库，其中，MySql数据库作为流水数据库，实现订单发放一致性管理，预算一致性管理等功能，并且基于全球化的需求，配置有多套独立流水库，道具发放系统设计也充分利用这多套流水数据库，实现异地多数据库灾备功能，为Proxy服务带来更高的可用性。其中，Worker服务可利用Redis实现类似缓存/订单去重等功能。RabbitMQ队列作为一个全球化的发奖系统，可用于接收各大区的道具发放请求，另外也可用于道具发放异常处理。ClickHouse数据库可用于存储道具发放请求的流水信息，方便后期统计、监控等场景上的应用，Worker服务可将需要进行监控的数据上报到RocketMQ队列中，并由Job服务从RocketMQ队列中采集对应数据并发送到ClickHouse数据库进行可视化处理。另外，道具发放系统还提供对各个消息队列和数据库经数据监控的监控系统，其主要利用Grafana工具将ClickHouse中存储的信息进行可视化处理，并以图表形式呈现。

通过道具发放系统聚合各个道具发放系统的道具发放接口，业务系统只需要对接一套通用的发放接口，后续如果要新增其他应用程序的道具发放接口，只需要由道具发放系统统一处理接入，业务系统只要修改对应参数即可实现新应用程序的道具发放，降低了业务系统接入道具发放系统的复杂度，提高接入效率，简化业务对接流程。同时，道具发放系统集成了包括黑名单/预算风控等功能，将Groovy脚本和Java的接口相结合，即解决了Java作为一门静态语言，不方便进行动态扩展的缺点，也通过接口定义约束了Groovy脚本的实现，利用接口的特性，保证了通过Groovy实现的资源发放逻辑能够被符合规定地安全加载，并且有足够的扩展性，可以约束各种高价值道具的发放，降低了因配置错误导致活动道具超发的情况，并通过数据上报ClickHouse以及Grafana可视化配置，形成按各种维度的统计报表，方便进行道具发放的监控告警等。并通过Proxy服务、Admin服务、Worker服务和Job服务的协作完成整个道具发放流程，既能有效的完成道具的发放处理，也能方便与各类已有的第三方业务系统的结合，具备较高的可用性。

上述，通过代理服务端统一接收业务端发出的道具发放请求，并道具发放请求保存到代理服务端的消息队列中，并从代理服务端的消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验，在道具发放请求通过资源发放核验时，调用道具发放请求对应的道具发放系统的道具发放接口，以使道具发放系统根据道具发放请求向目标客户端发放对应道具，向业务端提供统一的道具发放接口，业务系统不需要对接不同的道具发放系统的道具发放接口，降低业务端对道具发放的复杂度，降低对后期维护难度，提高道具发放效率。同时，根据道具类型确定对应的核验策略对道具发放请求进行资源发放核验，实现对道具发放请求的针对性核验，提高对不同道具发放的适用性。并且兼容原先的道具发放接口，不需要业务端道具发送请求的参数转换，减少业务迁移成本。由流水数据库负责道具发放请求向消息队列的发送与重试，保证道具发放请求正常发送至消息队列，完成对道具发放请求的有效响应。

图6是本申请实施例提供的一种道具发放装置的结构示意图。参考图6，该道具发放装置包括请求获取模块61、资源核验模块62和道具发放模块63。

其中，请求获取模块61，用于接收代理服务端推送的道具发放请求，将道具发放请求保存在配置的消息队列中，代理服务端推送的道具发放请求由业务端提供；资源核验模块62，用于从消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验；道具发放模块63，用于根据通过资源发放核验的道具发放请求，调用对应道具发放系统的道具发放接口，以使道具发放系统根据道具发放请求向目标客户端发放对应道具。

上述，通过代理服务端统一接收业务端发出的道具发放请求，并道具发放请求保存到代理服务端的消息队列中，并从代理服务端的消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验，在道具发放请求通过资源发放核验时，调用道具发放请求对应的道具发放系统的道具发放接口，以使道具发放系统根据道具发放请求向目标客户端发放对应道具，向业务端提供统一的道具发放接口，业务系统不需要对接不同的道具发放系统的道具发放接口，降低业务端对道具发放的复杂度，降低对后期维护难度，提高道具发放效率。

本申请实施例还提供了一种道具发放设备，该道具发放设备可集成本申请实施例提供的道具发放装置。图7是本申请实施例提供的一种道具发放设备的结构示意图，参考图7，该道具发放设备包括：输入装置73、输出装置74、存储器72以及一个或多个处理器71；存储器72，用于存储一个或多个程序；当一个或多个程序被一个或多个处理器71执行，使得一个或多个处理器71实现如上述实施例提供的道具发放方法。上述提供的道具发放装置、设备和计算机可用于执行上述任意实施例提供的道具发放方法，具备相应的功能和有益效果。

本申请实施例还提供一种包含计算机可执行指令的存储介质，计算机可执行指令在由计算机处理器执行时用于执行如上述实施例提供的道具发放方法。当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上提供的道具发放方法，还可以执行本申请任意实施例所提供的道具发放方法中的相关操作。上述实施例中提供的道具发放装置、设备及存储介质可执行本申请任意实施例所提供的道具发放方法，未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的道具发放方法。

上述仅为本申请的较佳实施例及所运用的技术原理。本申请不限于这里提供的特定实施例，对本领域技术人员来说能够进行的各种明显变化、重新调整及替代均不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由权利要求的范围决定。

Claims (10)

1.一种道具发放方法，其特征在于，包括：

接收代理服务端推送的道具发放请求，将所述道具发放请求保存在配置的消息队列中，所述代理服务端推送的道具发放请求由业务端提供；

从所述消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验；

根据通过资源发放核验的道具发放请求，调用对应道具发放系统的道具发放接口，以使所述道具发放系统根据所述道具发放请求向目标客户端发放对应道具。

2.根据权利要求1所述的道具发放方法，其特征在于，所述对获取的道具发放请求进行资源发放核验之前，还包括：

确定所述道具发放请求对应的道具类型，并根据所述道具类型确定对道具发放请求的核验策略。

3.根据权利要求2所述的道具发放方法，其特征在于，所述核验策略包括剩余预算核验策略、黑名单核验策略和配置参数核验策略中的一种或多种的组合；

所述对获取的道具发放请求进行资源发放核验，包括以下至少一种：

基于剩余预算核验策略，确定所述道具发放请求对应道具的预算额度，并判断所述预算额度是否满足所述道具发放请求对应道具的发放数量要求；

基于黑名单核验策略，确定所述道具发放请求对应的用户黑名单，并判断所述道具发放请求对应的目标客户端是否在所述用户黑名单中；

基于配置参数核验策略，确定所述道具发放请求对应的配置参数范围，并判断所述道具发放请求对应的配置参数是否在所述配置参数范围内。

4.根据权利要求1所述的道具发放方法，其特征在于，所述代理服务端在接收到业务端发送的道具发放请求后，将所述道具发放请求发送至配置的流水数据库，以使所述流水数据库向所述消息队列推送接收到的道具发放请求。

5.根据权利要求4所述的道具发放方法，其特征在于，所述代理服务端在将道具发放请求发送至配置的流水数据库之前，确定所述道具发放请求对应的道具发放接口是否为设定的通用接口；在所述道具发放接口为非通用接口时，所述代理服务端根据所述通用接口对所述道具发放请求进行参数转换。

6.根据权利要求1所述的道具发放方法，其特征在于，所述方法还包括：

按照设定的重试时间间隔从所述消息队列中获取道具发放失败的道具发放请求，重新调用对应道具发放系统的道具发放接口。

7.根据权利要求1所述的道具发放方法，其特征在于，所述代理服务端在将所述道具发放请求发送至配置的流水数据库后，向所述业务端反馈所述道具发放请求的推送结果。

8.一种道具发放装置，其特征在于，包括请求获取模块、资源核验模块和道具发放模块，其中：

所述请求获取模块，用于接收代理服务端推送的道具发放请求，将所述道具发放请求保存在配置的消息队列中，所述代理服务端推送的道具发放请求由业务端提供；

所述资源核验模块，用于从所述消息队列中获取道具发放请求，对获取的道具发放请求进行资源发放核验；

所述道具发放模块，用于根据通过资源发放核验的道具发放请求，调用对应道具发放系统的道具发放接口，以使所述道具发放系统根据所述道具发放请求向目标客户端发放对应道具。

9.一种道具发放设备，其特征在于，包括：存储器以及一个或多个处理器；

所述存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-7任一项所述的道具发放方法。

10.一种包含计算机可执行指令的存储介质，其特征在于，所述计算机可执行指令在由计算机处理器执行时用于执行如权利要求1-7任一项所述的道具发放方法。

Images