发放资源的方法、装置、系统、存储介质和计算机设备与流程

本申请为申请号201810265099.6，申请日2018年03月28日、发明名称“发放资源的方法、装置、系统、存储介质和计算机设备”的分案申请。

本发明涉及计算机技术领域，具体而言，本发明涉及一种发放资源的方法、装置、系统、存储介质和计算机设备。

背景技术：

发放资源是一种很好的互动娱乐形式。发放资源的方式有很多，以抽奖为例，定期合法的以一些虚拟或者实体礼物激励用户会让用户之间增加亲密度，例如点歌机会、赠送周边礼品等。因此，为了满足直播中用户的互动需要，需要提供一种在直播中发放资源的方案。

技术实现要素：

本发明针对现有方式的缺点，提出一种发放资源的方法、装置、系统、存储介质和计算机设备，用以解决现有技术中由于缺乏直播中发放资源的方案而导致的无法满足直播中用户的互动需要的问题，以提供一种直播中资源发放方案，更好满足直播中用户的互动需要。

本发明的实施例根据第一个方面，提供了一种发放资源的方法，包括步骤：

第一客户端向目标服务端发送直播间中参与资源发放活动的第一用户输入的资源发放请求；

目标服务端根据资源发放请求为第一用户分配竞猜信息，若竞猜信息与预先存储的资源发放活动的配置信息包含的竞猜答案匹配，则获取配置信息包含的资源总数量和资源发放持续时间，根据资源总数量和资源发放持续时间得到资源发放时间间隔；

通过资源发放时间间隔确定资源发放请求的接收时间是否达到发放资源的时间段内；

若达到发放资源的时间段内，则向第一用户发放资源；其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

本发明的实施例根据第二个方面，还提供了另一种发放资源的方法，包括步骤：

接收直播间中参与资源发放活动的第一用户输入的资源发放请求；

根据资源发放请求为第一用户分配竞猜信息，若竞猜信息与预先存储的资源发放活动的配置信息包含的竞猜答案匹配，则获取配置信息包含的资源总数量和资源发放持续时间，根据资源总数量和资源发放持续时间得到资源发放时间间隔；

通过资源发放时间间隔确定资源发放请求的接收时间是否达到发放资源的时间段内；

若达到发放资源的时间段内，则向第一用户发放资源；其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

本发明的实施例根据第三个方面，还提供了一种发放资源的系统，包括：

第一客户端，用于向目标服务端发送直播间中参与资源发放活动的第一用户输入的资源发放请求；

目标服务端，用于根据资源发放请求为第一用户分配竞猜信息，若竞猜信息与预先存储的资源发放活动的配置信息包含的竞猜答案匹配，则获取配置信息包含的资源总数量和资源发放持续时间，根据资源总数量和资源发放持续时间得到资源发放时间间隔，通过资源发放时间间隔确定资源发放请求的接收时间是否达到发放资源的时间段内；若达到发放资源的时间段内，则向第一用户发放资源；其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

本发明的实施例根据第四个方面，还提供了一种发放资源的装置，包括：

资源发放请求接收模块，用于接收直播间中参与资源发放活动的第一用户输入的资源发放请求；

竞猜信息分配模块，用于根据资源发放请求为第一用户分配竞猜信息；

资源发放模块，用于若竞猜信息与预先存储的资源发放活动的配置信息包含的竞猜答案匹配，则获取配置信息包含的资源总数量和资源发放持续时间，根据资源总数量和资源发放持续时间得到资源发放时间间隔，通过资源发放时间间隔确定资源发放请求的接收时间是否达到发放资源的时间段内；若达到发放资源的时间段内，则向第一用户发放资源；其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

本发明的实施例根据第五个方面，还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任意一项的发放资源的方法。

本实施例将竞猜信息和预先存储的竞猜答案进行匹配，在匹配时向发送资源发放请求的用户发放资源，从而在直播间中实现了资源发放，更好满足直播中用户的互动需要。

本发明的实施例根据第六个方面，还提供了一种计算机设备，计算机设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现上述任意一项的发放资源的方法。

上述实施例提供的发放资源的方法、装置、系统、存储介质和计算机设备，实现了在进行资源发放时不仅考虑竞猜信息和竞猜答案之间的关系，还结合资源总数量以及资源发放持续时间，以综合判断是否向请求用户发放资源，从而有效避免了由于竞猜信息和竞猜答案匹配即发放资源而可能导致的资源发放活动刚开始所有资源均已被抽中或者资源发放活动开始较长时间资源一直未被抽中的问题，实现了资源的均匀发放，灵活性较好，能够很好的支持资源发放活动开展，满足直播中用户的互动需要。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1a为本发明一个实施例的发放资源的方法的流程示意图；

图1b为本发明另一个实施例的发放资源的方法的流程示意图；

图2为本发明一个实施例的发放资源的系统的结构示意图；

图3为本发明一个具体实施例的抽奖系统的结构示意图；

图4为本发明另一个实施例的发放资源的方法的流程示意图；

图5为本发明另一个实施例的发放资源的系统的结构示意图；

图6a为本发明另一个实施例的发放资源的方法的流程示意图；

图6b为本发明另一个实施例的发放资源的方法的流程示意图；

图7为本发明一个实施例的发放资源的装置的结构示意图；

图8为本发明另一个实施例的发放资源的方法的流程示意图；

图9为本发明另一个实施例的发放资源的装置的结构示意图；

图10为本发明一个实施例的计算机设备的结构示意图。

具体实施方式

