CN114339270A - 直播中发放物品的控制方法、系统、电子设备及存储介质 - Google Patents

Abstract

本申请涉及网络信息技术领域，公开了一种直播中发放物品的控制方法、系统、电子设备及存储介质，提高了物品发放时的安全性和稳定性，该系统包括：业务控制模块和发放控制模块；业务控制模块，用于根据直播过程中针对目标任务的任务完成消息，生成物品发放请求，物品发放请求包括发放给目标对象的物品信息；发放控制模块，用于若确定物品发放请求满足目标任务对应的物品发放条件，则控制对应的物品发放模块将物品发放请求中的物品信息对应的目标物品发放给目标对象。

Description

直播中发放物品的控制方法、系统、电子设备及存储介质

技术领域

本申请涉及网络信息技术领域，尤其涉及一种直播中发放物品的控制方法、系统、电子设备及存储介质。

背景技术

随着网络技术的发展以及智能终端设备的普及，人们越来越习惯于通过网络进行购物、娱乐以及社交，如观看直播、玩网络游戏。为了增加用户粘性，各平台运营商、商家、主播等经常会设计各类在线活动，通过抽奖等形式将设定的物品发放给符合一定条件的用户，设定的物品可以是优惠券、代金券、游戏装备、会员卡、虚拟货币等各种虚拟物品，也可以是真实物品。但是，现有的物品发放过程，通常是由活动主办方设计的活动逻辑模块直接调用相应的物品发放模块完成物品的发放，直接向活动主办方开放物品发放模块，容易给物品发放过程带来安全隐患，导致错发、少发、漏发的情况频发，且遭到恶意攻击，降低了物品发放的安全性和稳定性。

发明内容

本申请实施例提供一种直播中发放物品的控制方法、系统、电子设备及存储介质，提高了物品发放时的安全性和稳定性。

一方面，本申请一实施例提供了一种直播中发放物品的控制系统，包括：

业务控制模块和发放控制模块；

所述业务控制模块，用于根据直播过程中针对目标任务的任务完成消息，生成物品发放请求，所述物品发放请求包括发放给目标对象的物品信息；

所述发放控制模块，用于若确定所述物品发放请求满足所述目标任务对应的物品发放条件，则控制对应的物品发放模块将所述物品发放请求中的物品信息对应的目标物品发放给所述目标对象。

一方面，本申请一实施例提供了一种直播中发放物品的控制方法，包括：

接收物品发放请求，其中，所述物品发放请求是根据直播过程中针对目标任务的任务完成消息生成的，所述物品发放请求包括发放给目标对象的物品信息；

若确定所述物品发放请求满足所述目标任务对应的物品发放条件，则控制对应的物品发放模块将所述物品发放请求中的物品信息对应的目标物品发放给所述目标对象。

可选地，所述方法还包括：

从所述业务控制模块获取所述目标任务对应的应发流水记录，所述应发流水记录包括历史生成的所述目标任务对应的物品发放请求；

基于所述发放控制模块存储的所述目标任务对应的请求处理记录和所述应发流水记录，获得未处理的物品发放请求，其中，所述请求处理记录中包括所述目标任务对应的已处理的物品发放请求；

基于所述未处理的物品发放请求，控制对应的物品发放模块将所述未处理的物品发放请求中的物品信息对应的物品发放给所述目标对象。

可选地，所述方法还包括：

从所述业务控制模块获取所述目标任务对应的应发流水记录，所述应发流水记录包括历史生成的所述目标任务对应的物品发放请求；

基于各个物品发放模块获取所述目标任务对应的实发流水记录，所述实发流水记录包括已向目标对象发放所述目标任务对应的物品的记录；

基于所述发放控制模块存储的所述目标任务对应的请求处理记录、所述应发流水记录和所述实发流水记录，获得所述目标任务对应的物品发放对账单，其中，所述请求处理记录中包括所述目标任务对应的已处理的物品发放请求。

可选地，每个物品发放模块对应至少两个发放处理单元；

所述方法还包括：

周期性获取各个物品发放模块对应的发放处理单元的心跳信息，所述心跳信息包括发放处理单元的运行情况；

所述控制对应的物品发放模块将所述物品发放请求中的物品信息对应的目标物品发放给所述目标对象，具体包括：

根据对应的物品发放模块的每个发放处理单元的运行情况，筛选出目标发放处理单元，并控制所述目标发放处理单元将所述物品发放请求中的物品信息对应的目标物品发放给所述目标对象。

可选地，所述方法还包括：

根据所述目标对象的历史操作数据，确定向所述目标对象发放物品的风险等级结果；

所述控制对应的物品发放模块将所述物品发放请求中的物品信息对应的目标物品发放给所述目标对象之前，所述方法还包括：

基于所述风险等级结果确定向所述目标对象发放物品。

一方面，本申请一实施例提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行计算机程序时实现上述任一种方法的步骤。

一方面，本申请一实施例提供了一种计算机可读存储介质，其上存储有计算机程序指令，该计算机程序指令被处理器执行时实现上述任一种方法的步骤。

一方面，本申请一实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一种TCP传输性能的控制的各种可选实现方式中提供的方法。

本申请实施例提供的直播中发放物品的控制方法、系统、电子设备及存储介质，将发放控制模块作为业务控制模块对接各个物品发放模块的唯一入口，并基于发放控制模块中配置的物品发放条件，对发放控制模块接收到的物品发放请求进行校验，仅执行满足物品发放条件的物品发放请求，并控制对应的物品发放模块完成物品发放，使得物品发放模块不会被随意调用，保证物品发放时的安全性和稳定性。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，显而易见地，下面所介绍的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1A为本申请实施例提供的直播中发放物品的控制方法的应用场景示意图；

图1B为本申请实施例提供的直播界面的示意图；

图1C为本申请实施例提供的物品发放系统的结构示意图；

图2为本申请一实施例提供的直播中发放物品的控制系统的结构示意图；

图3为本申请一实施例提供的业务控制模块和发放控制模块之间基于令牌进行消息传递的示意图；

图4为本申请一实施例提供的显示给审批人员的发放审批单的示意图；

图5A为本申请一实施例提供的直播中发放物品的控制系统的结构示意图；

图5B为本申请一实施例提供的直播中发放物品的控制系统的结构示意图；

图6A为本申请一实施例提供的物品发放系统的结构示意图；

图6B为本申请一实施例提供的物品发放系统的结构示意图；

图7为本申请一实施例提供的直播中发放物品的控制方法的流程示意图；

图8为本申请一实施例提供的差异流水检测及补发方法的流程示意图；

图9为本申请一实施例提供的三方对账方法的流程示意图；

图10为本申请一实施例提供的电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

为了方便理解，下面对本申请实施例中涉及的名词进行解释：

直播，即互联网直播，是指基于互联网，以视频、音频、图文等形式向公众持续发布实时信息的活动。

直播间，在本申请实施例中就是服务器创建的一种虚拟空间(或虚拟房间)，主播客户端与观众客户端可以进入到该虚拟空间，位于该虚拟空间内的观众客户端可以不仅观看主播客户端的直播内容，还可以和主播客户端进行语音或文字的交互，例如观众客户端可以在当前在线频道中向喜爱的主播客户端发送礼物等。

消息中间件，是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。目前市场长常见的消息中间件有：ActiveMQ、RabbitMQ、Kafka、RocketMQ、Hippo等。

Redis(Remote Dictionary Server)，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

客户端(Client)或称为用户端，是指与服务器相对应，为客户提供本地服务的程序。除了一些只在本地运行的应用程序之外，一般安装在普通的客户机上，需要与服务端互相配合运行。因特网发展以后，较常用的用户端包括了如万维网使用的网页浏览器，收寄电子邮件时的电子邮件客户端，以及即时通讯的客户端软件等。对于这一类应用程序，需要网络中有相应的服务器和服务程序来提供相应的服务，如数据库服务，电子邮件服务等等，这样在客户机和服务器端，需要建立特定的通信连接，来保证应用程序的正常运行。

