一种红包实时派发的方法、装置、系统及存储介质与流程

本发明涉及数据处理领域，尤其涉及一种红包实时派发的方法、装置、系统及存储介质。

背景技术：

互联网电商中比较火热的秒杀(or抢红包)活动，这类红包实时派发活动的特点是：

1、红包发行预算有限，不能出现超发(资损)。

2、每次发放红包的金额不确定(由客户端指定，通常指活动系统)。

3、瞬间并发量特别大，如整点抢红包。

4、某些场景实时性要求高，需实时返回处理结果(因活动有许多规则，异步处理不一定能成功发放)。

但由于秒杀活动在线流量非常大，访问人数多访问量大，需要支持高并发量；现有技术的做法是前端进行限流，web服务层进行流量控制或者通过排队处理，保证同时操作预算的流量在可支持范围内；将预算缓存到redis缓存，利用redis的原子自增操作(事物特性)保证不超发。

然而，在上述现有技术方案中，活动的总预算额是存在单个缓存节点中，整个系统吞吐量受单个节点实例瓶颈影响，控制并发数不能满足实时性要求高的场景，用户需要排队等红包的派发结果，因此用户体验不是很好；

因此如何能够同时满足，保证预算安全(不出现超发)并且提高系统的并发处理能力，是一个亟需解决的问题。

技术实现要素：

本发明的主要目的在于提供一种红包实时派发的方法，旨在提高系统的并发处理能力，同时保证系统的实时性和预算扣减的准确性。

为实现上述目的，为实现上述目的，本发明提供一种红包实时派发的方法，所述红包实时派发方法包括以下步骤：

创建活动时，将活动总预算拆分成n份节点预算额，将n份节点预算额分配到各redis缓存实例中的预算节点，并将各节点预算额保存到第一数据库；其中，各redis缓存实例分别具有一个预算节点，所述预算节点还包括已发放额；

在接收用户设备发送的与所述活动对应的抢红包请求时，轮询本地内存中的预算节点路由表中的各预算节点状态，以选取一个可用状态的redis缓存实例中的预算节点作为预算扣减节点，将所述抢红包请求关联到所述预算扣减节点；其中，所述预算节点路由表记录各预算节点状态；

根据所述预算扣减节点中的节点预算额生成红包，将所述红包的金额累加到所述已发放额；

当累加后的已发放额满足预设条件时，将所述红包派发至与所述抢红包请求对应的用户设备，并将所述累加后的已发放额以及与所述红包对应的派发记录保存到第二数据库。

优选地，所述当检查到累加后的已发放额满足预设条件时，所述当累加后的已发放额满足预设条件时，将所述红包派发至与所述抢红包请求对应的用户设备之前，所述方法还包括：

检查到累加后的已发放额小于所述预算扣减节点的节点预算额时，，执行将所述红包派发至与所述抢红包请求对应的用户设备的步骤；

或

检查到所述预算扣减节点需进行预算碎片整理，或累加后的已发放额不小于所述预算扣减节点的节点预算额时时，将所述预算扣减节点状态设置为不可用；

将所述预算扣减节点中的剩余金额转移到所述第一预设预算节点中，所述剩余金额由所述节点预算额与所述已发放额生成；

返回到所述轮询本地内存中的预算节点路由表中的各预算节点状态的步骤，以获取一个可用状态的预算节点作为新的预算扣减节点，直至检查到所述累加后的已发放额小于所述新的预算扣减节点的节点预算额时，，执行将所述红包派发至与所述抢红包请求对应的用户设备的步骤。

优选地，所述将所述预算扣减节点中的剩余金额转移到所述第一预设预算节点中，具体包括：

从各redis缓存实例中确定所述第一预设预算节点，将所述预算扣减节点中的剩余金额转移到所述第一预设预算节点中；

当检测到所述第一预设预算节点中的节点预算额发生变化时，将所述预算节点路由表中与所述第一预设预算节点对应的预算节点状态设置为可用状态。

优选地，在所述根据所述抢红包请求轮询本地内存中的预算节点路由表之前，所述方法还包括：

在首次接收与所述活动对应的抢红包请求时，根据与所述redis缓存实例中的信息在本地内存中生成所述预算节点路由表。