下面详细描述本发明的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的“客户端”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，执行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；pcs(personalcommunicationsservice，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；pda(personaldigitalassistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或gps(globalpositioningsystem，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“客户端”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“客户端”还可以是通信终端、上网终端、音乐/视频播放终端，例如可以是pda、mid(mobileinternetdevice，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。

本技术领域技术人员可以理解，这里所使用的服务端包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云。在此，云由基于云计算(cloudcomputing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。本发明的实施例中，远端网络设备、终端设备与服务端之间可通过任何通信方式实现通信，包括但不限于，基于3gpp、lte、wimax的移动通信、基于tcp/ip、udp协议的计算机网络通信以及基于蓝牙、红外传输标准的近距无线传输方式。

首先从整个系统的角度，结合附图对本发明的具体实施方式进行详细介绍。

如图1a所示，在一个实施例中，一种发放资源的方法，包括步骤：

s101a、第一客户端向目标服务端发送直播间中参与资源发放活动的第一用户输入的资源发放请求。

s102a、目标服务端根据资源发放请求为第一用户分配竞猜信息，若竞猜信息与预先存储的资源发放活动的配置信息包含的竞猜答案匹配，则获取配置信息包含的资源总数量和资源发放持续时间，根据资源总数量和资源发放持续时间得到资源发放时间间隔；其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

s103a、通过资源发放时间间隔确定资源发放请求的接收时间是否达到发放资源的时间段内。

s104a、若达到发放资源的时间段内，则向第一用户发放资源。

如图1b所示，在一个实施例中，一种发放资源的方法，包括步骤：

s110、第一客户端向目标服务端发送直播间中参与资源发放活动的第一用户输入的资源发放请求。

第一客户端是第一用户所用的客户端。直播间也可以称为直播的频道，是主播开播的绑定虚拟房间，通常每个直播间都有唯一id(identification，身份标识号)。以yy直播间为例，直播间有顶级频道，记为topcid，可能对应多个子频道，记为subcid。单个直播间人数可高达百万级。资源包括虚拟或者实体礼物等等。资源发放活动是关于将资源发放给请求用户的活动，例如抽奖活动等。

进入直播间的用户一般均可以参与该直播间举办的资源发放活动。当直播间中的用户参与该资源发放活动时，客户端即会向目标服务端发送资源发放请求，请求为该用户发放资源。

s120、目标服务端根据资源发放请求为第一用户分配竞猜信息，若随机数与预先存储的资源发放活动的配置信息包含的竞猜答案匹配，向第一用户发放资源。

接收到资源发放请求后，即会根据该资源发放请求为用户分配竞猜信息。竞猜信息用于确定是否可以向用户发放资源，具体形式与资源发放活动的类型有关，例如，资源发放活动用于猜一个数字，则竞猜信息即为给用户分配的数字。资源发放活动的配置信息是进行资源发放活动的保障。竞猜答案可以根据实际需要进行设置，例如竞猜答案为某一类型的物品、某一个数字、某一个物品、某一个颜色或者某一个名字等等，以抽奖为例，中奖点数即为竞猜答案，例如，中奖点数为8。

为第一用户分配竞猜信息后，将该竞猜信息与预先存储的竞猜答案匹配。如果两者匹配，则确定向第一用户发放资源。如果两者不匹配，则不向第一用户发放资源。

为了保证资源发放活动的公平性，可选的，在资源发放活动中采用随机数机制。因此，在一个实施例中，竞猜信息为随机数，竞猜答案为中奖点数；若竞猜信息与预先存储的资源发放活动的配置信息包含的竞猜答案匹配，向第一用户发放资源，包括：

若随机数与预先存储的资源发放活动的配置信息包含的中奖点数匹配，向第一用户发放资源。

当目标服务端接收到第一用户的资源发放请求时，为该第一用户随机生成随机数，判断该随机数是否与中奖点数匹配，从而判断是否能为该第一用户分配资源，避免了造假情况的出现。可选的，采用梅森旋转算法(mersennetwister)生成随机数。应当理解，本发明并不对随机数的生成算法进行限定，用户还可以根据实际需要采用其它算法生成随机数。

本实施例为发送资源发放请求的用户分配竞猜信息，然后将该竞猜信息和预先存储的竞猜答案进行匹配，在匹配时向发送资源发放请求的用户发放资源，从而在直播间中实现了资源发放，更好满足直播中用户的互动需要。

如果仅根据竞猜信息和竞猜答案匹配即发放资源，当用户群足够大的时候，只是竞猜信息和竞猜答案对应是非常容易的，很有可能导致资源发放活动刚开始所有资源均已被抽中或者资源发放活动开始较长时间资源一直未被抽中的问题，降低用户参与资源发放活动的积极性，不能很好满足直播中用户的互动需求。因此为了能很好的支持资源发放活动开展，增加互动，还需要根据资源发放请求的接收时间和配置信息进一步判定是否能够向第一用户发放资源，实现资源的均匀发放。

可选的，配置信息还包含资源总数量、资源发放开始时间以及资源发放持续时间等。资源总数量为配置的发放资源的总数目。资源发放开始时间为设置的开始能够发放资源的时间，例如，资源发放开始时间设置为在开始后第10分钟投放资源，那么在资源发放活动前10分钟不会进行资源发放，从第10分钟开始进行资源发放。资源发放持续时间指的是从资源发放开始时间起所持续的时间，例如，资源发放持续时间设置为20分钟内投放完毕，那么从资源发放开始时间起20分钟内需要把所有资源投放完毕。后续会对配置信息进行详细介绍。

在一个实施例中，目标服务端向第一用户发放资源，包括：

s1201、目标服务端判断记录的资源发放请求的接收时间是否晚于资源发放开始时间。

接收时间可以是接收到资源发放请求时的实际系统时间，那么同样的资源发放开始时间指的也是实际系统时间。接收时间还可以是距离资源发放活动开始的时间差，那么同样的资源发放开始时间指的也是距离资源发放活动开始的时间差。另外，本发明考虑到客户端生成资源发放请求到目标服务端接收到该资源发放请求的时间很短，因此选择了资源发放请求的接收时间，应当理解，本发明实施例还可以采用资源发放请求的生成时间等等，只要可以表征第一用户参与资源发放活动的时间即可。

s1202、若接收时间晚于资源发放开始时间，目标服务端计算接收时间和资源发放开始时间的第一时间差值。

若接收时间比资源发放开始时间晚，计算第一时间差值，第一时间差值等于接收时间减去资源发放开始时间。

在一个实施例中，目标服务端判断记录的资源发放请求的接收时间是否晚于资源发放开始时间之后，还包括：

若接收时间早于或等于资源发放开始时间，目标服务端禁止向第一用户发放资源。

如果接收时间早于或等于资源发放开始时间，即使竞猜信息与竞猜答案匹配，由于还未到设置的能够投放资源的时间，也不向第一用户发放资源。以抽奖为例，则在该种情况下第一用户未中奖。

s1203、若第一时间差值与整数倍的资源发放时间间隔之间的差值小于预设阈值，目标服务端向第一用户发放资源，其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

预设阈值可以根据实际需要进行设置，为了保证判断的准确性，预设阈值宜设置一个较小的值。资源发放时间间隔用于确定是否到达能够发放资源的时间段内。如果竞猜信息与竞猜答案匹配，且第一用户参加资源发放活动的时间(即接收时间)到达能够发放资源的时间段内，则为第一用户发放资源，具体发放资源的类型和数量包含在配置信息中。

在一个实施例中，目标服务端计算接收时间和资源发放开始时间的第一时间差值之后，还包括：

若第一时间差值大于等于预设阈值，目标服务端禁止向第一用户发放资源。

如果竞猜信息与竞猜答案匹配，但是第一用户参加资源发放活动的时间还未到达能够发放资源的时间段内，则不向该第一用户发放资源。

在另一个实施例中，还可以获取本次资源发放活动中的历史资源发放记录，该历史资源发放记录记录有用户成功获取资源的时间点以及资源的类型等。在竞猜信息与竞猜答案匹配时，目标服务端判断接收时间是否晚于资源发放开始时间。若否，目标服务端禁止向第一用户发放资源。若是，目标服务端若根据历史资源发放记录确定还未向任何用户发放过资源，则计算接收时间和资源发放开始时间的第二时间差值，如果第二时间差值在资源发放时间间隔附近，则向第一用户发放资源，否则不向第一用户发放资源；目标服务端若根据历史资源发放记录确定已向某些用户发放过资源，则获取最近一次发放资源的时间，计算接收时间和最近一次发放资源时间的第三时间差值，如果第三时间差值在资源发放时间间隔附近，则向第一用户发放资源，否则不向第一用户发放资源。

通过上述实施例可以看出，除非用户(管理员)配置了某场资源发放活动某个资源开场多久后才有机会被抽中，否则资源的发放概率是“均匀”贯穿整个资源发放活动的，即各个资源的发放概率从一开始到最终的活动结束都是“均衡”的，不会出现资源一下子发放完毕的情况。

为了更好的理解上述资源发放逻辑，下面结合在直播间中抽奖的两个具体实例进行说明。

第一个具体实例：

在一个抽奖活动的配置信息中，设置了奖品1的活动信息：“玩具熊”数量(资源总数量)10个，中奖点数(竞猜答案)是8，开始后第1分钟投放奖品(资源发放开始时间)、30分钟内投放完毕(资源发放持续时间)。

基于上述配置信息，本实施例采用的资源发放逻辑就会把10个玩具熊的中奖情况较均匀的控制在30分钟内，也就是说，一般而言平均3分钟(资源发放间隔时间)左右会有用户抽中一个奖品。例如，开始后第4分钟某一个用户抽中某一个奖品，第5分钟某一个用户随机数为8，第7分钟某一个用户随机数为8，那么则会向第7分钟的用户发放一个奖品，第5分钟的用户未抽中奖品。

第二个具体实例：

在一个抽奖活动的配置信息中，设置了奖品2的活动信息：“点歌机会”数量(资源总数量)3个，中奖点数(竞猜答案)是40，开始后第10分钟投放奖品(资源发放开始时间)、20分钟内投放完毕(资源发放持续时间)。

基于上述配置信息，抽奖活动持续了半个小时，采用本发明实施例提供的资源发放逻辑，那么前10分钟，用户没法抽到奖品2(点歌机会)，从10分钟开始，也就是第10分至第30分这个20分钟的时间段内，3首点歌机会较均匀的被用户抽中，即平均下来约6.7分钟被抽中一个。

根据上面两个具体实例可以看出，摇奖开始之后，两个奖品中奖情况都是均匀的，另外在均匀发奖的同时完全随机，避免作弊行为，参与一个普通参与摇奖的用户，从一开始到结尾都有希望抽中奖品，不会出现前期抽完了奖品后面就没人参与活动等情况。抽奖活动的配置信息实现更加灵活，非常有利于直播间主播和观众互动。

在一个实施例中，目标服务端向第一用户发放资源之后，还包括：

s130、目标服务端将对应的资源发放信息持久化后写入数据库。

资源发放信息是确定可以向第一用户发放资源后具体给第一用户发放的资源信息，以抽奖为例，资源发放信息为中奖用户的中奖信息。数据持久化可以通过现有技术中已有的方式实现。可选的，数据库为mysql(关系型数据库管理系统)，另外，数据库具有主备同步。应当理解，本发明并不对数据库的类型和数量等进行限定。

s140、若资源发放信息成功写入，目标服务端向第一客户端反馈资源发放信息。

为了保证数据的准确性，一场资源发放活动中，一般资源数目是远小于参与资源发放活动的用户数的，那么只在确定要进行资源发放的情况下持久化资源发放信息到数据库，写入数据库成功后，才返回客户端资源发放信息，这样即使服务存在宕机，也能从数据库中获取到正确的历史数据。在返回资源发放信息时可以采用广播的形式，广播给直播间所有用户，中奖者自己即能实时在客户端看到全部中奖信息，也能看到本次抽奖活动自己的中奖物品。

目前市场上一般会基于限流削峰结合各环节的性能优化实现资源发放，面向特定的平台或者活动，不能灵活定制，迁移至直播间中无法满足丰富玩法的需要。资源发放活动的开启也很难做到用户自己随意配置开启，主要是官方运营活动方式等。在直播领域泛娱乐的强互动情景下，很难满足用户需要。因此，本发明实施例除了合理优化发奖逻辑之外，还面向直播领域，提供了一种可于各个独立直播间随意开启，支持灵活配置资源发放信息的资源发放方法，下面进行详细介绍。

在一个实施例中，第一客户端向目标服务端发送直播间中参与资源发放活动的用户输入的资源发放请求之前，还包括：

s104、第二客户端向路由设备发送直播间中级别权限为管理员的第二用户配置的资源发放活动的活动信息，以及直播间信息和第二用户信息。

第二客户端为管理员所用的客户端。可选的，将直播间中的用户分为了两种角色，一种是管理员，一种是普通用户。管理员和普通用户均可参与资源发放活动，但是管理员具有配置、开启、停止资源发放活动的权限。管理员分为直播间主人(即主播)和一些普通管理员，主播可以赋予其他用户管理员权限。管理员和普通用户均具有抽奖、查看全部抽奖结果等权限。

每个管理员可以配置很多资源发放活动的活动信息。可选的，每个资源发放活动的活动信息包括活动名称、资源名称、资源总数量、资源发放开始时间和资源发放持续时间等等。另外，竞猜答案可以由管理员配置，比如摇奖的时候设置随机数50可中奖品a。如果管理员不配置，则目标服务端会自动生成一个竞猜答案，例如随机生成一个1～100的数字，该区间可以合理设置。

可选的，直播间信息包括直播间id，也即是频道id。用户信息包括用户id，例如账户名等，用来指明是哪个用户发起了什么请求，方便之后其他可能的业务逻辑处理。

在需要开启资源发放活动时，管理员配置该资源发放活动的活动信息，那么客户端即会将该资源发放活动的活动信息、直播间信息和第二用户信息发送给路由设备，也即是路由服务。可选的，客户端先将资源发放活动的活动信息、直播间信息和第二用户信息发送给接入服务，接入服务将资源发放活动的活动信息、直播间信息和第二用户信息分发到后面的路由服务，同时广播或者单播信息给客户端。其中，接入服务是客户端协议到达的第一关口，负责安全防护、负载均衡、消息转发等功能。

s105、路由设备根据直播间信息以及第二用户信息，将资源发放活动的活动信息转发至目标服务端。

路由服务主要负责转发来的资源发放活动的活动信息、直播间信息和第二用户信息进行解包，取出直播间信息和第二用户信息，然后根据该直播间信息和第二用户信息将资源发放活动的活动信息转发至目标服务端。

在一个实施例中，路由设备根据直播间信息以及第二用户信息，将资源发放活动的活动信息转发至目标服务端，包括：

s1051、路由设备根据直播间信息，将资源发放活动的活动信息哈希到负载低于第一阈值的机房。

每一机房即为一个集(set)，每一个集中包含多个服务端。先基于频道信息将资源发放活动的活动信息哈希到负载不高的机房。该步骤中的哈希算法的设计是灵活的，变量是频道id(即直播间id)，支持开发人员配置相关的哈希路由规则，具体可以采用主流常用的一些哈希算法。机房服务的负载信息可以从服务发现系统获取。

一般而言，服务发现系统是后端服务必备的系统，用来检测后端各服务状态，管理后端服务信息。上述方案提到的接入服务、路由服务和服务端都需要在服务发现系统注册，互相订阅相关信息，以获取对方服务状态。如果有服务出现故障，服务发现系统就会注销相关信息，其他服务就无法获取其信息转为其他服务提供处理，避免消息丢失。例如：路由服务把客户端请求转发给抽奖服务的时候，需要从服务发现系统获取抽奖服务的相关信息，才能正确建立连接进行通信。

s1052、路由设备根据第二用户信息，将资源发放活动的活动信息哈希到机房中负载低于第二阈值的目标服务端。

当第一步哈希得到一个具体的机房信息后，在该机房的服务端一般都是部署了多个的，每个服务端都会有服务id，再以用户信息为变量进行哈希，让资源发放活动的活动信息落到具体的服务上。该步骤的哈希算法同样可以采用主流常用的一些哈希算法。机房中各个服务端的负载信息可以从服务发现系统获取。另外，可选的，本步骤中的哈希变量还可以是直播间信息。

路由服务本质上是做了重要的资源发放活动活动信息的分派，有效的考虑了服务的负载均衡，在同时大量资源发放活动开启且参与用户众多时，采用两级哈希策略，让用户请求较均匀和合理地分发到后端服务，能有效地提供稳定的服务。

考虑到虽然服务端部署了很多，但是用户的请求可能会非常大，这些请求随着用户量的增大会给服务端增大压力。因为这些服务端注册到了服务发现系统，所以从服务发现系统可以获取后端服务端信息，从而可以基于相关服务信息对后端服务端进行扩容或者缩容部署。可选的，同一机房的服务端共用缓存系统(如redis集群)和数据库(如mysql)。那么在进行扩容时，只需要直接在该机房内增加新的服务端，新的服务端不会影响原有的一些逻辑，也不必考虑复杂的数据迁移情况，可以分担新到达的请求压力，缩容也是相同的道理。所以实现了平滑地对后端服务端进行扩容或者缩容部署，动态扩展性很好，甚至非常适宜使用docker等容器去部署服务，扩展简单，无需额外的限制，根据实际情况可以有效利用资源，节省成本。

s106、目标服务端根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识。

目标服务端根据接收到的资源发放活动的活动信息生成配置信息，例如，每个资源发放活动的活动信息包括活动名称、资源名称、资源总数量、资源发放开始时间和资源发放持续时间等等，那么目标服务端生成的配置信息包括活动名称对应的资源发放配置id、资源名称对应的资源id、资源总数量num、资源发放开始时间和资源发放持续时间等等。活动标识，即活动id，又称之为局次id，可记为actid，用于唯一标识每一局活动，即每局活动都分配一个活动标识。

通过上述方式，管理员可以在直播频道内多次开启同一配置信息，每次开启会生成对应的局次id(即活动id)，开启抽奖之后，各局次之间的资源发放信息均分开，互相隔离。每个频道可以配置不同资源发放方式，管理员可以随时随地开启资源发放活动。可以在顶级频道开启抽奖，也可以在具体的子频道里面开启抽奖活动，互相无感知，只有进入具体直播间才能参与该直播间的抽奖局次。配置信息包含的具体内容均可以灵活设置。

为了更好的理解上述配置信息，下面结合例子进行简单说明。应当理解，下述示例并不对配置信息的具体内容等进行限定。

管理员小王的直播间里面，配置了两种抽奖配置(资源发放配置id)：config_1和config_2。

config_1配置下面有奖品两个：“点歌”*数量1(奖品id为100)；“真心话问题”*数量1(奖品id为101)。

config_2配置下面有奖品一个：“玩具熊”*数量1(奖品id：501)。

周一，10点～11点，小王利用配置config_1开启了一局抽奖活动，分配局次id为actid_1；下午14点～15点，小王继续用配置config_1开启了一局抽奖活动，分配局次id为actid_2；

周二，10点～11点，小王利用配置config_2开启了一局抽奖活动，分配局次id为actid_3。此时用户小红中奖，获得奖品“玩具熊”，其奖品id为501。

在一个实施例中，目标服务端根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识之后，还包括：

s107、目标服务端将活动标识对应的资源发放活动的配置信息存储至对应的缓存系统和数据库中，其中，缓存系统被同一机房中各个服务端共用，数据库被各个机房共用。

每一次直播间管理员开启资源发放活动，目标服务端都会在缓存系统为当前局次创建一个局次会话信息，与其他局次隔离，同时写入数据库一份，其中，局次会话信息包括配置信息。加载配置信息放于缓存系统或数据库中，当用户抽中资源的时候，则更新会话信息中的相关资源数量数据。另外，因为创建资源发放活动属于较低频率的请求，所以也可以直接存储于数据库中。可选的，数据库和缓存系统均具备主备保活。

s108、若目标服务端崩溃，将目标服务端所在机房的其它服务端作为目标服务端，该目标服务端从缓存系统或者数据库中获取活动标识对应的资源发放活动的配置信息，以保持资源发放活动正常进行。

如果目标服务端崩溃，则其他服务端可以基于缓存系统或者数据库恢复相关局次对应的配置信息，继续提供客户端用户参与资源发放活动。例如，局次id为100的抽奖活动正在进行，负责提供服务的a机器突然故障，但是之前的会话信息实时保存到了缓存系统和数据库中，那么其他服务端检测到a机器的服务故障，就会根据缓存系统或数据库中的会话信息恢复本局次抽奖活动，局次id为100的抽奖活动正常开展，用户侧则没有感知这种变化，仍然可以继续参与抽奖。

s109、若目标服务端所在机房宕机，将其它机房的服务端作为目标服务端，该目标服务端从数据库中获取活动标识对应的资源发放活动的配置信息，以保持资源发放活动正常进行。

如果一个机房宕机，则请求会哈希到其他机房，其他机房的服务会基于数据库中中断局次的配置信息恢复该局次的资源发放活动，速度很快，一般用户无感知，等机房服务恢复后再同步数据，继续提供新的服务。

本发明实施例的发放资源的方法还可以实现限流，限流在于防刷与高峰限流，可以在接入服务中安装防刷安全模块，同时在产品层面限制用户，比如每个用户每分钟只能摇一次奖。这样就大大降低了非法攻击，降低了并发量。

基于同一发明构思，本发明还提供一种发放资源的系统，下面结合附图对本发明系统的具体实施方式进行详细介绍。

如图2所示，在一个实施例中，一种发放资源的系统，包括：

第一客户端110，用于向目标服务端发送直播间中参与资源发放活动的第一用户输入的资源发放请求；

目标服务端120，用于根据资源发放请求为第一用户分配竞猜信息，在竞猜信息与预先存储的资源发放活动的配置信息包含的竞猜答案匹配时，向第一用户发放资源。

在一个实施例中，配置信息还包含资源总数量、资源发放开始时间和资源发放持续时间；目标服务端120通过执行以下操作实现向第一用户发放资源：

判断记录的资源发放请求的接收时间是否晚于资源发放开始时间；

若接收时间晚于资源发放开始时间，计算接收时间和资源发放开始时间的第一时间差值；

若第一时间差值与整数倍的资源发放时间间隔之间的差值小于预设阈值，向第一用户发放资源，其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

在一个实施例中，目标服务端判断记录的资源发放请求的接收时间是否晚于资源发放开始时间之后，还用于执行以下操作：

若接收时间早于或等于资源发放开始时间，禁止向第一用户发放资源。

在一个实施例中，目标服务端计算接收时间和资源发放开始时间的第一时间差值之后，还用于执行以下操作：

若差值大于等于预设阈值，禁止向第一用户发放资源。

在一个实施例中，发放资源的系统还包括第二客户端和路由设备。在第一客户端向目标服务端发送直播间中参与资源发放活动的第一用户输入的资源发放请求之前，第二客户端向路由设备发送直播间中级别权限为管理员的第二用户配置的资源发放活动的活动信息，以及直播间信息和第二用户信息；路由设备根据直播间信息以及第二用户信息，将资源发放活动的活动信息转发至目标服务端120；目标服务端120根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识。

在一个实施例中，路由设备130用于执行以下操作：

根据直播间信息，将资源发放活动的活动信息哈希到负载低于第一阈值的机房；

根据第二用户信息，将资源发放活动的活动信息哈希到机房中负载低于第二阈值的目标服务端。

在一个实施例中，发放资源的系统还包括缓存系统、数据库以及各个机房，每一个机房包括各个服务端。目标服务端120根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识之后，将活动标识对应的资源发放活动的配置信息存储至对应的缓存系统和数据库中，其中，缓存系统被同一机房中各个服务端共用，数据库被各个机房共用。若目标服务端崩溃，将目标服务端所在机房的其它服务端作为目标服务端，该目标服务端从缓存系统或者数据库中获取活动标识对应的资源发放活动的配置信息，以保持资源发放活动正常进行。若目标服务端所在机房宕机，将其它机房的服务端作为目标服务端，该目标服务端从数据库中获取活动标识对应的资源发放活动的配置信息，以保持资源发放活动正常进行。

在一个实施例中，目标服务端120向第一用户发放资源之后，还用于将对应的资源发放信息持久化后写入数据库；若资源发放信息成功写入，向第一客户端110反馈资源发放信息。

为了更好的理解本发明，下面结合一个抽奖系统的具体实施例进行说明。

如图3所示，在一个具体实施例中，该抽奖系统包括客户端、接入服务、路由服务、各个机房中的抽奖服务、缓存系统以及数据库，其中各个抽奖服务是遍布各地的多个机房内服务，此图仅以部分服务示意，缓存系统和数据库都有主备保活。该抽奖系统在进行抽奖时，执行以下操作：

s1、客户端向接入服务发送直播间id、用户信息以及抽奖局次请求，该抽奖局次请求包括直播间的管理员配置的抽奖活动信息；

s2、接入服务结合负载均衡策略把相关消息转发至路由服务；

s3、路由服务解析消息，获取直播间id和用户信息，先根据直播间id将抽奖局次请求哈希到负载不高的机房，再按照用户信息将抽奖局次请求哈希到负载不高的具体抽奖服务上；

s4、该抽奖服务根据摇奖局次请求生成抽奖活动的配置信息，为本次抽奖活动分配局次id，将该局次id的配置信息加载到缓存系统和数据库中；

s5、在抽奖活动开始后，客户端将用户的抽奖请求发送给抽奖服务；

s6、抽奖服务生成随机数，并根据本次抽奖活动的配置信息判断用户是否中奖，如果中奖，则将该中奖信息持久化后写入数据库，然后广播给直播间所有用户，中奖者自己既能实时在客户端看到全部中奖信息，也能看到本次抽奖活动自己的中奖物品。

下面再从整个系统的角度，结合附图对本发明的具体实施方式进行详细介绍。

如图4所示，在一个实施例中，一种发放资源的方法，包括步骤：

s210、第一客户端向目标服务端发送直播间中参与资源发放活动的第一用户输入的资源发放请求，其中，资源发放请求中包括第一用户输入的竞猜信息。

第一客户端是第一用户所用的客户端。直播间也可以称为直播的频道，是主播开播的绑定虚拟房间，通常每个直播间都有唯一id(identification，身份标识号)。以yy直播间为例，直播间有顶级频道，记为topcid，可能对应多个子频道，记为subcid。单个直播间人数可高达百万级。资源包括虚拟或者实体礼物等等。资源发放活动是关于将资源发放给请求用户的活动，例如抽奖活动等。

进入直播间的用户一般均可以参与该直播间举办的资源发放活动。当直播间中的用户参与该资源发放活动时，客户端即会向目标服务端发送资源发放请求，请求为该用户发放资源。资源发放请求中包括第一用户输入的竞猜信息。竞猜信息用于确定是否可以向用户发放资源，具体形式与资源发放活动的类型有关，例如，资源发放活动用于猜一个数字，则竞猜信息即为给用户分配的数字。

s220、目标服务端接收到资源发放请求后，判断竞猜信息与预先存储的资源发放活动的配置信息中所包含的竞猜答案是否匹配；若匹配，则向第一用户发放资源。

资源发放活动的配置信息是进行资源发放活动的保障。竞猜答案可以根据实际需要进行设置，例如竞猜答案为某一类型的物品、某一个数字、某一个物品、某一个颜色或者某一个名字等等，以抽奖为例，中奖点数即为竞猜答案，例如，中奖点数为8。

接收到竞猜信息后，将该竞猜信息与预先存储的竞猜答案匹配。如果两者匹配，则确定向第一用户发放资源。如果两者不匹配，则不向第一用户发放资源。

本实施例通过将竞猜信息和预先存储的竞猜答案进行匹配，在匹配时向发送资源发放请求的用户发放资源，从而在直播间中实现了资源发放，更好满足直播中用户的互动需要。

如果仅根据竞猜信息和竞猜答案匹配即发放资源，当用户群足够大的时候，只是竞猜信息和竞猜答案对应是非常容易的，很有可能导致资源发放活动刚开始所有资源均已被抽中或者资源发放活动开始较长时间资源一直未被抽中的问题，降低用户参与资源发放活动的积极性，不能很好满足直播中用户的互动需求。因此为了能很好的支持资源发放活动开展，增加互动，还需要根据资源发放请求的接收时间和配置信息进一步判定是否能够向第一用户发放资源，实现资源的均匀发放。

可选的，配置信息还包含资源总数量和资源发放持续时间等。资源总数量为配置的发放资源的总数目。资源发放持续时间指的是从资源发放开始时间起所持续的时间，例如，资源发放持续时间设置为20分钟内投放完毕，那么从资源发放开始时间起20分钟内需要把所有资源投放完毕。后续会对配置信息进行详细介绍。

在一个实施例中，目标服务端向第一用户发放资源，包括：

s2201、目标服务端计算记录的资源发放请求的接收时间与资源发放活动的开启时间的第一时间差值。

目标服务端在接收到资源发放请求时可以记录该资源发放请求的接收时间。目标服务端向直播间中的各个用户广播资源发放活动时可以记录该资源发放活动的开启时间。得到接收时间和资源发放活动的开启时间后，计算两者的第一时间差值。

另外，本发明考虑到客户端生成资源发放请求到目标服务端接收到该资源发放请求的时间很短，因此选择了资源发放请求的接收时间，应当理解，本发明实施例还可以采用资源发放请求的生成时间等等，只要可以表征第一用户参与资源发放活动的时间即可。

s2202、若第一时间差值与整数倍的资源发放时间间隔之间的差值小于预设阈值，目标服务端向第一用户发放资源，其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

预设阈值可以根据实际需要进行设置，为了保证判断的准确性，预设阈值宜设置一个较小的值。资源发放时间间隔用于确定是否到达能够发放资源的时间段内。如果竞猜信息与竞猜答案匹配，且第一用户参加资源发放活动的时间(即接收时间)到达能够发放资源的时间段内，则为第一用户发放资源，具体发放资源的类型和数量包含在配置信息中。

在一个实施例中，目标服务端计算接收时间和资源发放开始时间的第一时间差值之后，还包括：

若第一时间差值大于等于预设阈值，目标服务端禁止向第一用户发放资源。

如果竞猜信息与竞猜答案匹配，但是第一用户参加资源发放活动的时间还未到达能够发放资源的时间段内，则不向该第一用户发放资源。

在另一个实施例中，还可以获取本次资源发放活动中的历史资源发放记录，该历史资源发放记录记录有用户成功获取资源的时间点以及资源的类型等。在竞猜信息与竞猜答案匹配时，目标服务端若根据历史资源发放记录确定还未向任何用户发放过资源，则计算接收时间和资源发放活动的开启时间的第二时间差值，如果第二时间差值在资源发放时间间隔附近，则向第一用户发放资源，否则不向第一用户发放资源；目标服务端若根据历史资源发放记录确定已向某些用户发放过资源，则获取最近一次发放资源的时间，计算接收时间和最近一次发放资源时间的第三时间差值，如果第三时间差值在资源发放时间间隔附近，则向第一用户发放资源，否则不向第一用户发放资源。

通过上述实施例可以看出，除非用户(管理员)配置了某场资源发放活动某个资源开场多久后才有机会被抽中，否则资源的发放概率是“均匀”贯穿整个资源发放活动的，即各个资源的发放概率从一开始到最终的活动结束都是“均衡”的，不会出现资源一下子发放完毕的情况。

为了更好的理解上述资源发放逻辑，下面结合在直播间中抽奖的两个具体实例进行说明。

第一个具体实例：

在一个抽奖活动的配置信息中，设置了奖品1的活动信息：“玩具熊”数量(资源总数量)10个，中奖点数(竞猜答案)是8，抽奖活动开启后30分钟内投放完毕(资源发放持续时间)。

基于上述配置信息，本实施例采用的资源发放逻辑就会把10个玩具熊的中奖情况较均匀的控制在30分钟内，也就是说，一般而言平均3分钟(资源发放间隔时间)左右会有用户抽中一个奖品。例如，开始后第3分钟某一个用户抽中某一个奖品，第4分钟某一个用户随机数为8，第6分钟某一个用户随机数为8，那么则会向第6分钟的用户发放一个奖品，第4分钟的用户未抽中奖品。

第二个具体实例：

在一个抽奖活动的配置信息中，设置了奖品2的活动信息：“点歌机会”数量(资源总数量)3个，中奖点数(竞猜答案)是40，资源活动开启后20分钟内投放完毕(资源发放持续时间)。

基于上述配置信息，抽奖活动持续了20分钟，采用本发明实施例提供的资源发放逻辑，在该20分钟内，3首点歌机会较均匀的被用户抽中，即平均下来约6.7分钟被抽中一个。

根据上面两个具体实例可以看出，摇奖开始之后，两个奖品中奖情况都是均匀的，另外在均匀发奖的同时完全随机，避免作弊行为，参与一个普通参与摇奖的用户，从一开始到结尾都有希望抽中奖品，不会出现前期抽完了奖品后面就没人参与活动等情况。抽奖活动的配置信息实现更加灵活，非常有利于直播间主播和观众互动。

在一个实施例中，目标服务端向第一用户发放资源之后，还包括：

s230、目标服务端将对应的资源发放信息持久化后写入数据库。

资源发放信息是确定可以向第一用户发放资源后具体给第一用户发放的资源信息，以抽奖为例，资源发放信息为中奖用户的中奖信息。数据持久化可以通过现有技术中已有的方式实现。可选的，数据库为mysql(关系型数据库管理系统)，另外，数据库具有主备同步。应当理解，本发明并不对数据库的类型和数量等进行限定。

s240、若资源发放信息成功写入，目标服务端向第一客户端反馈资源发放信息。

为了保证数据的准确性，一场资源发放活动中，一般资源数目是远小于参与资源发放活动的用户数的，那么只在确定要进行资源发放的情况下持久化资源发放信息到数据库，写入数据库成功后，才返回客户端资源发放信息，这样即使服务存在宕机，也能从数据库中获取到正确的历史数据。在返回资源发放信息时可以采用广播的形式，广播给直播间所有用户，中奖者自己即能实时在客户端看到全部中奖信息，也能看到本次抽奖活动自己的中奖物品。

目前市场上一般会基于限流削峰结合各环节的性能优化实现资源发放，面向特定的平台或者活动，不能灵活定制，迁移至直播间中无法满足丰富玩法的需要。资源发放活动的开启也很难做到用户自己随意配置开启，主要是官方运营活动方式等。在直播领域泛娱乐的强互动情景下，很难满足用户需要。因此，本发明实施例除了合理优化发奖逻辑之外，还面向直播领域，提供了一种可于各个独立直播间随意开启，支持灵活配置资源发放信息的资源发放方法，下面进行详细介绍。

在一个实施例中，第一客户端向目标服务端发送直播间中参与资源发放活动的用户输入的资源发放请求之前，还包括：

s205、第二客户端向目标服务端发送直播间中级别权限为管理员的第二用户配置的资源发放活动的活动信息，其中，活动信息包括竞猜答案。

第二客户端为管理员所用的客户端。可选的，将直播间中的用户分为了两种角色，一种是管理员，一种是普通用户。管理员和普通用户均可参与资源发放活动，但是管理员具有配置、开启、停止资源发放活动的权限。管理员分为直播间主人(即主播)和一些普通管理员，主播可以赋予其他用户管理员权限。管理员和普通用户均具有抽奖、查看全部抽奖结果等权限。

每个管理员可以配置很多资源发放活动的活动信息。可选的，每个资源发放活动的活动信息包括活动名称、资源名称、资源总数量、竞猜答案和资源发放持续时间等等。

可选的，直播间信息包括直播间id，也即是频道id。用户信息包括用户id，例如账户名等，用来指明是哪个用户发起了什么请求，方便之后其他可能的业务逻辑处理。

在需要开启资源发放活动时，管理员配置该资源发放活动的活动信息，那么客户端即会将该资源发放活动的活动信息发送给目标服务端。

s206、目标服务端根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识，向直播间中的各个用户广播活动标识对应的资源发放活动。

目标服务端根据接收到的资源发放活动的活动信息生成配置信息，例如，每个资源发放活动的活动信息包括活动名称、资源名称、资源总数量、竞猜答案和资源发放持续时间等等，那么目标服务端生成的配置信息包括活动名称对应的资源发放配置id、资源名称对应的资源id、资源总数量num、竞猜答案和资源发放持续时间等等。活动标识，即活动id，又称之为局次id，可记为actid，用于唯一标识每一局活动，即每局活动都分配一个活动标识。

得到该活动标识对应的配置信息后，目标服务端向直播间中各个用户广播该资源发放活动，直播间中的各个用户即可以参与该资源发放活动。

通过上述方式，管理员可以在直播频道内多次开启同一配置信息，每次开启会生成对应的局次id(即活动id)，开启抽奖之后，各局次之间的资源发放信息均分开，互相隔离。每个频道可以配置不同资源发放方式，管理员可以随时随地开启资源发放活动。可以在顶级频道开启抽奖，也可以在具体的子频道里面开启抽奖活动，互相无感知，只有进入具体直播间才能参与该直播间的抽奖局次。配置信息包含的具体内容均可以灵活设置。

为了更好的理解上述配置信息，下面结合例子进行简单说明。应当理解，下述示例并不对配置信息的具体内容等进行限定。

管理员小王的直播间里面，配置了两种抽奖配置(资源发放配置id)：config_1和config_2。

config_1配置下面有奖品两个：“点歌”*数量1(奖品id为100)；“真心话问题”*数量1(奖品id为101)。

config_2配置下面有奖品一个：“玩具熊”*数量1(奖品id：501)。

周一，10点～11点，小王利用配置config_1开启了一局抽奖活动，分配局次id为actid_1；下午14点～15点，小王继续用配置config_1开启了一局抽奖活动，分配局次id为actid_2；

周二，10点～11点，小王利用配置config_2开启了一局抽奖活动，分配局次id为actid_3。此时用户小红中奖，获得奖品“玩具熊”，其奖品id为501。

在一个实施例中，目标服务端根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识之后，还包括：

s207、目标服务端将活动标识对应的资源发放活动的配置信息存储至对应的缓存系统和数据库中，其中，缓存系统被同一机房中各个服务端共用，数据库被各个机房共用。

每一次直播间管理员开启资源发放活动，目标服务端都会在缓存系统为当前局次创建一个局次会话信息，与其他局次隔离，同时写入数据库一份，其中，局次会话信息包括配置信息。加载配置信息放于缓存系统或数据库中，当用户抽中资源的时候，则更新会话信息中的相关资源数量数据。另外，因为创建资源发放活动属于较低频率的请求，所以也可以直接存储于数据库中。可选的，数据库和缓存系统均具备主备保活。

考虑到虽然服务端部署了很多，但是用户的请求可能会非常大，这些请求随着用户量的增大会给服务端增大压力。因为这些服务端注册到了服务发现系统，所以从服务发现系统可以获取后端服务端信息，从而可以基于相关服务信息对后端服务端进行扩容或者缩容部署。可选的，同一机房的服务端共用缓存系统(如redis集群)和数据库(如mysql)。那么在进行扩容时，只需要直接在该机房内增加新的服务端，新的服务端不会影响原有的一些逻辑，也不必考虑复杂的数据迁移情况，可以分担新到达的请求压力，缩容也是相同的道理。所以实现了平滑地对后端服务端进行扩容或者缩容部署，动态扩展性很好，甚至非常适宜使用docker等容器去部署服务，扩展简单，无需额外的限制，根据实际情况可以有效利用资源，节省成本。

s208、若目标服务端崩溃，将目标服务端所在机房的其它服务端作为目标服务端，该目标服务端从缓存系统或者数据库中获取活动标识对应的资源发放活动的配置信息，以保持资源发放活动正常进行。

如果目标服务端崩溃，则其他服务端可以基于缓存系统或者数据库恢复相关局次对应的配置信息，继续提供客户端用户参与资源发放活动。例如，局次id为100的抽奖活动正在进行，负责提供服务的a机器突然故障，但是之前的会话信息实时保存到了缓存系统和数据库中，那么其他服务端检测到a机器的服务故障，就会根据缓存系统或数据库中的会话信息恢复本局次抽奖活动，局次id为100的抽奖活动正常开展，用户侧则没有感知这种变化，仍然可以继续参与抽奖。

s209、若目标服务端所在机房宕机，将其它机房的服务端作为目标服务端，该目标服务端从数据库中获取活动标识对应的资源发放活动的配置信息，以保持资源发放活动正常进行。

如果一个机房宕机，则请求会哈希到其他机房，其他机房的服务会基于数据库中中断局次的配置信息恢复该局次的资源发放活动，速度很快，一般用户无感知，等机房服务恢复后再同步数据，继续提供新的服务。

本发明实施例的发放资源的方法还可以实现限流，限流在于防刷与高峰限流，可以在接入服务中安装防刷安全模块，同时在产品层面限制用户，比如每个用户每分钟只能摇一次奖。这样就大大降低了非法攻击，降低了并发量。

基于同一发明构思，本发明还提供一种发放资源的系统，下面结合附图对本发明系统的具体实施方式进行详细介绍。

如图5所示，在一个实施例中，一种发放资源的系统，包括：

第一客户端210，用于向目标服务端发送直播间中参与资源发放活动的第一用户输入的资源发放请求，其中，资源发放请求中包括第一用户输入的竞猜信息；

目标服务端220，用于接收到资源发放请求后，判断竞猜信息与预先存储的资源发放活动的配置信息中所包含的竞猜答案是否匹配；若匹配，则向第一用户发放资源。

在一个实施例中，配置信息还包含资源总数量和资源发放持续时间；目标服务端220通过执行以下操作实现向第一用户发放资源：

目标服务端计算记录的资源发放请求的接收时间与资源发放活动的开启时间的第一时间差值；

若第一时间差值与整数倍的资源发放时间间隔之间的差值小于预设阈值，目标服务端向第一用户发放资源，其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

在一个实施例中，目标服务端计算记录的资源发放请求的接收时间与资源发放活动的开始时间的第一时间差值之后，还包括：

若第一时间差值大于等于预设阈值，目标服务端禁止向第一用户发放资源。

在一个实施例中，发放资源的系统还包括第二客户端。在第一客户端向目标服务端发送直播间中参与资源发放活动的第一用户输入的资源发放请求之前，第二客户端向目标服务端发送直播间中级别权限为管理员的第二用户配置的资源发放活动的活动信息，其中，活动信息包括竞猜答案；目标服务端220根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识，向直播间中的各个用户广播活动标识对应的资源发放活动。

在一个实施例中，发放资源的系统还包括缓存系统、数据库以及各个机房，每一个机房包括各个服务端。目标服务端220根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识之后，将活动标识对应的资源发放活动的配置信息存储至对应的缓存系统和数据库中，其中，缓存系统被同一机房中各个服务端共用，数据库被各个机房共用。若目标服务端崩溃，将目标服务端所在机房的其它服务端作为目标服务端，该目标服务端从缓存系统或者数据库中获取活动标识对应的资源发放活动的配置信息，以保持资源发放活动正常进行。若目标服务端所在机房宕机，将其它机房的服务端作为目标服务端，该目标服务端从数据库中获取活动标识对应的资源发放活动的配置信息，以保持资源发放活动正常进行。

在一个实施例中，目标服务端220向第一用户发放资源之后，还用于将对应的资源发放信息持久化后写入数据库；若资源发放信息成功写入，向第一客户端210反馈资源发放信息。

为了更好的理解本发明，下面结合一个抽奖系统的具体实施例进行说明。

如图3所示，在一个具体实施例中，该抽奖系统包括客户端、接入服务、路由服务、各个机房中的抽奖服务、缓存系统以及数据库，其中各个抽奖服务是遍布各地的多个机房内服务，此图仅以部分服务示意，缓存系统和数据库都有主备保活。该抽奖系统在进行抽奖时，执行以下操作：

s1、客户端通过接入服务和路由服务向目标抽奖服务发送抽奖局次请求，该抽奖局次请求包括直播间的管理员配置的抽奖活动信息，抽奖活动信息包含中奖点数；

s2、该目标抽奖服务根据摇奖局次请求生成抽奖活动的配置信息，为本次抽奖活动分配局次id，将该局次id的配置信息加载到缓存系统和数据库中，向直播间中的各个用户广播本次抽奖活动；

s3、在抽奖活动开始后，客户端将用户的抽奖请求发送给抽奖服务，其中，抽奖请求包含用户输入的数字；

s4、抽奖服务将用户输入的数字和配置信息中的中奖点数进行匹配，如果中奖，则将该中奖信息持久化后写入数据库，然后广播给直播间所有用户，中奖者自己既能实时在客户端看到全部中奖信息，也能看到本次抽奖活动自己的中奖物品。

下面从用于发放资源的服务端的角度，结合附图对本发明的具体实施方式进行详细介绍。

如图6a所示，在一个实施例中，一种发放资源的方法，包括步骤：

s301a、接收直播间中参与资源发放活动的第一用户输入的资源发放请求。

s302a、根据资源发放请求为第一用户分配竞猜信息，若竞猜信息与预先存储的资源发放活动的配置信息包含的竞猜答案匹配，则获取配置信息包含的资源总数量和资源发放持续时间，根据资源总数量和资源发放持续时间得到资源发放时间间隔；其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

s303a、通过资源发放时间间隔确定资源发放请求的接收时间是否达到发放资源的时间段内。

s304a、若达到发放资源的时间段内，则向第一用户发放资源。

如图6b所示，在一个实施例中，一种发放资源的方法，包括步骤：

s310、接收直播间中参与资源发放活动的第一用户输入的资源发放请求。

直播间也可以称为直播的频道，是主播开播的绑定虚拟房间，通常每个直播间都有唯一id。以yy直播间为例，直播间有顶级频道，记为topcid，可能对应多个子频道，记为subcid。单个直播间人数可高达百万级。资源包括虚拟或者实体礼物等等。资源发放活动是关于将资源发放给请求用户的活动，例如抽奖活动等。

进入直播间的用户一般均可以参与该直播间举办的资源发放活动。当直播间中的用户参与该资源发放活动时，客户端即会向目标服务端发送资源发放请求，请求为该用户发放资源。

s320、根据资源发放请求为第一用户分配竞猜信息。

接收到资源发放请求后，即会根据该资源发放请求为用户分配竞猜信息。竞猜信息用于确定是否可以向用户发放资源，具体形式与资源发放活动的类型有关，例如，资源发放活动用于猜一个数字，则竞猜信息即为给用户分配的数字。

s330、若竞猜信息与预先存储的资源发放活动的配置信息包含的竞猜答案匹配，向第一用户发放资源。

资源发放活动的配置信息是进行资源发放活动的保障。竞猜答案可以根据实际需要进行设置，例如竞猜答案为某一类型的物品、某一个数字、某一个物品、某一个颜色或者某一个名字等等，以抽奖为例，中奖点数即为竞猜答案，例如，中奖点数为8。

为第一用户分配竞猜信息后，将该竞猜信息与预先存储的竞猜答案匹配。如果两者匹配，则确定向第一用户发放资源。如果两者不匹配，则不向第一用户发放资源。

为了保证资源发放活动的公平性，可选的，在资源发放活动中采用随机数机制。因此，在一个实施例中，竞猜信息为随机数，竞猜答案为中奖点数；若竞猜信息与预先存储的资源发放活动的配置信息包含的竞猜答案匹配，向第一用户发放资源，包括：

若随机数与预先存储的资源发放活动的配置信息包含的中奖点数匹配，向第一用户发放资源。

当目标服务端接收到第一用户的资源发放请求时，为该第一用户随机生成随机数，判断该随机数是否与中奖点数匹配，从而判断是否能为该第一用户分配资源，避免了造假情况的出现。可选的，采用梅森旋转算法(mersennetwister)生成随机数。应当理解，本发明并不对随机数的生成算法进行限定，用户还可以根据实际需要采用其它算法生成随机数。

本实施例为发送资源发放请求的用户分配竞猜信息，然后将该竞猜信息和预先存储的竞猜答案进行匹配，在匹配时向发送资源发放请求的用户发放资源，从而在直播间中实现了资源发放，更好满足直播中用户的互动需要。

如果仅根据竞猜信息和竞猜答案匹配即发放资源，当用户群足够大的时候，只是竞猜信息和竞猜答案对应是非常容易的，很有可能导致资源发放活动刚开始所有资源均已被抽中或者资源发放活动开始较长时间资源一直未被抽中的问题，降低用户参与资源发放活动的积极性，不能很好满足直播中用户的互动需求。因此为了能很好的支持资源发放活动开展，增加互动，还需要根据资源发放请求的接收时间和配置信息进一步判定是否能够向第一用户发放资源，实现资源的均匀发放。

可选的，配置信息还包含资源总数量、资源发放开始时间以及资源发放持续时间等。资源总数量为配置的发放资源的总数目。资源发放开始时间为设置的开始能够发放资源的时间，例如，资源发放开始时间设置为在开始后第10分钟投放资源，那么在资源发放活动前10分钟不会进行资源发放，从第10分钟开始进行资源发放。资源发放持续时间指的是从资源发放开始时间起所持续的时间，例如，资源发放持续时间设置为20分钟内投放完毕，那么从资源发放开始时间起20分钟内需要把所有资源投放完毕。后续会对配置信息进行详细介绍。

在一个实施例中，向第一用户发放资源，包括：

s3301、判断记录的资源发放请求的接收时间是否晚于资源发放开始时间。

接收时间可以是接收到资源发放请求时的实际系统时间，那么同样的资源发放开始时间指的也是实际系统时间。接收时间还可以是距离资源发放活动开始的时间差，那么同样的资源发放开始时间指的也是距离资源发放活动开始的时间差。另外，本发明考虑到客户端生成资源发放请求到目标服务端接收到该资源发放请求的时间很短，因此选择了资源发放请求的接收时间，应当理解，本发明实施例还可以采用资源发放请求的生成时间等等，只要可以表征第一用户参与资源发放活动的时间即可。

s3302、若接收时间晚于资源发放开始时间，计算接收时间和资源发放开始时间的第一时间差值。

若接收时间比资源发放开始时间晚，计算第一时间差值，第一时间差值等于接收时间减去资源发放开始时间。

在一个实施例中，判断记录的资源发放请求的接收时间是否晚于资源发放开始时间之后，还包括：

若接收时间早于或等于资源发放开始时间，禁止向第一用户发放资源。

如果接收时间早于或等于资源发放开始时间，即使竞猜信息与竞猜答案匹配，由于还未到设置的能够投放资源的时间，也不向第一用户发放资源。以抽奖为例，则在该种情况下第一用户未中奖。

s3303、若第一时间差值与整数倍的资源发放时间间隔之间的差值小于预设阈值，向第一用户发放资源，其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

预设阈值可以根据实际需要进行设置，为了保证判断的准确性，预设阈值宜设置一个较小的值。资源发放时间间隔用于确定是否到达能够发放资源的时间段内。如果竞猜信息与竞猜答案匹配，且第一用户参加资源发放活动的时间(即接收时间)到达能够发放资源的时间段内，则为第一用户发放资源，具体发放资源的类型和数量包含在配置信息中。

在一个实施例中，计算接收时间和资源发放开始时间的第一时间差值之后，还包括：

若第一时间差值大于等于预设阈值，禁止向第一用户发放资源。

如果竞猜信息与竞猜答案匹配，但是第一用户参加资源发放活动的时间还未到达能够发放资源的时间段内，则不向该第一用户发放资源。

在另一个实施例中，还可以获取本次资源发放活动中的历史资源发放记录，该历史资源发放记录记录有用户成功获取资源的时间点以及资源的类型等。在竞猜信息与竞猜答案匹配时，目标服务端判断接收时间是否晚于资源发放开始时间。若否，目标服务端禁止向第一用户发放资源。若是，目标服务端若根据历史资源发放记录确定还未向任何用户发放过资源，则计算接收时间和资源发放开始时间的第二时间差值，如果第二时间差值在资源发放时间间隔附近，则向第一用户发放资源，否则不向第一用户发放资源；目标服务端若根据历史资源发放记录确定已向某些用户发放过资源，则获取最近一次发放资源的时间，计算接收时间和最近一次发放资源时间的第三时间差值，如果第三时间差值在资源发放时间间隔附近，则向第一用户发放资源，否则不向第一用户发放资源。

通过上述实施例可以看出，除非用户(管理员)配置了某场资源发放活动某个资源开场多久后才有机会被抽中，否则资源的发放概率是“均匀”贯穿整个资源发放活动的，即各个资源的发放概率从一开始到最终的活动结束都是“均衡”的，不会出现资源一下子发放完毕的情况。

在一个实施例中，向第一用户发放资源之后，还包括：

s340、将对应的资源发放信息持久化后写入数据库。

资源发放信息是确定可以向第一用户发放资源后具体给第一用户发放的资源信息，以抽奖为例，资源发放信息为中奖用户的中奖信息。数据持久化可以通过现有技术中已有的方式实现。可选的，数据库为mysql(关系型数据库管理系统)，另外，数据库具有主备同步。应当理解，本发明并不对数据库的类型和数量等进行限定。

s350、若资源发放信息成功写入，反馈资源发放信息。

为了保证数据的准确性，一场资源发放活动中，一般资源数目是远小于参与资源发放活动的用户数的，那么只在确定要进行资源发放的情况下持久化资源发放信息到数据库，写入数据库成功后，才返回客户端资源发放信息，这样即使服务存在宕机，也能从数据库中获取到正确的历史数据。在返回资源发放信息时可以采用广播的形式，广播给直播间所有用户，中奖者自己即能实时在客户端看到全部中奖信息，也能看到本次抽奖活动自己的中奖物品。

目前市场上一般会基于限流削峰结合各环节的性能优化实现资源发放，面向特定的平台或者活动，不能灵活定制，迁移至直播间中无法满足丰富玩法的需要。资源发放活动的开启也很难做到用户自己随意配置开启，主要是官方运营活动方式等。在直播领域泛娱乐的强互动情景下，很难满足用户需要。因此，本发明实施例除了合理优化发奖逻辑之外，还面向直播领域，提供了一种可于各个独立直播间随意开启，支持灵活配置资源发放信息的资源发放方法，下面进行详细介绍。

在一个实施例中，接收直播间中参与资源发放活动的用户输入的资源发放请求之前，还包括：

s308、接收直播间中级别权限为管理员的第二用户配置的资源发放活动的活动信息。

可选的，将直播间中的用户分为了两种角色，一种是管理员，一种是普通用户。管理员和普通用户均可参与资源发放活动，但是管理员具有配置、开启、停止资源发放活动的权限。管理员分为直播间主人(即主播)和一些普通管理员，主播可以赋予其他用户管理员权限。管理员和普通用户均具有抽奖、查看全部抽奖结果等权限。

每个管理员可以配置很多资源发放活动的活动信息。可选的，每个资源发放活动的活动信息包括活动名称、资源名称、资源总数量、资源发放开始时间和资源发放持续时间等等。另外，竞猜答案可以由管理员配置，比如摇奖的时候设置随机数50可中奖品a。如果管理员不配置，则目标服务端会自动生成一个竞猜答案，例如随机生成一个1～100的数字，该区间可以合理设置。

s309、根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识。

目标服务端根据接收到的资源发放活动的活动信息生成配置信息，例如，每个资源发放活动的活动信息包括活动名称、资源名称、资源总数量、资源发放开始时间和资源发放持续时间等等，那么目标服务端生成的配置信息包括活动名称对应的资源发放配置id、资源名称对应的资源id、资源总数量num、资源发放开始时间和资源发放持续时间等等。活动标识，即活动id，又称之为局次id，可记为actid，用于唯一标识每一局活动，即每局活动都分配一个活动标识。

通过上述方式，管理员可以在直播频道内多次开启同一配置信息，每次开启会生成对应的局次id(即活动id)，开启抽奖之后，各局次之间的资源发放信息均分开，互相隔离。每个频道可以配置不同资源发放方式，管理员可以随时随地开启资源发放活动。可以在顶级频道开启抽奖，也可以在具体的子频道里面开启抽奖活动，互相无感知，只有进入具体直播间才能参与该直播间的抽奖局次。配置信息包含的具体内容均可以灵活设置。

上述从服务端描述的资源发放方法的其他技术特征与上述从系统描述的资源发放方法的技术特征相同，在此不予赘述。

基于同一发明构思，本发明还提供一种发放资源的装置，下面结合附图对本发明装置的具体实施方式进行详细描述。

如图7所示，在一个实施例中，一种发放资源的装置，包括：

资源发放请求接收模块310，用于接收直播间中参与资源发放活动的第一用户输入的资源发放请求；

竞猜信息分配模块320，用于根据资源发放请求为第一用户分配随机数；

资源发放模块330，用于在竞猜信息与预先存储的资源发放活动的配置信息包含的竞猜答案匹配时，向第一用户发放资源。

在一个实施例中，配置信息还包含资源总数量、资源发放开始时间和资源发放持续时间；资源发放模块330用于执行以下操作：

判断记录的资源发放请求的接收时间是否晚于资源发放开始时间；

若接收时间晚于资源发放开始时间，计算接收时间和资源发放开始时间的第一时间差值；

若第一时间差值与整数倍的资源发放时间间隔之间的差值小于预设阈值，向第一用户发放资源，其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

在一个实施例中，资源发放模块330判断记录的资源发放请求的接收时间是否晚于资源发放开始时间之后，还用于在接收时间早于或等于资源发放开始时间时，禁止向第一用户发放资源。

在一个实施例中，资源发放模块330计算接收时间和资源发放开始时间的第一时间差值之后，还用于在差值大于等于预设阈值时，禁止向第一用户发放资源。

在一个实施例中，还包括与资源发放请求接收模块310相连的资源发放活动开启模块，用于执行以下操作：

接收直播间中级别权限为管理员的第二用户配置的资源发放活动的活动信息；

根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识。

在一个实施例中，资源发放模块330向第一用户发放资源之后，还用于执行以下操作：

将对应的资源发放信息持久化后写入数据库；

若资源发放信息成功写入，反馈资源发放信息。

下面再从用于发放资源的服务端的角度，结合附图对本发明的具体实施方式进行详细介绍。

如图8所示，在一个实施例中，一种发放资源的方法，包括步骤：

s410、接收直播间中参与资源发放活动的第一用户输入的资源发放请求，其中，资源发放请求中包括第一用户输入的竞猜信息。

直播间也可以称为直播的频道，是主播开播的绑定虚拟房间，通常每个直播间都有唯一id(identification，身份标识号)。以yy直播间为例，直播间有顶级频道，记为topcid，可能对应多个子频道，记为subcid。单个直播间人数可高达百万级。资源包括虚拟或者实体礼物等等。资源发放活动是关于将资源发放给请求用户的活动，例如抽奖活动等。

进入直播间的用户一般均可以参与该直播间举办的资源发放活动。当直播间中的用户参与该资源发放活动时，客户端即会向目标服务端发送资源发放请求，请求为该用户发放资源。资源发放请求中包括第一用户输入的竞猜信息。竞猜信息用于确定是否可以向用户发放资源，具体形式与资源发放活动的类型有关，例如，资源发放活动用于猜一个数字，则竞猜信息即为给用户分配的数字。

s420、判断竞猜信息与预先存储的资源发放活动的配置信息中所包含的竞猜答案是否匹配。

资源发放活动的配置信息是进行资源发放活动的保障。竞猜答案可以根据实际需要进行设置，例如竞猜答案为某一类型的物品、某一个数字、某一个物品、某一个颜色或者某一个名字等等，以抽奖为例，中奖点数即为竞猜答案，例如，中奖点数为8。接收到竞猜信息后，将该竞猜信息与预先存储的竞猜答案匹配。

s430、若匹配，向第一用户发放资源。

如果两者匹配，则确定向第一用户发放资源。如果两者不匹配，则不向第一用户发放资源。

本实施例通过将竞猜信息和预先存储的竞猜答案进行匹配，在匹配时向发送资源发放请求的用户发放资源，从而在直播间中实现了资源发放，更好满足直播中用户的互动需要。

如果仅根据竞猜信息和竞猜答案匹配即发放资源，当用户群足够大的时候，只是竞猜信息和竞猜答案对应是非常容易的，很有可能导致资源发放活动刚开始所有资源均已被抽中或者资源发放活动开始较长时间资源一直未被抽中的问题，降低用户参与资源发放活动的积极性，不能很好满足直播中用户的互动需求。因此为了能很好的支持资源发放活动开展，增加互动，还需要根据资源发放请求的接收时间和配置信息进一步判定是否能够向第一用户发放资源，实现资源的均匀发放。

可选的，配置信息还包含资源总数量和资源发放持续时间等。资源总数量为配置的发放资源的总数目。资源发放持续时间指的是从资源发放开始时间起所持续的时间，例如，资源发放持续时间设置为20分钟内投放完毕，那么从资源发放开始时间起20分钟内需要把所有资源投放完毕。后续会对配置信息进行详细介绍。

在一个实施例中，向第一用户发放资源，包括：

s4301、计算记录的资源发放请求的接收时间与资源发放活动的开启时间的第一时间差值。

目标服务端在接收到资源发放请求时可以记录该资源发放请求的接收时间。目标服务端向直播间中的各个用户广播资源发放活动时可以记录该资源发放活动的开启时间。得到接收时间和资源发放活动的开启时间后，计算两者的第一时间差值。

另外，本发明考虑到客户端生成资源发放请求到目标服务端接收到该资源发放请求的时间很短，因此选择了资源发放请求的接收时间，应当理解，本发明实施例还可以采用资源发放请求的生成时间等等，只要可以表征第一用户参与资源发放活动的时间即可。

s4302、若第一时间差值与整数倍的资源发放时间间隔之间的差值小于预设阈值，向第一用户发放资源，其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

预设阈值可以根据实际需要进行设置，为了保证判断的准确性，预设阈值宜设置一个较小的值。资源发放时间间隔用于确定是否到达能够发放资源的时间段内。如果竞猜信息与竞猜答案匹配，且第一用户参加资源发放活动的时间(即接收时间)到达能够发放资源的时间段内，则为第一用户发放资源，具体发放资源的类型和数量包含在配置信息中。

在一个实施例中，计算记录的资源发放请求的接收时间与资源发放活动的开始时间的第一时间差值之后，还包括：

若差值大于等于预设阈值，禁止向第一用户发放资源。

如果竞猜信息与竞猜答案匹配，但是第一用户参加资源发放活动的时间还未到达能够发放资源的时间段内，则不向该第一用户发放资源。

在另一个实施例中，还可以获取本次资源发放活动中的历史资源发放记录，该历史资源发放记录记录有用户成功获取资源的时间点以及资源的类型等。在竞猜信息与竞猜答案匹配时，若根据历史资源发放记录确定还未向任何用户发放过资源，则计算接收时间和资源发放活动的开启时间的第二时间差值，如果第二时间差值在资源发放时间间隔附近，则向第一用户发放资源，否则不向第一用户发放资源；目标服务端若根据历史资源发放记录确定已向某些用户发放过资源，则获取最近一次发放资源的时间，计算接收时间和最近一次发放资源的时间的第三时间差值，如果第三时间差值在资源发放时间间隔附近，则向第一用户发放资源，否则不向第一用户发放资源。

通过上述实施例可以看出，除非用户(管理员)配置了某场资源发放活动某个资源开场多久后才有机会被抽中，否则资源的发放概率是“均匀”贯穿整个资源发放活动的，即各个资源的发放概率从一开始到最终的活动结束都是“均衡”的，不会出现资源一下子发放完毕的情况。

在一个实施例中，向第一用户发放资源之后，还包括：

s440、将对应的资源发放信息持久化后写入数据库。

资源发放信息是确定可以向第一用户发放资源后具体给第一用户发放的资源信息，以抽奖为例，资源发放信息为中奖用户的中奖信息。数据持久化可以通过现有技术中已有的方式实现。可选的，数据库为mysql(关系型数据库管理系统)，另外，数据库具有主备同步。应当理解，本发明并不对数据库的类型和数量等进行限定。

s450、若资源发放信息成功写入，反馈资源发放信息。

为了保证数据的准确性，一场资源发放活动中，一般资源数目是远小于参与资源发放活动的用户数的，那么只在确定要进行资源发放的情况下持久化资源发放信息到数据库，写入数据库成功后，才返回客户端资源发放信息，这样即使服务存在宕机，也能从数据库中获取到正确的历史数据。在返回资源发放信息时可以采用广播的形式，广播给直播间所有用户，中奖者自己即能实时在客户端看到全部中奖信息，也能看到本次抽奖活动自己的中奖物品。

目前市场上一般会基于限流削峰结合各环节的性能优化实现资源发放，面向特定的平台或者活动，不能灵活定制，迁移至直播间中无法满足丰富玩法的需要。资源发放活动的开启也很难做到用户自己随意配置开启，主要是官方运营活动方式等。在直播领域泛娱乐的强互动情景下，很难满足用户需要。因此，本发明实施例除了合理优化发奖逻辑之外，还面向直播领域，提供了一种可于各个独立直播间随意开启，支持灵活配置资源发放信息的资源发放方法，下面进行详细介绍。

在一个实施例中，接收直播间中参与资源发放活动的第一用户输入的资源发放请求之前，还包括：

s405、接收直播间中级别权限为管理员的第二用户配置的资源发放活动的活动信息，其中，活动信息包括竞猜答案。

第二客户端为管理员所用的客户端。可选的，将直播间中的用户分为了两种角色，一种是管理员，一种是普通用户。管理员和普通用户均可参与资源发放活动，但是管理员具有配置、开启、停止资源发放活动的权限。管理员分为直播间主人(即主播)和一些普通管理员，主播可以赋予其他用户管理员权限。管理员和普通用户均具有抽奖、查看全部抽奖结果等权限。

每个管理员可以配置很多资源发放活动的活动信息。可选的，每个资源发放活动的活动信息包括活动名称、资源名称、资源总数量、竞猜答案和资源发放持续时间等等。

可选的，直播间信息包括直播间id，也即是频道id。用户信息包括用户id，例如账户名等，用来指明是哪个用户发起了什么请求，方便之后其他可能的业务逻辑处理。

在需要开启资源发放活动时，管理员配置该资源发放活动的活动信息，那么客户端即会将该资源发放活动的活动信息发送给目标服务端。

s406、根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识。

目标服务端根据接收到的资源发放活动的活动信息生成配置信息，例如，每个资源发放活动的活动信息包括活动名称、资源名称、资源总数量、竞猜答案和资源发放持续时间等等，那么目标服务端生成的配置信息包括活动名称对应的资源发放配置id、资源名称对应的资源id、资源总数量num、竞猜答案和资源发放持续时间等等。活动标识，即活动id，又称之为局次id，可记为actid，用于唯一标识每一局活动，即每局活动都分配一个活动标识。

s407、向直播间中的各个用户广播活动标识对应的资源发放活动。

得到该活动标识对应的配置信息后，目标服务端向直播间中各个用户广播该资源发放活动，直播间中的各个用户即可以参与该资源发放活动。

通过上述方式，管理员可以在直播频道内多次开启同一配置信息，每次开启会生成对应的局次id(即活动id)，开启抽奖之后，各局次之间的资源发放信息均分开，互相隔离。每个频道可以配置不同资源发放方式，管理员可以随时随地开启资源发放活动。可以在顶级频道开启抽奖，也可以在具体的子频道里面开启抽奖活动，互相无感知，只有进入具体直播间才能参与该直播间的抽奖局次。配置信息包含的具体内容均可以灵活设置。

本发明实施例的发放资源的方法还可以实现限流，限流在于防刷与高峰限流，可以在接入服务中安装防刷安全模块，同时在产品层面限制用户，比如每个用户每分钟只能摇一次奖。这样就大大降低了非法攻击，降低了并发量。

基于同一发明构思，本发明还提供一种发放资源的装置，下面结合附图对本发明装置的具体实施方式进行详细介绍。

如图9所示，在一个实施例中，一种发放资源的装置，包括：

资源发放请求接收模块410，用于接收直播间中参与资源发放活动的第一用户输入的资源发放请求，其中，资源发放请求中包括第一用户输入的竞猜信息；

判断模块420，用于判断竞猜信息与预先存储的资源发放活动的配置信息中所包含的竞猜答案是否匹配；

资源发放模块430，用于在匹配时，向第一用户发放资源。

在一个实施例中，配置信息还包含资源总数量和资源发放持续时间；资源发放模块430用于执行以下操作：

计算记录的资源发放请求的接收时间与资源发放活动的开启时间的第一时间差值；

若第一时间差值与整数倍的资源发放时间间隔之间的差值小于预设阈值，向第一用户发放资源，其中，资源发放时间间隔为资源发放持续时间与资源总数量的比值。

在一个实施例中，资源发放模块430计算记录的资源发放请求的接收时间与资源发放活动的开始时间的第一时间差值之后，还用于在差值大于等于预设阈值时，禁止向第一用户发放资源。

在一个实施例中，还包括与资源发放请求接收模块410相连的资源发放活动开启模块，用于执行以下操作：

接收直播间中级别权限为管理员的第二用户配置的资源发放活动的活动信息，其中，活动信息包括竞猜答案；

根据资源发放活动的活动信息生成资源发放活动的配置信息，并为资源发放活动分配活动标识；

向直播间中的各个用户广播活动标识对应的资源发放活动。

在一个实施例中，资源发放模块430向第一用户发放资源之后，还包括：

将对应的资源发放信息持久化后写入数据库；

若资源发放信息成功写入，反馈资源发放信息。

本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任意一项的发放资源的方法。其中，存储介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、cd-rom、和磁光盘)、rom(read-onlymemory，只读存储器)、ram(randomaccessmemory，随即存储器)、eprom(erasableprogrammableread-onlymemory，可擦写可编程只读存储器)、eeprom(electricallyerasableprogrammableread-onlymemory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，存储介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。可以是只读存储器，磁盘或光盘等。

本发明实施例还提供一种计算机设备，计算机设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现上述任意一项的发放资源的方法。

图10为本发明计算机设备的结构示意图，包括处理器520、存储装置530、输入单元540以及显示单元550等器件。本领域技术人员可以理解，图10示出的结构器件并不构成对所有计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件。存储装置530可用于存储应用程序510以及各功能模块，处理器520运行存储在存储装置530的应用程序510，从而执行设备的各种功能应用以及数据处理。存储装置530可以是内存储器或外存储器，或者包括内存储器和外存储器两者。内存储器可以包括只读存储器、可编程rom(prom)、电可编程rom(eprom)、电可擦写可编程rom(eeprom)、快闪存储器、或者随机存储器。外存储器可以包括硬盘、软盘、zip盘、u盘、磁带等。本发明所公开的存储装置包括但不限于这些类型的存储装置。本发明所公开的存储装置530只作为例子而非作为限定。

输入单元540用于接收信号的输入，以及接收用户输入的资源发放相关请求。输入单元540可包括触控面板以及其它输入设备。触控面板可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板上或在触控面板附近的操作)，并根据预先设定的程序驱动相应的连接装置；其它输入设备可以包括但不限于物理键盘、功能键(比如播放控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。显示单元550可用于显示用户输入的信息或提供给用户的信息以及计算机设备的各种菜单。显示单元550可采用液晶显示器、有机发光二极管等形式。处理器520是计算机设备的控制中心，利用各种接口和线路连接整个电脑的各个部分，通过运行或执行存储在存储装置530内的软件程序和/或模块，以及调用存储在存储装置内的数据，执行各种功能和处理数据。

在一实施方式中，计算机设备包括一个或多个处理器520，以及一个或多个存储装置530，一个或多个应用程序510，其中一个或多个应用程序510被存储在存储装置530中并被配置为由一个或多个处理器520执行，一个或多个应用程序510配置用于执行以上实施例的发放资源的方法。

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

应该理解的是，在本发明各实施例中的各功能单元可集成在一个处理模块中，也可以各个单元单独物理存在，也可以两个或两个以上单元集成于一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

以上仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。