附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

现有的在直播过程中发放物品的方式，通常是由活动方设计的活动逻辑模块直接调用相应的物品发放模块完成物品的发放，直接向活动主办方开放物品发放模块，容易给物品发放过程带来安全隐患，导致错发、少发、漏发的情况频发，且易遭到恶意攻击，如羊毛党或黑客的恶意攻击，造成活动方的损失，因此现有的物品发放过程的安全性和稳定性都较低。

为此，本申请提供了一种直播中发放物品的控制系统，具体包括：业务控制模块和发放控制模块；其中，业务控制模块，用于根据直播过程中针对目标任务的任务完成消息，生成物品发放请求，物品发放请求包括发放给目标对象的物品信息；发放控制模块，用于若确定物品发放请求满足目标任务对应的物品发放条件，则控制对应的物品发放模块将物品发放请求中的物品信息对应的目标物品发放给目标对象。在直播中发放物品的控制系统中引入了发放控制模块，作为业务控制模块对接各个物品发放模块的唯一入口，并基于发放控制模块中配置的物品发放条件，对发放控制模块接收到的物品发放请求进行校验，仅执行满足物品发放条件的物品发放请求，并控制对应的物品发放模块完成物品发放，使得物品发放模块不会被随意调用，保证物品发放时的安全性和稳定性。

在介绍完本申请实施例的设计思想之后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施时，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

参考图1A，其为本申请实施例提供的直播中发放物品的控制方法的应用场景示意图。该应用场景包括终端设备101、直播服务器102和物品发放系统103。其中，终端设备101、直播服务器102以及物品发放系统103之间均可通过无线或有线网络连接。终端设备101包括但不限于桌面计算机、智能手机、移动电脑、平板电脑、媒体播放器、智能可穿戴设备、智能电视等电子设备。直播服务器102可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

直播服务器102为终端设备101提供直播服务。终端设备101中安装有支持直播技术的直播客户端，每个终端设备101既可以作为主播终端，也可以作为观众终端。用户可通过主播终端创建一个直播间并进行直播，该用户即为主播，主播终端将采集的音频数据和视频数据发送给直播服务器102，直播服务器102对音频数据和视频数据进行处理后得到直播数据，将直播数据发送给进入该直播间内的观众的观众终端。在直播过程中，进入直播间的观众可通过观众终端向直播服务器102发送弹幕消息，该弹幕消息携带有直播间标识以及观众标识，直播服务器102将弹幕消息添加到该直播间的直播数据中，这样，观众发送的弹幕消息就会展示在直播间直播画面的弹幕展示区域，同样，主播也可以通过上述方式在直播间发送弹幕消息，即直播间的主播和其他观众可通过弹幕消息进行互动。同样地，观众可以通过观众终端给主播送各种道具和礼物，主播可以在直播间发起各种类型的任务，如抽奖、游戏PK赛、主播任务联动等。

直播服务器102还提供了任务设置入口，主播可通过主播终端显示的任务设置入口进行具体任务的配置，配置的任务参数包括业务任务参数和奖励发放参数，其中，业务任务参数可包括：任务类型、参与任务时需要完成的任务、获得奖励物品的奖励规则、任务开始时间、任务结束时间等，物品发放参数可包括：单次发放最大数量、本次任务可发放的物品总数、发放的物品信息、发放方式等，具体的任务参数可根据具体的任务进行自由配置，对此不作限定。主播终端将主播配置的任务参数发送至直播服务器102，直播服务器102接收任务参数，生成本次任务对应的任务标识，每个任务对应一个任务标识，并将任务标识和对应的任务参数关联存储，同时将任务标识和任务参数同步到物品发放系统103中，以完成任务的申请，然后直播服务器102会将任务推送到进入直播间的每个用户(包括主播和观众)的终端设备上。参考图1B，终端设备的直播界面110上会显示任务窗口120，用户点击任务窗口120后终端设备可显示任务详情页面130，任务详情页面130中可包括任务的具体内容、任务进程以及参加任务的方式等信息，用户可通过任务详情页面130查看任务进度以及申请参与任务。

参考图1C，物品发放系统103可包括：业务控制模块1031、发放控制模块1032和多个物品发放模块1033，业务控制模块1031与发放控制模块1032连接，发放控制模块1032分别与多个物品发放模块1033连接，每个物品发放模块1033可用于控制至少一种物品的具体发放流程，通过发放控制模块1032统一管理多个物品发放模块1033。其中，业务控制模块1031、发放控制模块1032和多个物品发放模块1033可分别设置在不同的服务器内，也可以设置在同一服务器内；或者业务控制模块1031可设置在直播服务器102内部，发放控制模块1032和多个物品发放模块1033可设置在另外的服务器内。

直播间内的用户(包括主播和观众)可通过任务详情页面参与任务，在完成任务后，例如赢得PK赛，直播服务器102向业务控制模块1031发送任务完成消息，该任务完成消息中包括完成任务的目标对象的对象标识、任务标识、任务完成情况等信息。业务控制模块1031根据任务标识获得该任务对应的奖励规则，根据奖励规则和任务完成情况，确定发放给该用户的物品种类以及物品数量，并生成物品发放请求，该物品发放请求可包括发放给目标对象的物品信息，该物品信息可包括物品种类、物品数量以及物品价值等。发放控制模块1032基于物品发放请求中的物品信息、目标对象，判断是否向目标对象发放物品；若确定发放，发放控制模块1032确定该物品对应的物品发放模块1033，并控制对应的物品发放模块1033将指定数量的物品发放给目标对象；若确定不发放，则将该物品发放请求标记为未通过请求，并将未通过信息反馈给直播服务器102，由直播服务器102通知对应的用户物品发放失败的消息。

物品发放系统103存储任务标识和任务参数，业务控制模块1031可根据任务参数中的物品总数和物品信息，从任务主办方的账户中扣除相应数量的物品，并暂存到数据存储模块中，数据存储模块中各个任务对应的任务总数和物品信息分开存储，可基于任务标识进行区分，方便后续基于任务标识从数据存储模块中获取相应的物品发放给用户。其中，数据存储模块可以是发放控制模块1032内部的存储单元，也可以是独立于发放控制模块1032的存储设备。

本申请实施例中的物品可以是虚拟物品，如电子优惠券、电子代金券、现金、游戏装备、VIP会员、积分、虚拟货币、虚拟勋章、虚拟道具(如座驾、皮肤、铭牌等)等，当然也可以是真实物品，如杯子、书、电饭煲等。对于虚拟物品，物品发放系统103可直接将虚拟物品发放到目标对象的账号中，如将电子优惠券添加到目标对象的卡包中，增加目标对象的积分等。对于真实物品，物品发放系统103可根据物品信息和目标对象的信息生成配送订单，通知工作人员将物品配送给用户，目标对象的信息中包括目标对象的地址信息和联系方式等。

当然，本申请实施例提供的方法并不限用于图1A～图1C所示的应用场景中，还可以用于其它可能的应用场景，本申请实施例并不进行限制。对于图1A～图1C所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。

为进一步说明本申请实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。

下面结合图1A～图1C所示的应用场景，对本申请实施例提供的技术方案进行说明。

参考图2，本申请实施例提供一种直播中发放物品的控制系统20，包括：业务控制模块201和发放控制模块202。

业务控制模块201用于根据直播过程中针对目标任务的任务完成消息，生成物品发放请求，物品发放请求包括发放给目标对象的物品信息。其中，物品信息可包括物品种类和物品数量等，例如，物品种类为积分，物品数量为100，则目标对象的积分增加100。