优选地，所述将本次派发的红包的金额保存到所述后台数据库之后，所述方法还包括：

当所述后台数据库中的活动总预算增加时，对所述redis缓存中的活动总预算、以及所述redis缓存实例中的节点预算额进行更新；

在应用服务器接收到新的抢红包请求时，将更新后的所述redis缓存中的活动总预算与所述预算节点路由表中的活动总预算进行比较，当比较结果为不同时，对所述预算节点路由表中的活动总预算进行更新，并将所述预算节点路由表中的各预算节点状态设置为可用状态。

优选地，所述根据所述预算扣减节点中的节点预算额生成红包之前，所述方法还包括：

当所述redis缓存出现失效时，从所述第一数据库及所述第二数据库中重新加载与所述失效信息对应的预算节点信息。

优选地，所述应用服务器接收用户设备发送的请求之前，所述在接收用户设备发送的与所述活动对应的抢红包请求时之前，所述方法还包括：

在所述抢红包请求的流量超过预设限制流量时，对后续的抢红包请求进行限制。

此外，为实现上述目的，本发明还提出一种红包实时派发装置，所述红包实时派发装置包括：处理器，存储器及存储在所述存储器上并可在所述处理器上运行的红包实时派发程序以及预算节点路由表；所述预算节点路由表用于从各redis缓存实例中读取多个预算节点，并对所述多个预算节点进行路由选择；所述红包实时派发配置为实现如上文所述红包实时派发的方法的步骤。

此外，为实现上述目的，本发明还提出一种红包实时派发系统，所述系统包括：

如上文所述的红包实时派发装置、redis缓存集群、第一数据库以及第二数据库；所述redis缓存集群包括n个redis缓存实例，用于缓存预算节点中的节点预算额和已发放额，并根据所述已发放额周期性地对所述第一数据库进行更新；所述第二数据库用于对所述累加后的已发放额以及与所述红包对应的派发记录进行实时保存。

此外，为实现上述目的，本发明还提出一种存储介质，所述存储介质上存储所述红包实时派发程序，所述红包实时派发程序被处理器执行时实现如上文所述的红包实时派发的方法的步骤。

本发明在创建活动时，通过将活动总预算拆分成多份分配到各redis缓存实例中，每个redis缓存实例具有一个预算节点，应用服务器接收抢红包请求，轮询本地内存中的预算节点路由表以获取可用状态的预算扣减节点，将抢红包请求关联到预算扣减节点，并生成红包；利用redis的单线程串行特性，当红包的金额满足预设条件时，将红包派发至与所述请求对应的用户设备；当红包的金额不满足预设条件时，对预算扣减节点中的碎片进行转移，并寻找下一个预算节点进行处理。进而能够提高系统的并发处理能力，保证各个预算节点操作的同步性及实时性，同时又能保证预算扣减的准确性，进而提高了用户体验及保证资金安全。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的红包实时派发装置的结构示意图；

图2为本发明红包实时派发的方法第一实施例的流程示意图；

图3为本发明实施例活动预算管理的数据模型示意图；

图4为本发明红包实时派发的方法第二实施例的流程示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

参照图1，图1为本发明实施例方案涉及的硬件运行环境的红包实时派发装置的结构示意图。