其中，目标对象可以是用户，目标对象的对象标识可以是用户唯一对应的身份标识；目标对象也可以是用户使用的终端，对象标识可以是终端标识或者用户登录终端时使用的用户名等标识信息。

具体实施时，用户在选择参与目标任务后，需执行目标任务指定的一系列操作，直播服务器会根据用户的操作确定用户的任务完成情况，若确定用户完成了目标任务指定的一系列操作，则直播服务器会生成任务完成消息并发送给业务控制模块201，此时，任务完成消息可包括：完成任务的目标对象的对象标识、任务标识等信息，其中，对象标识可以是用户登录直播客户端时使用的账号，直播客户端通过该账号区分各用户，并管理每个用户的积分、虚拟货币、历史观看记录等在直播客户端上的数据，每个任务对应一个任务标识，以区分各个任务。业务控制模块201可基于任务完成消息中的任务标识获取对应的奖励规则，确定需要发放给用户的物品的物品信息，基于物品信息和任务完成消息中的对象标识，生成物品发放请求并发送给发放控制模块202。

实际应用中，业务控制模块201内执行的业务逻辑可根据具体需求确定。例如，目标任务为抽奖，参与抽奖前用户需要支付50个积分，未支付50个积分的用户无法参与抽奖并获得物品奖励。当用户点击参与抽奖并支付50个积分后，直播服务器在检验用户支付的积分数量达到50后，向用户的终端设备返回抽奖页面；用户通过抽奖页面进行抽奖操作，终端设备显示用户抽中的物品，将抽中物品的物品信息、任务标识以及用户的对象标识返回给直播服务器；直播服务器根据物品信息、任务标识以及对象标识，生成对应的任务完成消息，并将任务完成消息发送至业务控制模块201。业务控制模块201根据物品信息和对象标识，生成物品发放请求并发送给发放控制模块202。

以目标任务为游戏PK赛为例，用户点击参与游戏PK赛并在游戏PK赛中获得胜利后，直播服务器获得用户赢得游戏PK赛的消息，生成任务完成消息并发送给业务控制模块201，此时，任务完成消息可包括：用户的对象标识、任务标识等信息。业务控制模块201根据任务完成消息中的任务标识获取游戏PK赛的奖励规则，基于奖励规则确定奖励给用户的物品信息，基于物品信息和任务完成消息中的对象标识，生成物品发放请求并发送给发放控制模块202。

具体实施时，一个任务可对应至少一种物品。例如抽奖任务中，可设置多个奖项，每个奖项对应一种物品。奖项和物品种类之间的对应关系可在奖励规则中预先配置。

发放控制模块202用于若确定物品发放请求满足目标任务对应的物品发放条件，则控制对应的物品发放模块203将物品发放请求中的物品信息对应的目标物品发放给目标对象。其中，物品发放条件可以是预先设定好的用于判断是否可以将物品发放给目标对象的条件，具体的物品发放条件可根据应用需求进行配置。具体地，每种物品可对应对一个物品发放模块203，即每个物品发放模块203用于执行至少一种物品的发放操作；每个任务可对应至少一个物品发放条件，或者部分任务可对应相同的物品发放条件。

具体地，发放控制模块202基于物品发放请求中的物品信息、目标对象以及对应的物品发放条件，判断是否向目标对象发放物品；若确定发放，发放控制模块202根据物品和物品发放模块203之间的对应关系，确定该物品对应的物品发放模块203，并控制该物品发放模块203将指定数量的物品发放给目标对象；若确定不发放，则将该物品发放请求标记为未通过请求，并将用于表示请求未通过的提示信息反馈给直播服务器102，由直播服务器102通知对应的用户物品发放失败的消息。

本申请实施例提供的直播中发放物品的控制系统，将发放控制模块作为业务控制模块对接各个物品发放模块203的唯一入口，并基于发放控制模块中配置的物品发放条件，对发放控制模块接收到的物品发放请求进行校验，仅执行满足物品发放条件的物品发放请求，并控制对应的物品发放模块203完成物品发放，使得物品发放模块203不会被随意调用，保证物品发放时的安全性和稳定性。

具体实施时，发放控制模块202中的物品发放条件可根据应用需求进行配置，例如物品发放条件可包括以下至少一种条件：

(1)条件一：已向目标对象发放过目标物品的次数不大于目标任务对应的限定次数。

其中，限定次数是指目标对象参与同一任务的最大次数，例如目标任务对应的限定次数为1，则表示每个目标对象只能参与一次目标任务，当目标任务对应的限定次数为2，则表示每个目标对象最多只能参与两次目标任务。每个任务对应的限定次数可以是不同的，限定次数可以由主播在配置任务参数时设置，也可以是系统默认的值。例如，一般为了让更多目标对象参与到任务中，限定次数可以设置为1、2等较小的数值。

具体实施时，发放控制模块202可以存储每个对象分别对应的历史参与信息列表，历史参与信息列表中的每个历史参与信息包括：对象参与的任务的任务标识、发放的物品信息以及发放时间等信息。基于目标对象的历史参与信息列表，确定目标对象是否参与过目标任务，并获得目标对象参与目标任务的次数以及目标对象获得目标物品的次数。

具体实施时，发放控制模块202可以存储每个任务分别对应的参与对象信息列表，参与对象信息列表中的每个参与对象信息包括：参与该任务的对象的对象标识、发放的物品信息以及发放时间等信息。从目标任务的参与对象信息列表中，确定目标对象是否参与过目标任务，并获得目标对象参与目标任务的次数以及目标对象获得目标物品的次数。

具体地，目标对象获得目标物品的次数即为已向目标对象发放过目标物品的次数，当已向目标对象发放过目标物品的次数不大于目标任务对应的限定次数时，控制对应的物品发放模块203将物品发放请求中的物品信息对应的目标物品发放给目标对象。

(2)条件二：发放给目标对象的目标物品的数量不大于目标任务对应的目标物品的剩余可发放数量。

其中，剩余可发放数量为分配给目标任务的目标物品的总数和已发放的目标物品的数量之差。

具体实施时，主播可在配置任务参数时设置分配给每个任务的物品以及物品的总数，例如，完成任务1后可获得100个积分，任务1对应的积分总数为1000，这样最多可以有10个目标对象可通过完成任务1获得积分。

具体实施时，发放控制模块202可以存储每个任务对应的物品的总数，并记录每个任务对应的已发放物品的数量，从而实时获得每个任务对应的物品的剩余可发放数量。发放控制模块202在收到物品发放请求后，基于物品发放请求中的物品信息，确定本次需要发放给目标对象的目标物品以及发放的目标物品的数量，记为第一数量；然后获得目标物品当前对应的剩余可发放数量，判断第一数量是否大于获得的剩余可发放数量；若第一数量不大于获得的剩余可发放数量，则控制对应的物品发放模块203将第一数量的目标物品发放给目标对象，并将目标物品的剩余可发放数量减去第一数量，获得本次发放操作后的剩余可发放数量；若第一数量大于获得的剩余可发放数量，则可以生成物品余量不足的提示信息，并将该提示信息发送给主播。主播在收到物品余量不足的提示信息后，可选择增加目标物品，若主播选择不增加目标物品，发放控制模块202可向目标对象发送任务已结束的提示信息。

(3)条件三：发放给目标对象的目标物品的数量不大于目标任务对应的单次发放最大数量。

其中，单次发放最大数量是由主播在配置任务参数时设置的，用于限制每次发放给目标对象的物品数量的上限，防止出现大额的发放错误。

具体地，当发放给目标对象的目标物品的数量不大于目标任务对应的单次发放最大数量时，发放控制模块202控制对应的物品发放模块203将目标物品发放给目标对象；当发放给目标对象的目标物品的数量大于目标任务对应的单次发放最大数量时，不进行发放操作，同时可通知主播该异常情况。

(4)条件四：发放给目标对象的目标物品的价值不大于物品发放请求对应的消费价值，物品发放请求对应的消费价值是基于目标对象在完成目标任务过程中的消费操作确定的。

对于需要用户进行消费操作后才能发放物品的场景，发放控制模块202可基于用户的消费操作确定对应的消费价值；当收到物品发放请求时，发放控制模块202基于物品发放请求中的物品信息确定向用户发放的目标物品和发放的数量，基于目标物品和发放的数量，确定发放给目标对象的目标物品的价值，并判断发放给目标对象的目标物品的价值是否大于消费操作对应的消费价值，若是，则不进行发放操作，同时向用户发送发放失败的提示信息，否则控制对应的物品发放模块203将目标物品发放给目标对象。

具体实施时，发放控制模块202会存储每种物品对应的价值，可以物品价格作为物品价值的衡量标准，如物品A的价值是10元，物品B的价值为100元，或者以积分等方式衡量物品的价值，如物品A的价值为100个积分，物品B的价值为200个积分。

以支付积分后换取物品的场景为例，用户的终端设备显示积分换物页面，用户通过积分换物页面支付10个积分，直播服务器接收用户支付10个积分的消费操作后，将消费操作发送给发放控制模块202，发放控制模块202基于该消费操作确定对应的消费价值为10个积分。与此同时，用户的终端设备显示可选择换取的物品，假设用户选择的物品是一张电子优惠券，终端设备将抽奖结果反馈给直播服务器，直播服务器基于用户选择的物品生成物品发放请求并发送至发放控制模块202，发放控制模块202确定电子优惠券的价值，若电子优惠券的价值大于10个积分，则不进行发放操作，否则控制发放电子优惠券的物品发放模块203将电子优惠券发放给用户。

以支付积分后进行抽奖的场景为例，用户的终端设备显示抽奖页面，用户通过抽奖页面支付10个积分，直播服务器接收用户支付10个积分的消费操作后，将消费操作发送给发放控制模块202，发放控制模块202基于该消费操作确定对应的消费价值为10个积分。与此同时，用户的终端设备显示可进行抽奖，假设用户获得的奖品是一张电子优惠券，终端设备将抽奖结果反馈给直播服务器，直播服务器基于抽奖结果生成物品发放请求并发送至发放控制模块202，发放控制模块202确定电子优惠券的价值，若电子优惠券的价值大于10个积分，则不进行发放操作，否则控制发放电子优惠券的物品发放模块203将电子优惠券发放给用户。在上述积分抽奖的场景中，若规定用户需要支付10个积分才可以抽奖，则在设置各个奖品的价值时，奖品的最高价值不应超过10个积分。

此外，参考图3，为了提高物品发放过程的安全性，目标对象进行针对任务A的消费操作时，业务控制模块201会将该消费操作的信息发送给发放控制模块202，发放控制模块202可基于消费操作确定消费操作的消费价值，并针对该消费操作生成一个令牌(token)，并将令牌和消费操作的价值关联存储，即通过这个令牌标识了此次消费操作的消费价值，然后将生成的令牌返回给业务控制模块201。业务控制模块201在将该目标对象针对任务A的物品发放请求发送给发放控制模块202时，会携带上述生成的令牌，发放控制模块202基于携带的令牌获得对应的价值，基于物品发放请求中的物品信息确定发放给目标对象的目标物品的价值，并判断发放给目标对象的目标物品的价值是否大于消费操作对应的消费价值，若是，则不进行发放操作，同时向用户发送发放失败的提示信息，否则控制对应的物品发放模块203将目标物品发放给目标对象。若业务控制模块201收到的物品发放请求未携带令牌，则不进行发放操作。

基于在发放控制模块202中配置的物品发放条件，对每个用户获得物品进行记录、监控和限制，实现对每个物品发放请求的实时监控，有效实现了对每一笔发放进行权限控制和额度控制，多维度的严控发放流程，防止出现多发物品或少发物品的情况，提高了物品发放的安全性和稳定性，防止薅羊毛等恶意事件的发生。

在一种可能的实施方式中，当发放控制模块202检测到某一任务对应的物品的剩余可发放数量为0时，可向主播发送物品余量不足的提示信息，主播可选择增加该物品的数量；若主播选择不增加物品，且只为该任务配置了一种可发放的物品，则发放控制模块202可将该任务标记为已结束任务。若为某一任务配置了多种可发放的物品，则当这多种物品的剩余可发放数量均为0，且主播不增加任何一种物品时，发放控制模块202可将该任务标记为已结束任务。

或者，当发放控制模块202检测到某一任务到达任务结束时间时，可将该任务标记为已结束任务。对于已结束任务，发放控制模块202会通知直播服务器，直播服务器会删除该已结束任务所对应的直播间内显示的任务窗口，即用户无法通过任务窗口参与该任务。

进一步地，发放控制模块202还会对目标对象的身份进行校验，若校验通过，则控制物品发放模块203进行发放操作，否则不进行发放操作，并通知目标对象物品发放失败。

具体地，发放控制模块202中可存储有各个对象参与任务的频率，当某一对象参与任务的频率高于预设的第一频率阈值时，可将该对象添加到黑名单中。发放控制模块202基于黑名单对目标对象的身份进行校验，如果目标对象在黑名单中，则校验不通过，不进行发放操作，如果目标对象不在黑名单中，则校验通过，进行发放操作。其中，黑名单中的对象是根据对象参与任务的频率动态变化的，当黑名单中的对象参与任务的频率下降到第二频率阈值时，可从黑名单中移除该对象，第二频率阈值不小于第一频率阈值。

具体地，发放控制模块202中还存储有各个用户的登录数据，登录数据包括用户的登录时间、常用登录地点、常用登录设备的设备标识、登录频率等，发放控制模块202确定目标对象对应的用户，进而从存储的登录数据中获取目标对象对应的登录数据，可基于目标对象当前的登录时间、登录地点、设备标识等信息，以及获取的登录数据，对目标对象的身份进行校验，例如，若当前的设备标识与常用登录设备的设备标识不同，则确定存在异常，若当前的登录地点与常用登录地点不同，则确定存在异常，对于存在异常的情况可通过预设的联系方式(如手机号、邮箱)通知到用户，以验证用户身份，在获得用户确认无异常后，再进行发放操作。

通过对目标对象的身份进行校验，可防止羊毛党或黑客的恶意攻击，进一步提高物品发放的安全性。

在上述任一实施方式的基础上，发放控制模块202还用于根据目标对象的历史操作数据，确定向目标对象发放物品的风险等级结果；如果风险等级低于风险阈值，则发放控制模块202控制对应的物品发放模块203将物品发放请求中的物品信息对应的目标物品发放给目标对象；如果风险等级不低于风险阈值，则发放控制模块202不进行针对该物品发放请求的发放操作。

其中，历史操作数据包括以下至少一种：历史消费数据、历史充值数据等。具体地，若历史消费数据的总价值低于发放给目标对象的目标物品的价值，则认为风险等级较高，否则认为风险等级较低；若历史充值数据的总价值低于发放给目标对象的目标物品的价值，则认为风险等级较高，否则认为风险等级较低。实际应用中，可以设置有风险和无风险两种风险等级，或者可以仅设置高和低两种风险等级，或者还可以设置更多级别的风险等级。

对于实时奖励机制，即需要即时将奖励发放给用户的情况，如抽奖，一位用户进行抽奖后需要立即将获得的物品发放给该用户，此时，发放控制模块202可根据该用户的历史操作数据确定向该用户发放物品的风险等级结果，如果风险等级低于风险阈值，发放控制模块202可控制对应的物品发放模块203将用户抽取的物品发放给该用户；如果风险等级不低于风险阈值，发放控制模块202不会将物品发放给该用户。