如图1所示，该红包实时派发装置可以包括：处理器1001，例如cpu，通信总线1002、管理员接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。管理员接口1003可以连接包括显示屏(display)、输入单元比如键盘(keyboard)，可选管理员接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如wi-fi接口)。存储器1005可以是高速ram存储器，也可以是稳定的存储器(non-volatilememory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的红包实时派发装置结构并不构成对红包实时派发装置的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。所述红包实时派发装置可用是应用服务器。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、管理员接口模块以及红包实时派发程序。

在图1所示的应用服务器中，网络接口1004主要用于接收客户端发送的数据，还用于与后台数据库进行数据通信；管理员接口1003主要用于与服务器管理维护人员进行交互；本发明应用服务器中的处理器1001、存储器1005可以设置在红包实时派发装置中，所述红包实时派发装置通过处理器1001调用存储器1005中存储的红包实时派发程序，并执行以下操作：

创建活动时，将活动总预算拆分成n份节点预算额，将n份节点预算额分配到各redis缓存实例中的预算节点，并将各节点预算额保存到第一数据库；其中，各redis缓存实例分别具有一个预算节点，所述预算节点还包括已发放额；

在接收用户设备发送的与所述活动对应的抢红包请求时，轮询本地内存中的预算节点路由表中的各预算节点状态，以选取一个可用状态的redis缓存实例中的预算节点作为预算扣减节点，将所述抢红包请求关联到所述预算扣减节点；其中，所述预算节点路由表记录各预算节点状态；

根据所述预算扣减节点中的节点预算额生成红包，将所述红包的金额累加到所述已发放额；

当累加后的已发放额满足预设条件时，将所述红包派发至与所述抢红包请求对应的用户设备，并将所述累加后的已发放额以及与所述红包对应的派发记录保存到第二数据库。

进一步地，处理器1001可以调用存储器1005中存储的红包实时派发程序，还执行以下操作：

检查到累加后的已发放额小于所述预算扣减节点的节点预算额时，，执行将所述红包派发至与所述抢红包请求对应的用户设备的步骤；

或

检查到所述预算扣减节点需进行预算碎片整理，或累加后的已发放额不小于所述预算扣减节点的节点预算额时时，将所述预算扣减节点状态设置为不可用；

将所述预算扣减节点中的剩余金额转移到所述第一预设预算节点中，所述剩余金额由所述节点预算额与所述已发放额生成；

返回到所述轮询本地内存中的预算节点路由表中的各预算节点状态的步骤，以获取一个可用状态的预算节点作为新的预算扣减节点，直至检查到所述累加后的已发放额小于所述新的预算扣减节点的节点预算额时，执行将所述红包派发至与所述抢红包请求对应的用户设备的步骤。

进一步地，处理器1001可以调用存储器1005中存储的红包实时派发程序，还执行以下操作：

从各redis缓存实例中确定所述第一预设预算节点，将所述预算扣减节点中的剩余金额转移到所述第一预设预算节点中；

当检测到所述第一预设预算节点中的节点预算额发生变化时，将所述预算节点路由表中与所述第一预设预算节点对应的预算节点状态设置为可用状态。

进一步地，处理器1001可以调用存储器1005中存储的红包实时派发程序，还执行以下操作：

在首次接收与所述活动对应的抢红包请求时，根据与所述redis缓存实例中的信息在本地内存中生成所述预算节点路由表。

进一步地，处理器1001可以调用存储器1005中存储的红包实时派发程序，还执行以下操作：

当所述后台数据库中的活动总预算增加时，对所述redis缓存中的活动总预算、以及所述redis缓存实例中的节点预算额进行更新；

在应用服务器接收到新的抢红包请求时，将更新后的所述redis缓存中的活动总预算与所述预算节点路由表中的活动总预算进行比较，当比较结果为不同时，对所述预算节点路由表中的活动总预算进行更新，并将所述预算节点路由表中的各预算节点状态设置为可用状态。

进一步地，处理器1001可以调用存储器1005中存储的红包实时派发程序，还执行以下操作：

当所述redis缓存出现失效时，从所述第一数据库及所述第二数据库中重新加载与所述失效信息对应的预算节点信息。

进一步地，处理器1001可以调用存储器1005中存储的红包实时派发程序，还执行以下操作：

在所述抢红包请求的流量超过预设限制流量时，对后续的抢红包请求进行限制。

本发明通过将活动总预算拆分成多份分配到各redis缓存实例中，每个redis缓存实例具有一个预算节点，应用服务器接收抢红包请求，轮询本地内存中的预算节点路由表以获取可用状态的预算扣减节点，将抢红包请求关联到预算扣减节点，并生成红包；利用redis的单线程串行特性，当红包的金额满足预设条件时，将红包派发至与所述请求对应的用户设备；当红包的金额不满足预设条件时，对预算扣减节点中的碎片进行转移，并寻找下一个预算节点进行处理。进而能够提高系统的并发处理能力，同时又能保证实时性和预算扣减的准确性，进而提高了用户体验及保证资金安全。

参照图2，图2为本发明红包实时派发的方法的第一实施例的流程示意图。

在本实施例中，所述红包实时派发的方法包括以下步骤：

s01：创建活动时，将活动总预算拆分成n份节点预算额，将n份节点预算额分配到各redis缓存实例中的预算节点，并将各节点预算额保存到第一数据库；其中，各redis缓存实例分别具有一个预算节点，所述预算节点还包括已发放额；

需要说明的是，本实施例中，由于本方案是通过代码控制，程序代码在服务层，因此以应用服务器作为本实施例方法的执行主体；所述应用服务器其本身是分布式架构的，并可以水平扩展的；所述应用服务器位于服务层；后台数据库和redis缓存(包括各redis缓存实例)位于数据层；其中，所述redis缓存设于缓存服务器；以关系型数据库mysql作为所述后台数据库进行描述，mysql中会预先创建活动数据库(对应上述第一数据库)和用户账户数据库(对应下文第二数据库)，并以活动id＝1时对应某品牌a组织的红包派发活动为例进行说明。

可理解的是，系统为了支撑抢红包请求的流量，即mysql数据库需要支持高并发的增删改查，本实施例会预先创建两类数据库：活动数据库(对应第一数据库)和用户账户数据库(第二数据库)，其中用户账户数据库已分库分表(可以无限扩展的)，所述；参考图3中，所述活动数据库中会预先建立“活动信息表”，其中，所述“活动信息表”包括与活动id(比如该活动是某品牌a组织的，对应品牌a为id＝1)对应的活动总预算、预算节点数、第一预设预算节点信息、其他预算节点信息等与红包活动相关的信息，活动数据库还包括与该活动id对应的“预算节点信息表”。所述用户账户数据库会预先建立“派发流水表”，其中，“派发流水表”包括用户id(某个用户设备的账户的唯一标识)，本次派发金额、派发时间、派发的预算节点(用“活动id+budget+n”表示)，(预算节点)已发放额以及红包状态等其他与该用户id对应的红包派发金额相关记录信息。

一般情况下，缓存服务器中只创建一个redis缓存实例，即单个redis缓存预算节点，而本实施例是创建多个的redis缓存实例(每个redis实例具有一个拆分后的预算节点)；创建活动时，将活动预算拆分成n份摊派到n个redis缓存实例中，本实施例以n＝10为例；可理解的是，关系型数据库mysql的i/o流(输入/输出流)可接受上万次的读的请求，但是mysql的i/o流不能承受对一条记录上万次写的请求，mysql数据库更新同一条记录会有锁等待，无法支持高并发更新同一条记录；那么就需要在缓存服务器中配置比mysql更加灵活非关系型redis缓存数据库，redis为不同的数据定制不同的数据类型，所有数据都缓存在内存中，并发处理能力要高很多；

需要说明的是，在具体运行环境配置中，可以配置一个缓存服务器来创建多个redis缓存实例，也可以是配置多个缓存服务器来创建多个redis缓存实例，本实施例在此不以赘述。

在具体实现中，例如，当所述品牌a的活动审批通过时(即创建了id＝1的活动)，管理后台程序将活动信息保存到mysql数据库的“活动信息表”；将活动总预算拆分成n份(可参数配置，以n＝10为例)预算节点，并保存“预算节点信息表”；同时将活动信息和预算节点信息保存到redis缓存中；每个redis缓存实例对应一个“预算节点”，各预算节点具有对应的预算节点信息，所述预算节点信息又包括节点预算额和已发放额；最后将由所述“活动总预算”拆分后形成的n个的“节点预算额”存入mysql数据库“预算节点信息表”，并同步redis缓存“预算节点”，这样当redis缓存中的“预算节点”及“活动信息”丢失时，可直接从mysql数据库中“预算节点信息表”及“活动信息表”重新加载。

所述redis缓存中的“预算节点”至少包括“预算节点编号”、“节点预算额”以及“已发放额”；可理解的是，redis是一个key-value存储系统，它支持存储的value类型很多，包括string(字符串)、list(链表)、hash(哈希)、set(集合)、zset(有序集合)等，所述“预算节点编号”记录为：活动编号+budget+编号(1～10)，其中budget代表所述“节点预算额”(各个“预算节点”的“节点预算额”加起来为所述“活动总预算”)；比如所述品牌a的活动id＝1，系统将所述品牌a的“活动总预算”拆分成10份分配到10个redis缓存实例(对应10个“预算节点”)，那么分别用“预算节点编号”1+budget+1、1+budget+2、1+budget+3…….以及1+budget+10来表示这10个“预算节点”。

s10：应用服务器接收用户设备发送的与所述活动对应的抢红包请求；

需要说明的是，本实施例中，所述请求为某一用户设备例如客户端发送的一个抢红包请求，而在具体实现中在某一秒内肯定会出现大量不同的客户端(高并发量)发起的抢红包请求，应用服务器会根据各请求的访问时间的先后依次对每一个请求按照本实施例步骤s10到s60顺序进行处理；

在具体实现中，当所述品牌a的整点抢红包活动开始时，用户设备(客户端)向应用服务器发送的抢红包请求(对应图3中步骤1：)；应用服务器在接收到该请求后，会对该请求进行有效性检查(比如是否满足本次活动规则)，当所有检查都通过之后会执行步骤s20。

s20：轮询本地内存中的预算节点路由表中的各预算节点状态，以选取一个可用状态的redis缓存实例中的预算节点作为预算扣减节点，将所述抢红包请求关联到所述预算扣减节点；其中，所述预算节点路由表记录各预算节点状态；

可理解的是，当应用服务器首次接收与所述品牌a的整点抢红包活动对应的请求时，会对服务层的内存中的路由表中的缓存数据进行初始化操作，并根据步骤s01中与所述redis缓存实例对应的预算节点信息在本地内存中生成所述预算节点路由表，所述预算节点路由表记录各预算节点的节点状态集(可用状态以及不可以状态)，所述预算节点路由表用于从数据层的各redis缓存实例中读取多个预算节点(对应图3中的步骤2)，并对所述多个预算节点进行路由选择以寻找预算节点(对应图3中的步骤3)；即轮询本地内存中的预算节点路由表中的各预算节点状态，以从各redis缓存实例中获取一个可用状态的预算节点作为预算扣减节点(即对应图3中的当前使用节点)，将所述请求关联到获取到的预算扣减节点(当前使用节点)，以获取对应的预算节点信息。

在具体实现中，服务层的负载均衡采用轮询策略从本地内存的预算节点路由表中寻找可用状态的预算节点；获取到可用状态的预算节点后，更新当前游标(当前使用节点)指向下一个预算节点，本地路由表会记录上一次使用的是哪个节点，下次请求从下一个节点开始寻找。当某个预算节点预算不足(可以是预算为0，或不足本次发放金额、金额不足时产生碎片整理)时，更新本地路由表此节点状态为不可用(参加下文中的步骤s502)；

s30：根据获取到的预算扣减节点中的节点预算额生成红包,利用redis的单线程串行特性，将所述红包的金额累加到所述已发放额；

可理解的是，所述品牌a的整点抢红包活动，可以是客户端指定的活动，比如是某指定时刻抢指定面值的优惠券红包，比如整点时刻抢100台手机，又或者比如某时刻某个明星下红包雨，，本实施例在此不加以限制。

相应地，利用redis原子自增操作，同时利用redis的单线程串行特性，以保证不出现超发，保证各个预算节点操作的同步性。

s40：检查到累加后的已发放额小于所述预算扣减节点的节点预算额时，则执行步骤s60；

s501：检查到所述预算扣减节点需进行预算碎片整理，或累加后的已发放额不小于所述预算扣减节点的节点预算额时，将所述预算扣减节点状态设置为不可用；将所述预算扣减节点中的剩余金额转移到所述第一预设预算节点中，所述剩余金额由所述节点预算额与所述已发放额生成；

s502：返回到所述步骤s20，以获取一个可用状态的预算节点作为新的预算扣减节点，直至检查到所述累加后的已发放额小于所述新的预算扣减节点的节点预算额时，执行步骤s60；

s60：将所述红包派发至与所述抢红包请求对应的用户设备，并将所述累加后的已发放额以及与所述红包对应的派发记录保存到第二数据库。

可理解的是，系统会对响应抢红包请求并随即分配一个待发放的红包的金额,并将所述金额累加到已发放额，并判断累加后的已发放额是否满足预设条件(即是否超额)：

由于通过将活动总预算拆分成多份保存到多个redis缓存实例，因此redis缓存节点中会出现更多的预算碎片(内存碎片)；需要更多策略保证多个redis缓存实例的可行性；因此，当各预算节点所在redis缓存实例出现预算碎片时，系统需执行预算碎片转移整理；

所述预算扣减节点的节点预算额可以是该预算扣减节点的最大派发金额，在本实例中，以最大派发金额等于所述节点预算额为例；当已发放额小于所述节点预算额时，本次发放视为未超额；当已发放额不小于节点预算额时，或检测到所述预算扣减节点需要进行预算碎片整理时，本次发放视为超额；

在具体实现中，检查此次发放是否已经超额：如果未超额，则给用户派发红包，并将本次派发记录实时地保存到上述用户账户数据库的派发流水表中；

如果超额，则将此预算节点(预算扣减节点)的状态设置为不可用，可将此节点预算额清零，并将此预算节点的剩余金额转移到redis缓存中“活动信息”的第一预设预算节点，其中，所述剩余金额由所述节点预算额与所述已发放额生成，所述第一个预设预算节点为预先指定所述redis缓存中“活动信息”中的某个预算节点；最后返回步骤s20以继续寻找下一个可用状态的预算节点处理。

此外，在步骤s60之后，系统会对根据redis缓存(经过累加之后的)已发放额周期性地对所述活动数据库进行更新；在具体实现中系统中会有个定时作业，比如按照每一分钟对所述活动数据库进行一次更新。

通过本实例可在当前预算节点出现不足本次请求发放时，对该预算节点(所在redis实例)后续的派发红包操作进行限制，将抢红包请求队列中的剩余的每个请求按照时间先后顺序依次关联到其他可用状态的预算节点(所在redis实例)，如此便能实现这n个预算节点在短时间内同步处理客户端发送的抢红包请求，即提高了系统的并发处理能力，同时又能保证实时性和预算扣减的准确性，进而提高了用户体验及保证资金安全。

上述有益效果中提高系统并发处理能力可理解为：rediscluster(redis缓存集群)单节点(即一个redis缓存实例)的性能，大概在2万tps(transactionprocessingsystems事务处理系统)左右；如果采用单个节点保存预算，每秒处理能力受限于redis单个实例的处理能力，每秒处理能力必定不超过2万。若采用本实例提到的拆分预算方案，只要有多个redis缓存实例，拆分的预算节点均匀分布在这些实例中(每个实例缓存一个预算节点)，并发处理量就可以提高到n(实例个数)*m(单个实例的处理能力)，前提条件是web服务层的硬件设施能够支撑这么大的并发量(服务层一般可以做到水平扩展)。举例：假设一个redis实例的处理能力是1万qps(querypersecond，每秒查询率)，如果将预算拆分成10份，均匀分配到这10个实例中(一个实例保存一个预算节点)，那么系统处理能力就能达到10万qps。

上述有益效果提高了用户体验及保证资金安全可理解为：通过提高系统的并发处理能力，用户不用再排队等红包派发结果，那么用户可以更加快速的得到结果，进而提升了用户体验和公司形象，支付公司(所述品牌a)也不用担心因预算出现超发而产生资金损失的问题。

进一步地，上述将此预算节点的余额转移到redis缓存中“活动信息”的第一预设预算节点之后，更新本次请求的应用服务的本地路由表状态，再异步更新mysql数据库中“预算节点信息表”中的第一预设预算节点(比如编号为1+budget+1)的节点预算额。具体实现中，根据抢红包请求将所述redis缓存中“活动信息”中的第一预设预算节点的节点预算额与本地内存中的“预算节点路由表”中的第一预设预算节点的节点预算额进行比较，当比较结果不同时，更新本地内存中的预算节点路由表中的第一预设预算节点的节点预算额，同时将本地内存中的预算节点路由表中的第一预设预算节点设置为可用状态，再异步更新mysql数据库中“预算节点信息表”中的第一预设预算节点(比如编号为1+budget+1)的节点预算额。此外本实施例可通过分布式系统的可靠协调系统zookeeper实现服务层之间的数据同步，即通过zookeeper实现所述服务层应用服务器本地内存中的预算节点路由表之间的数据同步。通过更新转移预算碎片后的第一预设预算节点的状态，能够保证本次活动的活动总预算最大限度被使用。

参照图4，图4为本发明红包实时派发的方法的第二实施例的流程示意图，基于上述图2所示的实施例，提出本发明红包实时派发的方法的第二实施例。

本实施例中，所述并将本次派发的红包的金额记录到所述后台数据库之后，所述方法还包括：

s70：当所述后台数据库中的活动总预算增加时，对所述redis缓存中的活动总预算、以及所述redis缓存实例中的节点预算额进行更新；

可理解的是，当所述品牌a的活动追加预算审批通过时，会更新远程上述活动数据库中“活动信息表”中的活动总预算，更新redis缓存中“活动信息”；同时计算redis缓存中各节点预算额的追加额，然后更新上述活动数据库的“预算节点信息表”，并更新redis缓存中活动的各个预算节点信息；

s80：在应用服务器接收到新的抢红包请求时，将更新后的所述redis缓存中的活动总预算与所述预算节点路由表中的活动总预算进行比较，当比较结果为不同时，对所述预算节点路由表中的活动总预算进行更新，并将所述预算节点路由表中的各预算节点状态设置为可用状态。

通过本实施例可在活动预算追加时，对服务层的本地预算节点路由表进行同步维护，以使得本次红包派发活动持续进行。

进一步地，本实施例中，所述步骤s30之前，所述方法还包括：

s03：当所述redis缓存出现失效时，从所述第一数据库及所述第二数据库中重新加载与所述失效信息对应的预算节点信息。

在具体实现中，首先，活动总预算保存在“活动信息表”，活动的各个预算节点的预算额保存在“预算节点信息表”，redis缓存中的“预算节点”及“活动信息”丢失时，可直接从上述活动数据库中的“预算节点信息表”及“活动信息表”重新加载；然后，活动已发放额从用户账户数据库的“派发流水表”统计，所述“派发流水表”中包括记录发放的该预算节点以及当前已发放额(参考图3)；最后，redis缓存中该预算节点的“已发放额”能够根据“派发流水表”中的当前的已发放额快速统计出来，并能保证一个活动只要一个线程进行缓冲同步。

通过本实施例，在redis缓存中活动信息或预算节点信息丢失时，能够使得服务层通过一个线程操作从数据库重新加载redis缓存中的“预算节点”及“活动信息”，并且redis缓存中的已发放额能够根据派发流水表计算出来，进而能够实现对已失效的redis缓存进行自动恢复。

进一步地，本实施例中，所述在接收用户设备发送的与所述活动对应的抢红包请求时之前，所述方法还包括：

s02：在所述抢红包请求的流量超过预设限制流量时，对后续的抢红包请求进行限制。

可理解的是，由于“预算节点”及“活动信息”保存在redis缓存中，系统处理能力和预算拆分分数和应用服务器资源有关。当系统处理能力超过10万qps时，依然会受到缓存瓶颈的限制；因此，检测到所述请求的流量超过应用服务器系统整体支出的10万qps时，对所述请求进行限制，以确保服务器的稳定和安全。

通过本实施例，在外部请求访问流量出现暴增时，服务层对流量进行有效控制，保证了服务器的稳定性，进而保证用户体验。

此外，本发明还提出一种红包实时派发系统，所述系统包括：

如上文所述的红包实时派发装置、redis缓存集群、第一数据库以及第二数据库；所述redis缓存集群包括n个redis缓存实例，用于缓存预算节点中的节点预算额和已发放额，并根据所述已发放额周期性地对所述第一数据库进行更新；所述第二数据库用于对所述累加后的已发放额以及与所述红包对应的派发记录进行实时保存。

此外，本发明还提出一种存储介质，所述存储介质上存储所述红包实时派发程序，所述红包实时派发程序被处理器执行时实现如下操作：

创建活动时，将活动总预算拆分成n份节点预算额，将n份节点预算额分配到各redis缓存实例中的预算节点，并将各节点预算额保存到第一数据库；其中，各redis缓存实例分别具有一个预算节点，所述预算节点还包括已发放额；

在接收用户设备发送的与所述活动对应的抢红包请求时，轮询本地内存中的预算节点路由表中的各预算节点状态，以选取一个可用状态的redis缓存实例中的预算节点作为预算扣减节点，将所述抢红包请求关联到所述预算扣减节点；其中，所述预算节点路由表记录各预算节点状态；

根据所述预算扣减节点中的节点预算额生成红包，将所述红包的金额累加到所述已发放额；

当累加后的已发放额满足预设条件时，将所述红包派发至与所述抢红包请求对应的用户设备，并将所述累加后的已发放额以及与所述红包对应的派发记录保存到第二数据库。

所述红包实时派发程序被处理器执行时还实现如下操作：

检查到累加后的已发放额小于所述预算扣减节点的节点预算额时，执行将所述红包派发至与所述抢红包请求对应的用户设备的步骤；

或

检查到所述预算扣减节点需进行预算碎片整理，或累加后的已发放额不小于所述预算扣减节点的节点预算额时时，将所述预算扣减节点状态设置为不可用；

将所述预算扣减节点中的剩余金额转移到所述第一预设预算节点中，所述剩余金额由所述节点预算额与所述已发放额生成；

返回到所述轮询本地内存中的预算节点路由表中的各预算节点状态的步骤，以获取一个可用状态的预算节点作为新的预算扣减节点，直至检查到所述累加后的已发放额小于所述新的预算扣减节点的节点预算额时，，执行将所述红包派发至与所述抢红包请求对应的用户设备的步骤。

所述红包实时派发程序被处理器执行时还实现如下操作：

从各redis缓存实例中确定所述第一预设预算节点，将所述预算扣减节点中的剩余金额转移到所述第一预设预算节点中；

当检测到所述第一预设预算节点中的节点预算额发生变化时，将所述预算节点路由表中与所述第一预设预算节点对应的预算节点状态设置为可用状态。

所述红包实时派发程序被处理器执行时还实现如下操作：

在首次接收与所述活动对应的抢红包请求时，根据与所述redis缓存实例中的信息在本地内存中生成所述预算节点路由表。

进一步地，所述红包实时派发程序被处理器执行时还实现如下操作：

当所述后台数据库中的活动总预算增加时，对所述redis缓存中的活动总预算、以及所述redis缓存实例中的节点预算额进行更新；

在应用服务器接收到新的抢红包请求时，将更新后的所述redis缓存中的活动总预算与所述预算节点路由表中的活动总预算进行比较，当比较结果为不同时，对所述预算节点路由表中的活动总预算进行更新，并将所述预算节点路由表中的各预算节点状态设置为可用状态。

进一步地，所述红包实时派发程序被处理器执行时还实现如下操作：

当所述redis缓存出现失效时，从所述第一数据库及所述第二数据库中重新加载与所述失效信息对应的预算节点信息。

进一步地，所述红包实时派发程序被处理器执行时还实现如下操作：

在所述抢红包请求的流量超过预设限制流量时，对后续的抢红包请求进行限制。

本发明通过将活动总预算拆分成多份分配到各redis缓存实例中，每个redis缓存实例具有一个预算节点，应用服务器接收抢红包请求，轮询本地内存中的预算节点路由表以获取可用状态的预算扣减节点，将抢红包请求关联到预算扣减节点，并生成红包；利用redis的单线程串行特性，当红包的金额满足预设条件时，将红包派发至与所述请求对应的用户设备；当红包的金额不满足预设条件时，对预算扣减节点中的碎片进行转移，并寻找下一个预算节点进行处理。进而能够提高系统的并发处理能力，同时又能保证实时性和预算扣减的准确性，进而提高了用户体验及保证资金安全。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。本文中，术语“第一”、“第二”仅用于在描述不同的对象时对不同的对象进行区别，而不能理解为指示、暗示程序的顺序或者隐含指明所指示的技术特征的数量。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。