对于结算奖励机制，即在某一时机下(如任务结束后)统一将物品发放给多位用户的情况，如多人参与的游戏PK赛，需要在整个PK赛结束后统一向获胜的用户发放奖励物品，此时发放控制模块202会在任务结束后，确定获胜的用户以及获胜用户获得的奖励物品，并根据获胜用户的信息和获得的奖励物品的信息等数据生成发放审批单，将发放审批单发送给审批人员进行审批；审批通过后，发放控制模块202可控制对应的物品发放模块203将奖励物品发放给用户；如果审批未通过，发放控制模块202不会将奖励物品发放给用户。审批系统会存储发放审批单，保证奖励下发有据可查。进一步地，发放审批单中还可以包括发放控制模块202基于各个用户的历史操作数据确定出的风险等级结果、以及物品发放请求是否满足物品发放条件的判断结果，供审批人员参考。显示给审批人员的发放审批单的示例可参考图4。

在上述任一实施方式的基础上，当主播通过主播终端显示的任务设置入口完成具体任务的配置后，主播终端将主播配置的任务参数发送至直播服务器，直播服务器接收任务参数，生成本次任务对应的任务标识，每个任务对应一个任务标识，并将任务标识和对应的任务参数关联存储，同时将任务标识和任务参数同步到发放控制模块202。发放控制模块202获取任务标识和任务参数，生成任务对应的密钥，将任务标识、任务参数和密钥进行关联存储，并将该任务对应的密钥发送给业务控制模块201，发放控制模块202将任务标识、任务参数和密钥进行关联存储。

基于此，业务控制模块201还用于：根据物品发放请求中目标任务的任务标识，获得任务标识对应的密钥，基于该密钥生成数字签名，并将数字签名添加到物品发放请求中，即业务控制模块201发送的物品发放请求还包括基于目标任务对应的密钥生成的数字签名。

发放控制模块202还用于：基于目标任务对应的密钥，对物品发放请求中的数字签名进行验证；若确定物品发放请求中的数字签名通过验证，则控制对应的物品发放模块203将物品发放请求中的物品信息对应的目标物品发放给目标对象；若确定物品发放请求中的数字签名未通过验证，则将该物品发放请求标记为未通过请求。

具体实施时，发放控制模块202可将标记为未通过请求的物品发放请求反馈给直播服务器，由直播服务器通知对应的用户物品发放失败的消息。

由于每一个任务对应一个唯一的密钥，因此可基于密钥对各个任务对应的物品发放请求进行校验，而只有通过校验的物品发放请求才会被处理，即通过加密接口的方式，保证对接物品发放模块203的入口的收拢，以防止业务控制模块201绕过发放控制模块202私自发放物品，提高物品发放系统的安全性。

此外，发放控制模块202和物品发放模块203之间传输的数据也可以是加密数据，进一步地提高品发放系统的安全性。

具体实施时，业务控制模块201会对发送给发放控制模块202的物品发放请求进行存储，为了方便后续对账，每个任务对应一个应发流水记录，每个任务对应的物品发放请求存储到该任务对应的应发流水记录中，应发流水记录中的物品发放请求可按物品发放请求生成的先后顺序进行存储，方便数据查找。

具体实施时，业务控制模块201会对每个已处理的物品发放请求进行存储。了方便后续对账，每个任务对应一个请求处理记录，每个任务对应的请求处理记录中包括该任务对应的已处理的物品发放请求，已处理的物品发放请求包括通过核验的请求和未通过核验的请求。具体地，若发放控制模块202确定物品发放请求满足物品发放条件，并基于该物品发放请求控制物品发放模块203进行发放操作，则发放控制模块202会将该物品发放请求标记为已通过请求，并存储到任务对应的请求处理记录中；若发放控制模块202确定物品发放请求不满足物品发放条件，也未基于该物品发放请求控制物品发放模块203进行发放操作，则将该物品发放请求标记为未通过请求，并存储到任务对应的请求处理记录中。其中，请求处理记录中的物品发放请求可按物品发放请求生成的先后顺序进行存储，方便数据查找。

具体实施时，各个物品发放模块203在将物品发放请求中的物品信息对应的目标物品发放给目标对象后，会存储该物品发放请求对应的发放记录，该发放记录中至少包括任务标识、目标对象的对象标识、发放的物品以及数量、发放时间等信息，记录物品发放模块203已完成针对该物品发放请求的发放操作。为了方便后续对账，每个任务对应一个实发流水记录，每个任务对应的发放记录存储到该任务对应的实发流水记录中，即实发流水记录包括已向对象发放任务对应的物品的记录。针对未完成发放操作的情况，会将相关信息存储在发放异常清单中，方便后续核验，以解决系统异常问题。

基于此，发放控制模块202还用于：从业务控制模块201获取目标任务对应的应发流水记录，应发流水记录包括历史生成的目标任务对应的物品发放请求；基于发放控制模块202存储的目标任务对应的请求处理记录和应发流水记录，获得未处理的物品发放请求；基于未处理的物品发放请求，控制对应的物品发放模块203将未处理的物品发放请求中的物品信息对应的物品发放给目标对象。

具体地，发放控制模块202比对目标任务对应的请求处理记录和应发流水记录，找出包含在应发流水记录中但未包含在请求处理记录中的物品发放请求，即未处理的物品发放请求，然后对未处理的物品发放请求进行核验，确定是否可以进行发放操作；若确定可以进行发放操作，则基于未处理的物品发放请求中的物品，确定对应的物品发放模块203，并控制对应的物品发放模块203将物品发放请求中的物品信息对应的目标物品发放给目标对象，同时，将该物品发放请求标记为已通过请求，并存储到任务对应的请求处理记录中；若确定不可以进行发放操作，则将该未处理的物品发放请求标记为未通过请求，并存储到任务对应的请求处理记录中。具体核验的方法可参考之前提供的发放控制模块202的功能，不再赘述。

参考图6A，可通过发放控制模块202中的差异流水对账单元实现上述检测未处理请求并进行补发的功能。具体地，差异流水对账单元从业务控制模块201获取目标任务对应的应发流水记录，从存储单元204中获取的目标任务对应的请求处理记录，基于应发流水记录和请求处理记录，获得未处理的物品发放请求，将未处理的物品发放请求，发送给权限控制和额度控制单元；权限控制和额度控制单元对未处理的物品发放请求进行核验，核验的内容至少包括判断物品发放请求是否满足目标任务对应的物品发放条件；通过核验后，权限控制和额度控制单元通知发货组件处理该物品发放请求；发货组件控制对应的物品发放模块203将未处理的物品发放请求中的物品信息对应的物品发放给目标对象。

对于需要补发的未处理的物品发放请求，发放控制模块202可生成对应的发放审批单，并发送给审批人员进行审批，审批通过后进行发放，若审批未通过，则不进行发放。

基于应发流水记录和请求处理记录，可检测是否有遗漏的物品发放请求未处理，进而对这些未处理的物品发放请求进行处理，补发差异流水。

进一步地，发放控制模块202还用于：从业务控制模块201获取目标任务对应的应发流水记录，应发流水记录包括历史生成的目标任务对应的物品发放请求；基于各个物品发放模块203获取目标任务对应的实发流水记录，实发流水记录包括已向目标对象发放目标任务对应的物品的记录；基于发放控制模块存储的目标任务对应的请求处理记录、应发流水记录和实发流水记录，获得目标任务对应的物品发放对账单。

具体地，发放控制模块202可基于目标任务对应的请求处理记录、应发流水记录和实发流水记录，生成物品发放对账单，该物品发放对账单中包括每个物品发放请求对应的应发流水记录和实发流水记录，并可以统计应发的物品数量和实发的物品数量，以便进行物品数量核对，物品发放对账单中还可以包括收到物品的用户的信息，保证物品发放到真实用户手中。发放控制模块202还可以通过比对目标任务对应的请求处理记录、应发流水记录和实发流水记录，确定出存在异常的发放操作，如实际发放给目标对象的物品数量超过物品发放请求中的物品数量，并在物品发放对账单中标注出异常的发放操作。

参考图6A，可基于发放控制模块202提供的三方对账单元实现上述三方对账功能，通过对业务控制模块201、发放控制模块202以及物品发放模块203中的流水记录进行对账，对发放过程进行有效地监管，防止物品发放过程中出现恶意的贪腐舞弊现象，解决了奖励数据无对账，物品发放过程中风险不可控的问题，提高物品发放的安全性。

进一步地，参考图5A，发放控制模块202还包括互为备份的两个存储单元204，两个存储单元204用于存储目标任务对应的请求处理记录。即发放控制模块202采用了两个互为备份的存储单元204存储请求处理记录，以记录发放控制模块202已处理的物品发放请求，也即发放控制模块202已处理的每一条物品发放请求都会同时存入这两个存储单元204中。为此，只要一个存储单元204中存储有物品发放请求，则表明已经处理了该物品发放请求，且已经将相应的物品发放目标对象，可基于请求处理记录，对物品发放过程进行监控和限制，防止出现重复发放、用户多次领取奖励等情况。此外，通过互为备份的两个存储单元204存储发放控制模块202的数据，可降低因存储单元204故障导致数据丢失的概率，提高系统可靠性。互为备份的两个存储单元204还可以用于存储发放控制模块202中的其他数据，如任务参数等。

其中，发放控制模块202中的存储单元204可以是Redis主机，发放控制模块202采用了两个互为备份的Redis主机存储请求处理记录，以记录发放控制模块202已处理的物品发放请求，即发放控制模块202已处理的每一条物品发放请求都会同时存入这两个Redis主机中。

在上述任一实施方式的基础上，参考图5A，业务控制模块201和发放控制模块202之间包括消息中间件205，其中，消息中间件205用于接收业务控制模块发送的物品发放请求，并将物品发送请求发送给发放控制模块。

基于消息中间件205，将业务控制模块201和发放控制模块202解耦，避免消息阻塞，在保证物品发放请求不丢失的同时，还可以有效应对大量突发请求，起到削峰限速的作用。

在上述任一实施方式的基础上，参考图5A，每个物品发放模块203对应至少两个发放处理单元。相应地，发放控制模块202还用于：周期性获取各个物品发放模块203对应的发放处理单元的心跳信息，心跳信息包括发放处理单元的运行情况；然后，根据物品发放模块203的每个发放处理单元的运行情况，筛选出目标发放处理单元，并控制目标发放处理单元将物品发放请求中的物品信息对应的目标物品发放给目标对象。

以图5B为例，业务控制模块201将生成的多个活动奖励信息(即物品发放请求)发送给Hippo消息队列(即消息中间件)，Hippo消息队列将活动奖励信息逐个发送给发放控制模块202，由发放控制模块202根据收到的活动奖励信息执行具体的发货服务，即控制活动奖励信息对应的物品发放模块将奖励物品发放给目标对象，每一种物品发放模块用于发放一种物品，例如图5B中的座驾模块用于将虚拟道具座驾发送给目标对象，勋章模块用于将勋章发送给目标对象，礼物模块用于将礼物发送给目标对象，铭牌模块用于将铭牌发送给目标对象。发放控制模块202可通过两个互为备份的Redis主机存储针对活动奖励信息的处理记录，以记录发放控制模块202已处理的活动奖励信息，即发放控制模块202已处理的每一条活动奖励信息都会同时存入这两个Redis主机中，实现了双写发货标记。发放控制模块202周期性获取各个物品发放模块对应的发放处理单元的心跳信息，根据物品发放模块203的每个发放处理单元的运行情况，筛选出目标发放处理单元，并控制目标发放处理单元将奖励物品发放给目标对象，实现分布式频率限速，当某一发放处理单元存在故障时,可以提高其他发放处理单元的发放速度。

参考图6A，发放控制模块202中的分布限流单元用于执行上述功能，分布限流单元周期性获取各个物品发放模块203对应的发放处理单元的心跳信息，心跳信息包括发放处理单元的运行情况，根据物品发放模块203的每个发放处理单元的运行情况，筛选出目标发放处理单元，并通知发货组件，由发货组件控制目标发放处理单元将物品发放请求中的物品信息对应的目标物品发放给目标对象。

为此，发放控制模块202可实时获取到物品发放模块203中的各个发放处理单元的运行状态，从中选出运行状态最好、负载最小、处理效率最高的发放处理单元，来处理本次物品发放操作，从而将大量的物品发放请求平均分摊到多个发放处理单元中进行处理，当物品发放模块203中的一个发放处理单元出现故障时，可以将物品发放请求分发到该物品发放模块203中的其他发放处理单元。通过分布限流的方式，对物品发放模块203进行限速保护，防止后端过载，保证发放过程的稳定进行。

示例性地，参考图6B，业务控制模块201中包括实时奖励机制和结算奖励机制，业务控制模块201可通过Hippo消息队列，将实时奖励机制和结算奖励机制产生的物品发放请求发送给发放控制模块202，同时业务控制模块201记录发送的物品发放请求以生成应发流水记录。发放控制模块202对业务控制模块201产生的物品发放请求进行统一发货处理，具体地，发放控制模块202可基于预设策略对物品发放请求进行安全检查，该功能对应图6A中的权限控制和额度控制单元，例如：基于物品发放请求中的物品信息、目标对象以及对应的物品发放条件，判断是否向目标对象发放物品，若确定发放，则通知发货组件处理该物品发放请求，发货组件可调用对应的物品发放模块203提供的物品发放接口，以将相应的物品发放给目标对象，发货组件和物品发放接口之间采用加密方式进行通信，保证数据安全。在存储方面，发放控制模块202可通过两个互为备份的Redis主机存储针对活动奖励信息的处理记录，以记录发放控制模块202已处理的活动奖励信息，即发放控制模块202已处理的每一条活动奖励信息都会同时存入这两个Redis主机中，实现了双写发货标记，同时，还可以将发放过程中存在异常的物品发放请求存入异常流水中，如未通过校验的物品发放请求。图6B中的对账功能可参考图6A中的差异流水对账单元，以检测出未处理请求并进行补发。图6B中的三方对账功能可参考图6A中的三方对账单元，基于应发流水记录、实发流水记录以及Redis主机中存储的流水记录进行三方对账，实现严格审计，对发放过程进行有效地监管。图6B中的速率控制功能可参考图6A中的分布限流单元，通过分布限流的方式，对物品发放模块203进行限速保护，防止后端过载，保证发放过程的稳定进行。图6B中的敏感系统可参考图6A中的审批系统，对于需要审批的物品发放请求，如需要补发的未处理的物品发放请求、异常的物品发放请求等，可生成对应的发放审批单，并发送给审批人员进行审批，审批通过后进行发放，若审批未通过，则不进行发放。

在上述任一实施方式的基础上，本申请实施例提供的直播中发放物品的控制系统还包括数据存储模块，数据存储模块包括多种类型的数据库，每个类型的数据库用于存储不同价值的物品数据。其中，物品数据可包括各个任务对应的物品种类以及物品数量等数据。

具体实施时，主播完成任务的申请后，发放控制模块202可根据任务参数中的物品总数和物品信息，从主播提供对应的账户中扣除相应数量的物品，并暂存到数据存储模块中，数据存储模块中各个任务对应的物品总数和物品信息分开存储，可基于任务标识进行区分，方便后续基于任务标识从数据存储模块中获取相应的物品发放给用户。

例如，价值相对较高的物品可存储在稳定性、安全性较高的TDSQL(TitanDistribute SQL，分布式数据库)中，价值相对较低的物品可存储在稳定性、安全性相对较低但成本也相对较低的Redis。一件物品是否具有价值，需要结合实际应用场景确定，此处不作限定。

具体实施时，数据存储模块还可以用于存储并管理各个用户的信息，如身份信息、积分信息等。具体地，可以选择MIDAS数据库存储用户的信息。

参考图3，发放控制模块202会将数据进行加密后再存储到数据存储模块中对应类型的数据库中，以保证数据存储的安全性，不同类型的数据库可采用相同或不同的加密方式。例如，发放控制模块202会对价值相对较高的物品的物品总数、物品信息等信息进行加密，再将加密后的信息存储到TDSQL中；发放控制模块202会对价值相对较低的物品的物品总数、物品信息等信息进行加密，再将加密后的信息存储到Redis中；发放控制模块202会对用户的信息进行加密，再将加密后的信息存储到MIDAS中。

根据数据的重要程度，采用不同类型的数据库存储不同的数据，在提供数据安全性的前提下，减低了存储成本。进一步地，数据存储模块还可以对存储的数据进行加密，防止信息泄露。此外，针对物品多样的问题，数据存储模块可对接物品管理平台，通过物品管理平台对物品数据进行管理，防止物品被错发的情况。

如图7所示，基于与上述直播中发放物品的控制系统相同的发明构思，本申请实施例还提供了一种直播中发放物品的控制方法，应用于发放控制模块202，具体包括如下步骤：

S701、接收物品发放请求，其中，物品发放请求是根据直播过程中针对目标任务的任务完成消息生成的，物品发放请求包括发放给目标对象的物品信息。

其中，物品发放请求是由业务控制模块201根据接收到的任务完成消息生成的，具体参考业务控制模块201的功能，不再赘述。

S702、若确定物品发放请求满足目标任务对应的物品发放条件，则控制对应的物品发放模块将物品发放请求中的物品信息对应的目标物品发放给目标对象。

本申请实施例提供的直播中发放物品的控制方法，将发放控制模块作为业务控制模块对接各个物品发放模块203的唯一入口，并基于发放控制模块中配置的物品发放条件，对发放控制模块接收到的物品发放请求进行校验，仅执行满足物品发放条件的物品发放请求，并控制对应的物品发放模块203完成物品发放，使得物品发放模块203不会被随意调用，保证物品发放时的安全性和稳定性。

具体实施时，物品发放条件包括以下至少一种：

(1)已向目标对象发放过目标物品的次数不大于目标任务对应的限定次数；

(2)发放给目标对象的目标物品的数量不大于目标任务对应的目标物品的剩余可发放数量，其中，剩余可发放数量为分配给目标任务的目标物品的总数和已发放的目标物品的数量之差；

(3)发放给目标对象的目标物品的数量不大于目标任务对应的单次发放最大数量；

(4)发放给目标对象的目标物品的价值不大于物品发放请求对应的消费价值，物品发放请求对应的消费价值是基于目标对象在完成目标任务过程中的消费操作确定的。

基于在发放控制模块202中配置的物品发放条件，对每个用户获得物品进行记录、监控和限制，实现对每个物品发放请求的实时监控，有效实现了对每一笔发放进行权限控制和额度控制，多维度的严控发放流程，防止出现多发物品或少发物品的情况，提高了物品发放的安全性和稳定性，防止薅羊毛等恶意事件的发生。

在一种可能的实施方式中，物品发放请求还包括基于目标任务对应的密钥生成的数字签名。

基于此，在执行步骤S702之前，本申请实施例的直播中发放物品的控制方法还包括如下步骤：基于目标任务对应的密钥对物品发放请求中的数字签名进行验证；若确定物品发放请求中的数字签名通过验证，则执行步骤S702，否则不执行步骤S702。

在一种可能的实施方式中，参考图8，本申请实施例的直播中发放物品的控制方法还包括如下步骤：

S801、从业务控制模块获取目标任务对应的应发流水记录，应发流水记录包括历史生成的目标任务对应的物品发放请求；

S802、基于发放控制模块存储的目标任务对应的请求处理记录和应发流水记录，获得未处理的物品发放请求，其中，请求处理记录中包括目标任务对应的已处理的物品发放请求；

S803、基于未处理的物品发放请求，控制对应的物品发放模块将未处理的物品发放请求中的物品信息对应的物品发放给目标对象。

对于需要补发的未处理的物品发放请求，发放控制模块202还可以生成对应的发放审批单，并发送给审批人员进行审批，审批通过后执行步骤S803，并将该未处理的物品发放请求标记为已通过请求；若审批未通过，则不执行步骤S803，即不进行发放，并将该未处理的物品发放请求标记为未通过请求。

基于图8提供的差异流水检测及补发方法，可检测是否有遗漏的物品发放请求未处理，进而对这些未处理的物品发放请求进行处理，补发差异流水。

在一种可能的实施方式中，参考图9，本申请实施例的直播中发放物品的控制方法还包括如下步骤：

S901、从业务控制模块获取目标任务对应的应发流水记录，应发流水记录包括历史生成的目标任务对应的物品发放请求；

S902、基于各个物品发放模块获取目标任务对应的实发流水记录，实发流水记录包括已向目标对象发放目标任务对应的物品的记录；

S903、基于发放控制模块存储的目标任务对应的请求处理记录、应发流水记录和实发流水记录，获得目标任务对应的物品发放对账单，其中，请求处理记录中包括目标任务对应的已处理的物品发放请求。

其中，物品发放对账单中可包括每个物品发放请求对应的应发流水记录和实发流水记录，并可以统计应发的物品数量和实发的物品数量，以便进行物品数量核对，物品发放对账单中还可以包括收到物品的用户的信息，保证物品发放到真实用户手中。还可以通过比对目标任务对应的请求处理记录、应发流水记录和实发流水记录，确定出存在异常的发放操作，如实际发放给目标对象的物品数量超过物品发放请求中的物品数量，并在物品发放对账单中标注出异常的发放操作。

通过对业务控制模块201、发放控制模块202以及物品发放模块203中的流水记录进行三方对账，对发放过程进行有效地监管，防止物品发放过程中出现恶意的贪腐舞弊现象，解决了奖励数据无对账，物品发放过程中风险不可控的问题，提高物品发放的安全性。

在一种可能的实施方式中，每个物品发放模块对应至少两个发放处理单元。

为此，本申请实施例的直播中发放物品的控制方法还包括如下步骤：周期性获取各个物品发放模块对应的发放处理单元的心跳信息，心跳信息包括发放处理单元的运行情况。

相应地，步骤S702具体包括：根据对应的物品发放模块的每个发放处理单元的运行情况，筛选出目标发放处理单元，并控制目标发放处理单元将物品发放请求中的物品信息对应的目标物品发放给目标对象。

基于此，发放控制模块202可实时获取到物品发放模块203中的各个发放处理单元的运行状态，从中选出运行状态最好、负载最小、处理效率最高的发放处理单元，来处理本次物品发放操作，从而将大量的物品发放请求平均分摊到多个发放处理单元中进行处理，当物品发放模块203中的一个发放处理单元出现故障时，可以将物品发放请求分发到该物品发放模块203中的其他发放处理单元。通过分布限流的方式，对物品发放模块203进行限速保护，防止后端过载，保证发放过程的稳定进行。

在一种可能的实施方式中，本申请实施例的直播中发放物品的控制方法还包括如下步骤：根据目标对象的历史操作数据，确定向目标对象发放物品的风险等级结果。其中，历史操作数据包括以下至少一种：历史消费数据、历史充值数据等。具体地，若历史消费数据的总价值低于发放给目标对象的目标物品的价值，则认为风险等级较高，否则认为风险等级较低；若历史充值数据的总价值低于发放给目标对象的目标物品的价值，则认为风险等级较高，否则认为风险等级较低。

为此，在执行步骤S702之前，本申请实施例的直播中发放物品的控制方法还包括如下步骤：基于风险等级结果，判断是否需要向目标对象发放物品；若确定需要向目标对象发放物品，则执行步骤S702，否则不执行步骤S702。

本申请实施例提的直播中发放物品的控制方法与上述直播中发放物品的控制系统采用了相同的发明构思，能够取得相同的有益效果，在此不再赘述。

基于与上述直播中发放物品的控制方法相同的发明构思，本申请实施例还提供了一种电子设备，该电子设备可以是一台服务器或多台服务器。如图10所示，该电子设备100可以包括处理器1001和存储器1002。

处理器1001可以是通用处理器，例如中央处理器(CPU)、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器1002作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random Access Memory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器1002还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；上述计算机存储介质可以是计算机能够存取的任何可用介质或数据存储设备，包括但不限于：移动存储设备、随机存取存储器(RAM，Random Access Memory)、磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、随机存取存储器(RAM，Random Access Memory)、磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等各种可以存储程序代码的介质。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的直播中发放物品的控制方法。

以上实施例仅用以对本申请的技术方案进行了详细介绍，但以上实施例的说明只是用于帮助理解本申请实施例的方法，不应理解为对本申请实施例的限制。本技术领域的技术人员可轻易想到的变化或替换，都应涵盖在本申请实施例的保护范围之内。

Claims (15)

1.一种直播中发放物品的控制系统，其特征在于，包括：业务控制模块和发放控制模块；

所述业务控制模块，用于根据直播过程中针对目标任务的任务完成消息，生成物品发放请求，所述物品发放请求包括发放给目标对象的物品信息；

所述发放控制模块，用于若确定所述物品发放请求满足所述目标任务对应的物品发放条件，则控制对应的物品发放模块将所述物品发放请求中的物品信息对应的目标物品发放给所述目标对象。

2.根据权利要求1所述的系统，其特征在于，所述物品发放条件包括以下至少一种：

已向所述目标对象发放过所述目标物品的次数不大于所述目标任务对应的限定次数；

发放给所述目标对象的所述目标物品的数量不大于所述目标任务对应的所述目标物品的剩余可发放数量，其中，所述剩余可发放数量为分配给所述目标任务的所述目标物品的总数和已发放的所述目标物品的数量之差；

发放给所述目标对象的所述目标物品的数量不大于所述目标任务对应的单次发放最大数量；以及

发放给所述目标对象的所述目标物品的价值不大于所述物品发放请求对应的消费价值，所述物品发放请求对应的消费价值是基于所述目标对象在完成所述目标任务过程中的消费操作确定的。

3.根据权利要求1所述的系统，其特征在于，所述物品发放请求还包括基于所述目标任务对应的密钥生成的数字签名；

所述发放控制模块，还用于在控制对应的物品发放模块将所述物品发放请求中的物品信息对应的目标物品发放给所述目标对象之前，基于所述目标任务对应的密钥确定所述物品发放请求中的数字签名通过验证。

4.根据权利要求1所述的系统，其特征在于，所述发放控制模块，还用于：

从所述业务控制模块获取所述目标任务对应的应发流水记录，所述应发流水记录包括历史生成的所述目标任务对应的物品发放请求；

基于所述发放控制模块存储的所述目标任务对应的请求处理记录和所述应发流水记录，获得未处理的物品发放请求，其中，所述请求处理记录中包括所述目标任务对应的已处理的物品发放请求；

基于所述未处理的物品发放请求，控制对应的物品发放模块将所述未处理的物品发放请求中的物品信息对应的物品发放给所述目标对象。

5.根据权利要求1所述的系统，其特征在于，所述发放控制模块，还用于：

从所述业务控制模块获取所述目标任务对应的应发流水记录，所述应发流水记录包括历史生成的所述目标任务对应的物品发放请求；

基于各个物品发放模块获取所述目标任务对应的实发流水记录，所述实发流水记录包括已向目标对象发放所述目标任务对应的物品的记录；

基于所述发放控制模块存储的所述目标任务对应的请求处理记录、所述应发流水记录和所述实发流水记录，获得所述目标任务对应的物品发放对账单，其中，所述请求处理记录中包括所述目标任务对应的已处理的物品发放请求。

6.根据权利要求4或5所述的系统，其特征在于，所述发放控制模块包括互为备份的两个存储单元，所述两个存储单元用于存储所述目标任务对应的请求处理记录。

7.根据权利要求1至5任一项所述的系统，其特征在于，每个物品发放模块对应至少两个发放处理单元；

所述发放控制模块，还用于周期性获取各个物品发放模块对应的发放处理单元的心跳信息，所述心跳信息包括发放处理单元的运行情况；

所述发放控制模块，具体用于根据对应的物品发放模块的每个发放处理单元的运行情况，筛选出目标发放处理单元，并控制所述目标发放处理单元将所述物品发放请求中的物品信息对应的目标物品发放给所述目标对象。

8.根据权利要求1至5任一项所述的系统，其特征在于，所述业务控制模块和所述发放控制模块之间包括消息中间件；

所述消息中间件，用于接收所述业务控制模块发送的所述物品发放请求，并将所述物品发送请求发送给所述发放控制模块。

9.根据权利要求1至5任一项所述的系统，其特征在于，

所述发放控制模块，还用于根据所述目标对象的历史操作数据，确定向所述目标对象发放物品的风险等级结果；在控制对应的物品发放模块将所述物品发放请求中的物品信息对应的目标物品发放给所述目标对象之前，基于所述风险等级结果确定向所述目标对象发放物品。

10.根据权利要求1至5任一项所述的系统，其特征在于，所述系统还包括数据存储模块，所述数据存储模块包括多种类型的数据库，每个类型的数据库用于存储不同价值的物品数据。

11.一种物品发放控制方法，其特征在于，包括：

接收物品发放请求，其中，所述物品发放请求是根据直播过程中针对目标任务的任务完成消息生成的，所述物品发放请求包括发放给目标对象的物品信息；

若确定所述物品发放请求满足所述目标任务对应的物品发放条件，则控制对应的物品发放模块将所述物品发放请求中的物品信息对应的目标物品发放给所述目标对象。

12.根据权利要求11所述的方法，其特征在于，所述物品发放条件包括以下至少一种：

已向所述目标对象发放过所述目标物品的次数不大于所述目标任务对应的限定次数；

发放给所述目标对象的所述目标物品的数量不大于所述目标任务对应的所述目标物品的剩余可发放数量，其中，所述剩余可发放数量为分配给所述目标任务的所述目标物品的总数和已发放的所述目标物品的数量之差；

发放给所述目标对象的所述目标物品的数量不大于所述目标任务对应的单次发放最大数量；以及

发放给所述目标对象的所述目标物品的价值不大于所述物品发放请求对应的消费价值，所述物品发放请求对应的消费价值是基于所述目标对象在完成所述目标任务过程中的消费操作确定的。

13.根据权利要求11所述的方法，其特征在于，所述物品发放请求还包括基于所述目标任务对应的密钥生成的数字签名；

所述控制对应的物品发放模块将所述物品发放请求中的物品信息对应的目标物品发放给所述目标对象之前，所述方法还包括：

基于所述目标任务对应的密钥确定所述物品发放请求中的数字签名通过验证。

14.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求11至13任一项所述方法的步骤。

15.一种计算机可读存储介质，其上存储有计算机程序指令，其特征在于，该计算机程序指令被处理器执行时实现权利要求11至13任一项所述方法的步骤。

Images