CN111782391A

CN111782391A - 资源分配方法、装置、电子设备和存储介质

Info

Publication number: CN111782391A
Application number: CN202010608198.7A
Authority: CN
Inventors: 岳晓东; 尹东洋; 朱方兴
Original assignee: Beijing Dajia Internet Information Technology Co Ltd
Current assignee: Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2020-06-29
Filing date: 2020-06-29
Publication date: 2020-10-16

Abstract

本公开关于资源分配方法、装置、电子设备和存储介质，应用于业务服务器，所述方法包括：根据接收到的用户发出的资源获取请求，查询业务服务器的本地缓存中记录的第一状态信息；若第一状态信息中包含待分配状态信息，则查询业务服务器对应的数据库缓存中记录的第二状态信息；若第二状态信息中不包含待分配状态信息，则向用户返回分配失败消息，若数据库中不存在处于待分配状态的目标资源，则向用户返回分配失败消息并将第一状态信息更新为不包含待分配状态信息，若数据库中存在处于待分配状态的目标资源，则通过数据库为用户分配处于待分配状态的目标资源，并根据返回的资源分配结果更新第一状态信息。

Description

资源分配方法、装置、电子设备和存储介质

技术领域

本公开涉及网络资源分配领域，尤其涉及资源分配方法、装置、电子设备和存储介质。

背景技术

随着互联网的普及，网络购票、网络竞拍、商品秒杀、促销抢购等资源分配事件越来越常见，这类事件通常具有高并发处理、高性能要求以及避免超卖等要求。

在相关技术中，资源分配系统通常包括业务服务器、数据库缓存和数据库(DB，DataBase)并由业务服务器分别查找数据库缓存和数据库中存储的秒杀对象的状态。但是，一方面，由于数据库缓存与业务服务器或数据库之间往往存在网络延时，因此请求响应速度较慢进而容易影响用户体验；另一方面，可能因数据库缓存与数据库之间的数据不一致而造成过多的资源获取请求穿透到数据库，从而导致读写能力有限的数据库强制丢弃请求甚至崩溃，系统稳定性较低。

发明内容

本公开提供了资源分配方法、装置、电子设备和存储介质，以至少解决相关技术中上述的技术问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提出一种资源分配方法，应用于业务服务器，所述方法包括：

根据接收到的用户发出的资源获取请求，查询所述业务服务器的本地缓存中记录的第一状态信息；

若所述第一状态信息中不包含待分配状态信息，则向所述用户返回分配失败消息，所述待分配状态信息用于表明所述业务服务器对应的数据库中存在处于待分配状态的目标资源，若所述第一状态信息中包含所述待分配状态信息，则查询所述业务服务器对应的数据库缓存中记录的第二状态信息；

若所述第二状态信息中不包含所述待分配状态信息，则向所述用户返回所述分配失败消息，若所述第二状态信息中包含所述待分配状态信息，则查询所述数据库中记录的所述目标资源的当前分配状态；

若所述数据库中不存在处于待分配状态的所述目标资源，则向所述用户返回所述分配失败消息并将所述第一状态信息更新为不包含所述待分配状态信息，若所述数据库中存在处于待分配状态的所述目标资源，则通过所述数据库为所述用户分配处于待分配状态的所述目标资源，并根据返回的资源分配结果更新所述第一状态信息。

可选的，所述查询所述业务服务器对应的数据库缓存中记录的第二状态信息，包括：向所述业务服务器对应的数据库缓存发送所述第一状态信息中包含的待分配资源信息，并接收所述数据库缓存返回的所述待分配资源信息对应的所述目标资源在所述第二状态信息中对应的分配状态；

所述查询所述数据库中记录的所述目标资源的当前分配状态，包括：向所述数据库发送所述第二状态信息中包含的待分配资源信息，并接收所述数据库返回的所述第二状态信息对应的所述目标资源的当前分配状态。

可选的，所述查询所述业务服务器对应的数据库缓存中记录的第二状态信息，包括：向所述业务服务器对应的数据库缓存发送查询请求，并接收所述数据库缓存返回的包含状态标识的缓存查询结果，所述状态标识为第一值时表明所述第二状态信息中不包含待分配状态信息，所述状态标识为第二值时表明所述第二状态信息中包含待分配状态信息；

所述查询所述数据库中记录的所述目标资源的当前分配状态，包括：向所述数据库发送查询请求，并接收所述数据库返回的包含状态标识的数据库查询结果；当所述状态标识为第三值时表明所述数据库中不存在处于待分配状态的所述目标资源，当所述状态标识为第四值时表明所述数据库中存在处于待分配状态的所述目标资源，且所述查询结果中包含所述数据库中记录的处于待分配状态的目标资源的资源信息。

可选的，还包括：

在所述第二状态信息与所述第一状态信息不相同的情况下，将所述第一状态信息更新至与所述第二状态信息相同。

可选的，所述通过所述数据库为所述用户分配处于待分配状态的所述目标资源，包括：

向所述数据库发送资源分配指令，以使所述数据库为所述用户分配处于待分配状态的所述目标资源；

接收所述数据库返回的资源分配结果。

可选的，还包括：

在所述资源分配结果表明存在所述目标资源被成功分配至所述用户的情况下，向所述用户返回分配成功消息；否则，

在所述资源分配结果表明不存在所述目标资源被成功分配至所述用户的情况下，向所述用户返回分配失败消息。

可选的，所述数据库生成的对应于所述资源分配结果的日志文件被日志解析器解析后得到状态变更信息，所述状态变更信息被所述数据库缓存用于更新自身记录的所述第二状态信息。

可选的，所述用户发送的所述资源获取请求满足下述至少之一的条件：

所述资源获取请求符合API(Application Programming Interface，应用程序接口)服务器按照请求发送的时间顺序进行的数量限制、所述用户已通过所述API服务器对资源获取权限进行的验证、所述资源获取请求已通过所述API服务器按照预设的风险控制规则对高风险请求进行的过滤处理、所述资源获取请求的请求信息和/或所述用户的用户信息已被所述API服务器进行备份。

可选的，所述数据库缓存包括分布式缓存。

根据本公开实施例的第二方面，提出一种资源分配系统，所述系统包括：

用户设备，用于向用户展示资源获取入口控件，在资源分配事件开始后，基于用户实施的预设触发操作向应用程序接口API服务器发送针对目标资源的资源获取请求；

API服务器，用于将接收到的所述资源获取请求转发至业务服务器；

业务服务器，所述业务服务器的本地缓存中保存有所述目标资源对应的第一状态信息，用于在接收到所述资源获取请求后，通过与数据库缓存、数据库和/或API服务器的配合，实现如权利要求1至9中任一项所述的资源分配方法；

数据库缓存，保存有所述目标资源对应的第二状态信息；

数据库，保存有所述目标资源的当前分配状态。

可选的，还包括：

所述API服务器接收到所述用户设备发送的签名申请；

在所述签名申请的接收时刻早于第一预设时刻的情况下，所述API服务器向所述用户设备返回无效签名；其中，所述第一预设时刻不晚于所述资源分配事件的开始时刻；

在所述签名申请的接收时刻不早于第一预设时刻的情况下，所述API服务器向所述用户设备返回对应于所述用户的用户信息的有效签名，以使所述用户基于所述有效签名参与所述资源分配事件。

可选的，还包括：

在当前时刻早于第二预设时刻时，所述API服务器不向所述用户设备下发所述资源分配事件对应的有效访问链接，或者向所述用户设备下发未被关联至所述资源分配事件的无效访问链接；其中，所述第二预设时刻不晚于所述资源分配事件的开始时刻；

在当前时刻不早于第二预设时刻时，所述API服务器向所述用户设备下发被关联至所述资源分配事件的有效访问链接，以使所述用户设备将所述有效访问链接关联至所述资源获取入口控件。

根据本公开实施例的第三方面，提出一种资源分配装置，应用于业务服务器，所述装置包括：

第一查询模块，被配置为根据接收到的用户发出的资源获取请求，查询所述业务服务器的本地缓存中记录的第一状态信息；

第二查询模块，被配置为若所述第一状态信息中不包含待分配状态信息，则向所述用户返回分配失败消息，所述待分配状态信息用于表明所述业务服务器对应的数据库中存在处于待分配状态的目标资源，若所述第一状态信息中包含所述待分配状态信息，则查询所述业务服务器对应的数据库缓存中记录的第二状态信息；

第三查询模块，被配置为若所述第二状态信息中不包含所述待分配状态信息，则向所述用户返回所述分配失败消息，若所述第二状态信息中包含所述待分配状态信息，则查询所述数据库中记录的所述目标资源的当前分配状态；

资源分配模块，被配置为若所述数据库中不存在处于待分配状态的所述目标资源，则向所述用户返回所述分配失败消息并将所述第一状态信息更新为不包含所述待分配状态信息，若所述数据库中存在处于待分配状态的所述目标资源，则通过所述数据库为所述用户分配处于待分配状态的所述目标资源，并根据返回的资源分配结果更新所述第一状态信息。

可选的，所述第二查询模块还被配置为：向所述业务服务器对应的数据库缓存发送所述第一状态信息中包含的待分配资源信息，并接收所述数据库缓存返回的所述待分配资源信息对应的所述目标资源在所述第二状态信息中对应的分配状态；

所述第三查询模块还被配置为：向所述数据库发送所述第二状态信息中包含的待分配资源信息，并接收所述数据库返回的所述第二状态信息对应的所述目标资源的当前分配状态。

可选的，所述第二查询模块还被配置为：向所述业务服务器对应的数据库缓存发送查询请求，并接收所述数据库缓存返回的包含状态标识的缓存查询结果，所述状态标识为第一值时表明所述第二状态信息中不包含待分配状态信息，所述状态标识为第二值时表明所述第二状态信息中包含待分配状态信息；

所述第三查询模块还被配置为：向所述数据库发送查询请求，并接收所述数据库返回的包含状态标识的数据库查询结果；当所述状态标识为第三值时表明所述数据库中不存在处于待分配状态的所述目标资源，当所述状态标识为第四值时表明所述数据库中存在处于待分配状态的所述目标资源，且所述查询结果中包含所述数据库中记录的处于待分配状态的目标资源的资源信息。

可选的，还包括：

第一更新模块，被配置为在所述第二状态信息与所述第一状态信息不相同的情况下，将所述第一状态信息更新至与所述第二状态信息相同。

可选的，所述资源分配模块包括：

指令发送单元，被配置为向所述数据库发送资源分配指令，以使所述数据库为所述用户分配处于待分配状态的所述目标资源；

结果接收单元，被配置为接收所述数据库返回的资源分配结果。

可选的，还包括：

成功返回模块，被配置为在所述资源分配结果表明存在所述目标资源被成功分配至所述用户的情况下，向所述用户返回分配成功消息；或者，

失败返回模块，被配置为在所述资源分配结果表明不存在所述目标资源被成功分配至所述用户的情况下，向所述用户返回分配失败消息。

所述资源获取请求符合所述API服务器按照请求发送的时间顺序进行的数量限制、所述用户已通过所述API服务器对资源获取权限进行的验证、所述资源获取请求已通过所述API服务器按照预设的风险控制规则对高风险请求进行的过滤处理、所述资源获取请求的请求信息和/或所述用户的用户信息已被所述API服务器进行备份。

可选的，所述数据库缓存包括分布式缓存。

根据本公开实施例的第四方面，提出一种电子设备，包括：

处理器；

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

其中，所述处理器被配置为执行所述指令，以实现如上述任一实施例所述的资源分配方法。

根据本公开实施例的第五方面，提出一种计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述任一实施例所述的资源分配方法。

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

根据本公开的实施例，业务服务器在接收到资源获取请求后，首先在本地缓存中快速查找第一状态信息，并在确定第一状态信息中不包含待分配状态信息的情况下，直接返回分配失败结果，而无需针对数据库缓存和数据库实施查询操作，不仅可以阻挡相应的资源获取请求穿透至数据库，而且相比于相关技术中直接查询数据库缓存的操作方式，能够有效地提升对资源获取请求的响应速度。以及，通过采用本地缓存、数据库缓存和数据库构成三级缓存，并且仅在上一级保存的状态信息中包含待分配状态信息时才对下一级缓存进行查询，而避免了大部分资源获取请求对数据库缓存的访问，在段时间内海量资源获取请求场景下极大的降低了数据库缓存的请求响应负荷。进一步的，前两级缓存的存在使得仅在资源分配事件前期的极少数资源获取请求能够穿透至数据库，而在后期能够阻挡大量无效请求穿透至数据库，从而极大地提升了数据库的稳定性。

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

附图说明

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

图1是相关技术中的一种资源分配系统网络架构示意图；

图2是根据本公开的实施例示出的一种资源分配方法流程图；

图3是根据本公开的实施例示出的一种秒杀业务处理系统示意图；

图4是根据本公开的实施例示出的一种秒杀业务处理方法流程图；

图5是根据本公开的实施例示出的一种秒杀业务处理装置的示意框图；

图6是根据本公开的实施例示出的一种电子设备的结构图。

具体实施方式

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

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

随着计算机网络及其相关应用的普及，网络购票、网络竞拍、商品秒杀、促销抢购等资源分配事件也愈发常见，作为网络资源分配的常见形式，这类资源分配事件通常由相应的资源分配系统实现。图1是相关技术中的一种资源分配系统网络架构示意图；如图1所示，用于控制执行资源分配的业务服务器以及用于保存数据库内目标资源状态信息的数据库缓存通常具有多个，各业务服务器分别接收到用户设备发送的资源获取请求后，在数据库缓存中保存的记录的第二状态信息中查询是否包含待分配状态信息：如果存在，则在数据库中尝试插入可分配的目标资源的分配记录，插入成功则表示为相应的用户分配目标资源成功即实现资源分配；如果不存在，则表示当前目标资源均已被分配完毕，即告知用户分配失败。

但是由于各数据库缓存与业务服务器或数据库之间通常距离较远，难以避免的会存在网络延时的问题，因此业务服务器接收请求后查询数据库缓存的速度较慢，从而导致请求响应速度慢进而影响用户的参与体验。而且，因为数据库缓存的数据更新不及时导致其与数据库之间的数据一致性较低，进而通过数据库缓存穿透到数据库的请求过多，易导致读写能力有限的数据库强制丢弃请求甚至崩溃，系统稳定性较低。

为解决上述技术问题，本公开实施例提供一种资源分配方法，该方法依赖于数据库、数据库缓存以及业务服务器的本地缓存实现。可由业务服务器控制执行，所述业务服务器可以为包含一独立主机的物理服务器，或者也可以为主机集群承载的虚拟服务器。上述前端程序可以是安装在用户设备中的APP(Application，应用程序)，可以是集成在浏览器中的H5(HTML5)页面，也可以是包含秒杀业务的小程序等。相应的，上述用户设备可以是手机、平板电脑、个人计算机、可穿戴设备、个人数字助理、云计算设备等电子设备。本公开对于前端程序及用户设备的具体形式并不进行限制。

图2是根据本公开的实施例示出的一种资源分配方法流程图；所述方法应用于服务器，可以包括：

步骤202，根据接收到的用户发出的资源获取请求，查询所述业务服务器的本地缓存中记录的第一状态信息。

在一实施例中，运行在用户设备中的前端程序可以在资源分配事件开始前向用户展示资源获取入口控件，在资源分配事件开始后，用户设备可以基于用户针对资源获取入口控件做出的预设触发操作向API服务器发送资源获取请求。可以理解的是，上述资源获取请求是针对资源分配事件的目标资源发出的，而且资源获取请求中可以携带所述用户的用户信息(实际上是所述前端程序当前登录的用户账号的账号信息)。另外，资源分配事件的全部目标资源可以全都相同(如都是同型号保温杯)，也可以不同(如保温杯、雨伞、手电筒三类)，对此本公开并不进行限制，但需要明确的是，本说明书方案中提及的目标资源应该被理解为上述保温杯等实体资源对应的虚拟资源，如上述实体资源的标识、编号、识别码等数字形式的资源信息，而非上述实体资源。

在一实施例中，用户发出的资源获取请求可以经过API的预处理后再发送至业务服务器，相应的，对于业务服务器来说，用户发出的资源能获取请求可以满足一个或多个条件。例如，API服务器可以对接收到的多个资源获取请求按照预设数量进行数量限制，即因为服务器接收到的资源获取请求可以符合API服务器按照请求发送的时间顺序进行的数量限制。其中，上述预设数量可以根据实际业务情况或目标预先设置，如可以大于目标资源的总数量，可以等于目标资源的总数量、可以等于按照时间或请求发送方IP地址归属地等对全部目标资源进行划分后的部分目标资源的数量等，通过对资源获取请求进行数量限制，初步保证了业务服务器所接收资源获取请求与相应目标资源的数量相吻合，避免请求过多导致系统崩溃。例如，API服务器可以对接收到的资源获取请求进行资格验证，即上述用户已通过API服务器对资源获取权限进行的验证。如API服务器可以针对资源获取请求所对应用户的账号年限、会员等级、积分数量等至少之一的信息进行核验，当然也可以根据业务需求核验用户的其他相关信息，以保证业务服务器接收到的都是具有资源获取权限的用户发送的真实有效的资源获取请求，避免无效处理。又例如，API服务器可以针对接收到的资源获取请求进行风控过滤，即业务服务器接收到的资源获取请求已通过所述API服务器按照预设的风险控制规则对高风险请求进行的过滤处理。如AIP服务器可以根据请求IP地址、用户账号活跃度、账号开通时长、同一设备请求发送数量或间隔时间、收货地址等不同维度的至少一条信息预先指定相应的风控规则，并在接收到用户发送的资源获取请求后按照该风控规则对请求进行过滤处理，以便滤除其中不符合正常请求条件的非法请求，从而有效避免黑产盗刷。再例如，API服务器可以针对接收到的资源获取请求进行信息备份，即业务服务器接收到的资源获取请求的请求信息及所述用户的用户信息已被所述API服务器进行备份。通过对资源获取请求的请求信息和/或相应的用户信息进行备份，便于在资源分配事件结束后对复盘事件过程或验证事件效果。当然，API服务器对接收到的资源获取请求可以采用上述一种或多种方式进行预处理，当然也可以根据实际情况采用其他预处理方式，而且不同处理方式的顺序可以根据实际情况进行调整，例如在先进行风控过滤再进行信息备份的情况下，可以备份全部请求的相关信息，也可以仅备份过滤后的合法请求或非法请求的相关信息，本公开对此并不进行限制。

对于资源分配事件的目标资源，业务服务器的本地缓存、数据库缓存和数据库分别保存有全部目标资源的状态信息，相应的、依次记作第一状态信息、第二状态信息和第三状态信息。其中，上述业务服务器可以为独立的服务器，也可以是用于实现业务功能的服务器集群，本公开对此并不进行限制。相应的，上述业务服务器的本地缓存可以为业务服务器的内部存储设备，如随机存取存储器(SRAM)或只读存储器(ROM)等，也可以为本地外接存储设备，如固态硬盘，机械硬盘等。本公开对于数据库缓存与数据库之间的物理位置并不进行限制，数据库缓存可以为数据库本身的缓存组件，也可以为分布式缓存，如Redis缓存系统、MemCache缓存系统或SSDB缓存系统等。由于业务服务器、数据库缓存和数据库三者之间可能因网络带宽、网络负荷及请求处理能力等因素导致各自所保存的目标资源状态数据可能并不一致，例如，若业务服务器与数据库之间的网络延时大于数据库缓存与数据库之间的网络延时，则在数据库中的全部目标资源均以分配完毕的情况下，很有可能数据库缓存中的第二状态信息已经按照数据库进行了更新(第二状态信息中不存在待分配状态信息)，但业务服务器本地缓存中的第一状态信息尚未及时更新(第一状态信息中存在待分配状态信息)，则此时查询业务服务器的本地缓存发现第一状态信息中包含待分配状态信息后，若不进一步查询数据库缓存则可能导致请求穿透到数据库，但此时数据库中的目标资源已经分配完毕，因此会出现请求报错从而影响用户体验，所以本公开方案依次对第一状态信息、第二状态信息和第三状态信息进行查询，以保证请求的有效响应。

步骤204，若所述第一状态信息中不包含待分配状态信息，则向所述用户返回分配失败消息，所述待分配状态信息用于表明所述业务服务器对应的数据库中存在处于待分配状态的目标资源，若所述第一状态信息中包含所述待分配状态信息，则查询所述业务服务器对应的数据库缓存中记录的第二状态信息。

步骤206，若所述第二状态信息中不包含所述待分配状态信息，则向所述用户返回所述分配失败消息，若所述第二状态信息中包含所述待分配状态信息，则查询所述数据库中记录的所述目标资源的当前分配状态。

在一实施例中，业务服务器可以向业务服务器对应的数据库缓存发送第一状态信息中包含的待分配资源信息，并接收数据库缓存返回的待分配资源信息对应的目标资源在第二状态信息中对应的分配状态；进一步的，业务服务器可以向数据库发送第二状态信息中包含的待分配资源信息，并接收数据库返回的第二状态信息对应的目标资源的当前分配状态。此时，业务服务器有针对性的向数据库缓存中发送第一状态信息中的待分配资源信息，并向数据库缓存发送第二状态信息中的待分配资源信息，相对于发送全部目标资源的资源信息，发送的数据量更少，因此不需要被查询方遍历所有目标资源的状态信息，一定程度上提高了查询速度并减少了网络压力。而且能够准确获知待分配资源信息对应的目标资源在第二状态信息和第三状态信息中对应的分配状态，即获知第一状态信息表明处于待分配状态的目标资源在第二状态信息中的分配状态，以及第一状态信息和第二状态信息同时表明处于待分配状态的目标资源在第三状态信息中的分配状态(即数据库中保存的真实分配状态)。

在一实施例中，在第二状态信息与第一状态信息不相同的情况下，可以将第一状态信息更新至与第二状态信息相同。第二状态信息与第一状态信息不相同，即表明本地缓存与数据库缓存之间存在数据延迟，因为先查询本地缓存后查询数据库缓存，因此进一步表明本地缓存的更新慢于数据库缓存，因此可以将本地缓存记录的第一状态信息更新至与数据库缓存中记录的第二状态信息相同，从而实现本地缓存与数据库缓存所保存状态信息的一致性。当然，由于实际物理距离、网络带宽及业务负载等的不同，也可能是第一状态信息的更新快于第二状态信息导致第二状态信息与第一状态信息不相同，因此也可以根据业务特点及历史延时等实际情况更新第二状态信息至与第一状态信息相同。

在另一实施例中，业务服务器可以向所业务服务器对应的数据库缓存发送查询请求，并接收数据库缓存返回的包含状态标识的缓存查询结果，其中状态标识为第一值时表明第二状态信息中不包含待分配状态信息，状态标识为第二值时表明第二状态信息中包含待分配状态信息；进一步的，业务服务器可以向数据库发送查询请求，并接收数据库返回的包含状态标识的数据库查询结果；当该状态标识为第三值时表明数据库中不存在处于待分配状态的目标资源，当状态标识为第四值时表明数据库中存在处于待分配状态的目标资源，且查询结果中包含数据库中记录的处于待分配状态的目标资源的资源信息。因为目标资源被保存在数据库中并且为不同用户分配的目标资源并不具有针对性，因此针对一个资源获取请求只需要获知知否存在可分配的目标资源，而并不需要知晓具体是哪个目标资源可分配。所以查询第一状态信息和第二状态信息只需要获知数据库中是否保存在可分配目标资源即可，业务服务器向数据库缓存发送的查询请求仅用于使数据库缓存执行查询操作，而其中并不携带第一状态信息表明的处于待分配状态的目标资源的对象信息，相应的，被数据库缓存返回的查询结果也仅包含不存在(或存在)待分配状态的目标资源对应的第三值(或第四值)，而不包含第三状态信息表明的处于待分配状态的目标资源的对象信息，因此能够减少上述查询请求和缓存查询结果的数据量，进而降低秒杀过程中的网络传输压力，进一步保证了系统稳定。上述第一值至第四值的具体取值可以根据实际场景选择，只需保证第一值和第二值不同，且第三值和第四值不同即可，例如，第一值和第三值可以为“0”，第二者和第四值可以为“1”。

步骤208，若所述数据库中不存在处于待分配状态的所述目标资源，则向所述用户返回所述分配失败消息并将所述第一状态信息更新为不包含所述待分配状态信息，若所述数据库中存在处于待分配状态的所述目标资源，则通过所述数据库为所述用户分配处于待分配状态的所述目标资源，并根据返回的资源分配结果更新所述第一状态信息。

在一实施例中，业务服务器可以有多种方式通过数据库为用户分配处于待分配状态的目标资源。作为一示例性实施例，在数据库中存在处于待分配状态的所述目标资源的情况下，业务服务器可以先向数据库发送资源分配指令，以使数据库为用户分配处于待分配状态的目标资源，然后接收数据库返回的资源分配结果。此时，资源分配指令中可以包含处于待分配状态的目标资源的资源标识，从而数据库可以按照该资源标识将相应的目标资源分配至上述用户。此时在业务服务器确认数据库中存在待分配状态的目标资源的前提下将目标资源分配至数据获取请求对应的用户，保证了用户被分配到目标资源。

作为另一示例性实施例，可以由数据库在查询第三状态信息并确定存在处于待分配状态的所述目标资源的情况下，直接为用户分配处于待分配状态的目标资源。因为在上述资源分配场景下业务服务器通常会在短时间内接收到大量资源获取请求，因此在数据库确定存在处于待分配状态的所述目标资源后直接为用户分配目标资源，减少了向业务数据库返回查询结果的时间占用，避免了因返回查询结果可能导致的分配失败(在返回查询结果时目标资源被分配至其它请求对应的用户)。当然，该实施例中，无论分配成功还是失败，分配完成后数据库也可以业务服务器返回资源分配结果。

在上述两示例性实施例中，数据库也可以在处于待分配状态的所有目标资源中随机选择任一目标资源，并将其分配至上述用户。具体的，数据库可以在该目标资源对应的分配方信息处写入上述用户的用户信息，也可以在数据库本地保存的分配记录表中添加关于上述用户的分配表项，并相应地将待分配状态的目标资源的数量减少预设数量(即分配给用户的目标资源的数量，如1)。

进一步的，上述分配过程可能成功(即将至少一个目标资源分配至上述用户)，也可能失败(即未将任何目标资源分配至上述用户，如上述目标资源被分配至其他用户)。因此，为保证用户即使知晓资源获取结果，在上述分配结果表明存在目标资源被成功分配至用户的情况下，可以向用户返回分配成功消息；否则，在资源分配结果表明不存在目标资源被成功分配至用户的情况下，可以向用户返回分配失败消息。

在一实施例中，上述数据库生成的对应于资源分配结果的日志文件可以被日志解析器解析后得到状态变更信息，该状态变更信息被数据库缓存用于更新自身记录的第二状态信息。上述状态变更信息可以具有多种形式，在一示例性实施例中，数据库在增、删、改等操作后会产生包含用于更新数据库的结构化查询语句的日志文件，因此上述数据库的变更信息可以包括数据库的日志文件。在另一示例性实施例中，可以按照预设周期定期抽取数据库的数据，并对当次抽取到的数据与前次抽取的数据进行比对，从而确定出上述状态变更信息，以便及时知晓数据库中目标资源对应的第三状态信息的变化情况。可见，正是因为本地缓存记录的第一状态信息根据数据库的资源分配结果进行更新，数据库缓存记录的第二状态信息根据资源分配结果的日志文件进行更新，因此第一状态信息和第二状态信息的变化都晚于数据库中记录的第三状态信息的变化；进一步的，因为通常数据库缓存与数据库之间的网络延迟小于业务服务器的本地缓存与数据库之间的网络延迟，因此，本公开方案中对于状态信息的查询顺序依次为：第一状态信息、第二状态信息和第三状态信息，以通过尽量少的查询次数尽快获取针对待分配状态的目标资源的查询结果，从而提高资源分配的整体效率。

根据本公开的上述实施例，服务器在接收到任一资源获取请求后，首先在本地缓存中快速查找第一状态信息，然后在确定第一状态信息中包含待分配状态信息的情况下再去数据库缓存查询第二状态信息，进一步在确定第二状态信息中包含待分配状态信息的情况下再去数据库查找目标资源的分配状态。经过本地缓存、数据库缓存和数据库构成三级缓存，并且仅在上一级保存的状态信息中包含待分配状态信息时才对下一级缓存进行查询，而避免了大部分资源获取请求对数据库缓存的访问，在段时间内海量资源获取请求场景下极大的降低了数据库缓存的请求响应负荷。进一步的，前两级缓存的存在使得仅在资源分配事件前期的极少数资源获取请求能够穿透至数据库，而在后期能够阻挡大量无效请求穿透至数据库，从而极大地提升了数据库的稳定性。

相应的，本公开还了公开一种资源分配系统，该系统可以包括：

用户设备，可以向用户展示资源获取入口控件，并在资源分配事件开始后，基于用户实施的预设触发操作向应用程序接口API服务器发送针对目标资源的资源获取请求；API服务器，可以将接收到的资源获取请求转发至业务服务器；业务服务器，自身的本地缓存中保存有上述目标资源对应的第一状态信息，可以在接收到资源获取请求后，通过与上述数据库缓存、数据库和/或API服务器的配合，实现如上述图2及其对应任一实施例所述的资源分配方法；数据库缓存，保存有上述目标资源对应的第二状态信息；数据库，保存有上述目标资源的当前分配状态。

在一实施例中，在接收到用户设备发送的签名申请后，在签名申请的接收时刻早于第一预设时刻的情况下，上述API服务器可以向用户设备返回无效签名，以避免部分用户在资源分配之间开始前非法锁定事件入口；其中，第一预设时刻不晚于资源分配事件的开始时刻；在签名申请的接收时刻不早于第一预设时刻的情况下，API服务器可以向用户设备返回对应于上述用户的用户信息的有效签名，以使该用户基于上述有效签名参与上述资源分配事件。

在一实施例中，为实现在资源分配事件开始前对有效访问链接的隐藏和保护，并在一定程度上避免黑产盗刷，在当前时刻早于第二预设时刻时，API服务器可以不向用户设备下发资源分配事件对应的有效访问链接，或者，也可以向用户设备下发未被关联至资源分配事件的无效访问链接；其中，第二预设时刻不晚于资源分配事件的开始时刻。另外，为保证合法用户正常参与资源分配事件，在当前时刻不早于第二预设时刻时，API服务器可以向用户设备下发被关联至资源分配事件的有效访问链接，以使用户设备将有效访问链接关联至资源获取入口控件。

下面以资源分配事件为秒杀活动为例，结合图3所示的一种秒杀业务处理系统示意图及图4所示的一种秒杀业务处理方法流程图对上述资源分配系统及分配方法进行详细说明。由图3可见，该秒杀业务处理系统主要包括应用层、代理层、接入层、服务层和数据层。其中：

应用层用于为用户提供前端程序301，其中，前端程序301可以具有多种形式，包括但不限于APP、H5页面、小程序等。前端程序301安装在用户设备上，例如，同一台用户设备可以安装一个或多个前端程序301，一个前端程序301上可以登录一个或多个用户的用户账号，本公开对此并不进行限制，本公开关注的是一个前端程序301上登录的一个用户账号对应的一个秒杀请求。在秒杀活动开始前，前端程序301向用户展示并提供前端搭建模块305发送的前端服务，以向用户提供秒杀入口以及秒杀活动和/或秒杀对象的相关信息，以便用户通过秒杀入口参与秒杀活动。秒杀活动开始后，前端程序301将对应于用户秒杀操作的秒杀请求发送至代理服务器302。

代理层主要包括代理服务器302，用于将来自各用户设备(实际上是用户设备上安装的前端程序)的秒杀请求及其他相关信息转发至API服务器304，并将API服务器304返回的秒杀成功消息或秒杀失败消息转发至相应的用户设备。当然，代理服务器302还可以对转发进行控制和登记，并完成内容过滤、访问控制管理等多种功能。代理服务器302可以具有多种形式，例如可以为Nginx服务器，其具体工作方式可以参见相关技术中公开的内容，本公开对此并不进行限制。

接入层可以包括多个接入设备模块，如备份服务模块303、API服务器304以及前端搭建模块305等。

具体的，API服务器304可以用于接收代理服务器302转发的秒杀请求及相关信息，并将接收到的秒杀服务器返回的秒杀成功消息或秒杀失败消息发送至代理服务器302。

API服务器304还可以将接收到的所有秒杀请求发送至备份服务模块303，并由备份服务模块303对秒杀请求进行备份及分类、统计等相关处理，以便于秒杀结束后核查秒杀请求、复盘秒杀活动或验证活动效果。上述备份服务模块303可以具有多种形式，本公开对此并不进行限制，例如在为消息队列的形式的情况下，可以为Ksfka队列、MetaQ队列、ActiveMQ队列或HornetQ等。

前端搭建模块305在秒杀活动开始前，可以按照从API服务器304获取的活动类型、秒杀对象数量、秒杀对象详情等活动信息搭建前端服务，并将搭建完成的前端服务反馈至前端程序301，以使前端程序301向用户提供该前端服务，例如该前端服务可以为秒杀活动对应的秒杀界面以及相应入口链接及操作检测服务等。在秒杀活动开始后，可以将接收到的API服务器304返回的秒杀结果处理后发送至前端程序301以向用户展示。该前端搭建模块305可以包括Node.js。

接入层还可以包括CDN(Content Delivery Network，即内容分发网络)服务器306，CDN服务器306中保存有秒杀活动对应的静态资源，如秒杀页面对应的图片资源、HTML资源等，这部分数据以静态资源的形式保存在CDN服务器306中，并在秒杀活动开始前提供给前端程序301以向用户展示秒杀界面。通过分布式的内容分发网络保存并经过(多个)代理服务器302向不同的前端程序301分发静态资源，不仅有助于不同前端程序301均能够较快的获取静态资源，而且因为上述资源是预先保存的静态资源，因此进一步保证了自愿的快速分发，从而进一步提高资源分发效率并提升用户体验。

服务层可以包括秒杀服务相关的多个设备模块，如风控服务模块307、业务服务器308以及配置中心309等；数据层可以包括数据库缓存311、本地缓存312以及数据库314。

具体的，API服务器304可以将秒杀请求直接发送至业务服务器308，也可以将秒杀请求发送至风控服务模块307，以由风控服务模块307对秒杀请求进行风控过滤，并将通过验证的合法秒杀请求发送至业务服务器308。

秒杀活动开始前，活动管理人员可以通过配置中心309将秒杀活动相关的开始时刻、秒杀对象数量等活动信息配置在业务服务器308中，以便秒杀活动顺利开展。

服务器层还可以包括数据库操作组件310，该组件可以作为业务服务器308对数据库314的操作代理模块，直接执行对数据库314的查询、插入等数据操作。该数据库操作组件310可以为自定义的CacheSetter组件。

数据层可以包括业务服务器308的本地缓存311(保存有秒杀对象的第一状态信息)、保存有所有秒杀对象对应的第二状态信息的数据库缓存312、以及保存有所有秒杀对象对应的第三状态信息的数据库313。业务服务器308接收到API服务器304或风控服务模块307发送的秒杀请求后，可以与本地缓存311、数据库缓存312及数据库313相互配合实现本公开上述实施例所述的资源分配方法。具体的，数据库缓存312可以为分布式缓存，例如Redis缓存系统、MemCache缓存系统或SSDB缓存系统等。

数据层还可以包括日志解析器314，数据库313在分配目标资源后通常会生成相应的日志文件，日志解析器314可以解析该日志文件以获知数据库313内秒杀对象的状态变化(即第三状态信息的变化)，然后数据库缓存312可以基于该状态变化更新自身所保存的秒杀对象的状态信息(即第二状态信息)，使之与分配目标资源之后数据库313内秒杀对象的状态信息保持一致。具体的，针对不同形式的数据库313，相应的日志及日志解析器314也有所不同，在数据库313为MySQL数据库时，插入数据后会产生Binlog日志文件，相应的日志解析器314即为Binlog解析程序，如Maxwell、Canal或mysql_streamer等；在数据库313为Oracle数据库时，插入数据后会产生Redolog日志文件，相应的日志解析器314即为Redolog解析程序，如Oracle LogMiner等。进一步的，redolog日志文件可以为在线重做日志onlineRedo log files，也可以为归档重做日志Archive Redo log files。对于上述数据库313的类型及其所产生日志文件的种类，本公开并不进行限制。

上述秒杀业务处理系统的工作过程可以分为秒杀活动开始前和秒杀活动开始后两个阶段，下面结合图3按照时间顺序对两阶段进行说明：

1)秒杀活动开始前

1.1、前端程序展示活动详情

在秒杀活动开始前，前端程序301向前端搭建模块305发起活动渲染请求，前端搭建模块305接收到上述请求后，对从CDN服务器306获取到的静态数据进行渲染，并将生成的渲染视图数据返回至前端程序301，由前端程序301进行相应的视图展示。其中，上述静态资源可以为图片、文字、HTML数据、动画数据等多种形式，并以离线资源包的形式预存于CDN服务器306中。

为用户展示的秒杀界面中可以包括秒杀入口控件，如按钮、滑块等，在秒杀活动开始前秒杀入口空间处于非激活状态(此时该控件可以未被关联任何链接或者被关联至无效链接)，用户无法对其进行有效的触发操作(用户及时实施触发操作，也无法产生有效的秒杀请求)。

1.2、验证用户的活动参与资格

前端程序301向前端搭建模块305发起秒杀状态获取请求，该请求中可以携带前端应用的登录信息、用户账户信息等用户数据，前端搭建模块305在接收到该请求后向API服务器304提出验证请求，API服务器304在判断活动已开启(秒杀活动开始前的准备阶段，但秒杀并未真正开始)的情况下，基于上述用户相关信息验证用户的活动参与资格，由前端搭建模块305将API服务器304返回的活动参与资格验证结果转发至前端程序301。

另外，API服务器304还可以返回服务端时间，用于对展示界面进行时间校验，以便于后续验证用户合法性。

1.3、验证用户合法性

前端程序301通过代理服务器302向前端搭建模块305发起签名申请，API服务器304接收到前端搭建模块305转发的上述签名申请后，对用户进行风控过滤，如由API服务器304调用风控服务模块307对用户进行风险评估，具体的，可以结合用户账号的注册时间、用户设备的IP地址、GPS地址、设备标识号、登录模式(APP、小程序、H5页面等)、用户收件地址、用户请求频率等信息对该秒杀请求进行多维评估，以确定其为危险系数，在其危险系数满足相应的预设风险控制条件的情况下，放行或拦截该用户发出的秒杀请求，并对风险评估结果进行相应的记录存档。风险过滤实现了对秒杀请求的风险处理，有效避免了黑产等非法用户盗刷攫取秒杀对象。

在风控过滤证明用户合法的情况下，API服务器304判断签名申请的接收时刻是否早于第一预设时刻：在签名申请的接收时刻早于第一预设时刻的情况下，API服务器304可以向前端程序301返回无效签名；在签名申请的接收时刻不早于第一预设时刻的情况下，API服务器304向前端程序301返回针对用户的用户信息的有效签名，以使用户基于有效签名参与秒杀活动。其中，可以利用从配置中心309获取的秒杀活动配置数据结合用户信息对用户进行有效签名。通过在预设时刻前向用户下发无效签名，能够降低秒杀入口对应的真实链接被泄露的风险，进一步防止黑产等非法用户盗刷攫取秒杀对象。

另外，在当前时刻早于第二预设时刻时，API服务器304可以不向前端程序301下发秒杀活动对应的有效访问链接，或者向前端程序301下发未被关联至所述资源分配事件的无效访问链接；其中，第二预设时刻不晚于秒杀活动的开始时刻；在不早于第二预设时刻时，API服务器304向前端程序301下发秒杀活动对应的真实链接，以使前端程序301将真实链接关联至秒杀入口控件。

前端搭建模块305向前端程序301返回有效签名和有效访问链接。

2)秒杀活动开始后

前端程序301通过前端搭建模块305向API服务器304提交秒杀请求。API服务器304对秒杀请求进行预处理。

具体的，可以先验证签名是否有效，活动时间是否有效以及是否具有合法的参与资格。

还可以对秒杀请求进行数量限制，在预设时长内发送至业务服务器308的秒杀请求数量应该不大于预设数量，如预设业务服务器的QPS(Queries-Per-Second，每秒查询率)为10000，则在1s内第10000个之后的其它请求在这一秒内不会发送至业务服务器，以强制控制业务服务器的请求访问量，避免请求瞬间暴增可能导致的业务瘫痪。

还可以进行信息备份，由API服务器304将接收的所有秒杀请求进行备份，备份过程中可以仅将秒杀请求进行备份保存，也可以将秒杀请求及其对应的用户名、用户设备的IP地址、用户收件地址、用户请求频率、用户历史活动热度等相关信息关联保存，以便于秒杀活动结束后基于上述信息识别秒杀请求的真实性，进而对秒杀活动的活动效果进行验证。

至此，合法业务服务器308将合法的秒杀请求转发至应用服务器308，应用服务器308通过与数据库操作模块310、本地缓存311、数据库缓存312、数据库313以及日志解析器314的配合实现上述资源分配方法。

下面结合图4所示的一种秒杀业务处理方法流程图，对秒杀过程进行详细说明。所述方法应用于业务服务器，包括：

步骤402，接收用户设备发出的秒杀请求。

秒杀活动开始后，用户通过触发前端设备上展示出的秒杀入口参与秒杀活动，用户设备生成相应的秒杀请求，该秒杀请求可以经过代理服务器和API服务器发送至业务服务器。可以理解的是，业务服务器接收到的该秒杀请求可以是经过API服务器预处理的合法的秒杀请求，具体的预处理过程可参见前文记载，本实施例不再赘述。

在一实施例中，上述秒杀请求中携带有发送该秒杀请求的前端程序的当前登录账户对应的账户标识(即为用户标识)和/或该请求的唯一请求标识。接收到秒杀请求后，业务服务器基于该秒杀请求确定上述标识，以便后续基于上述标识返回相应的秒杀成功消息或秒杀失败消息。

步骤404，查询本地缓存，确定是否存在待分配秒杀对象。

业务服务器可以在自身的本地缓存中查询当前各秒杀对象的状态，并基于查询结果确定当前是否存在处于待分配状态的秒杀对象。

在一实施例中，上述第一状态信息可以包括各秒杀对象的标识(如编号、分组等)与其当前状态的映射关系，此时，业务服务器可以按照各秒杀对象的标识依次查询各秒杀对象的当前状态。

在另一实施例中，上述第一状态信息可以包括各秒杀对象的对象信息与其当前状态的映射关系，同时本地缓存中还保存有当前处于未分配状态的秒杀对象的第一待分配数量。此时业务服务器可以直接查看第一待分配数量：若第一待分配数量为零，则说明当前所有秒杀对象均已被分配，则当前不存在处于待分配状态的秒杀对象；若第一待分配数量大于零，则说明当前存在秒杀对象未被分配，说明当前存在处于待分配状态的秒杀对象。通过上述第一待分配数量简单直观的表明本地缓存的第一状态信息表明的处于待分配状态的对象数量，相较于遍历的方式明显加快了本地缓存中第一状态信息的查询速度，特别是在秒杀后期对于无效秒杀请求(秒杀对象已被分配完毕后接收到的秒杀请求)的阻挡作用更加明显。在存在处于待分配状态的秒杀对象的情况下，业务服务器可以在确定出处于待分配状态的秒杀对象的对象信息后，向数据库缓存发送携带上述处于待分配状态的秒杀对象的对象信息的查询请求；或者，也可以将上述处于待分配状态的秒杀对象的对象信息与查询请求关联发送至数据库缓存。

在又一实施例中，上述第一状态信息仅包括处于未分配状态的秒杀对象的对象信息与其当前状态的映射关系，当其中任一秒杀对象被分配后，将该秒杀对象对应的第一状态信息剔除，直至所有秒杀对象均处于已分配状态，此时本地缓存中不存在所述第一状态信息。具体的，业务服务器可以直接查看第一状态信息是否为空：若为空，则表明当前不存在处于待分配状态的秒杀对象；若不为空，则表明当前存在处于待分配状态的秒杀对象。在当前存在处于待分配状态的秒杀对象的情况下，业务服务器可以向数据库缓存发送查询请求，该查询请求中可以携带上述处于待分配状态的秒杀对象的对象信息，可以携带上述处于待分配状态的秒杀对象的数量，也可以仅携带用于标识存在处于待分配状态的秒杀对象的字段，还可以仅发送简单的查询请求(并不携带上述相关信息)，当然，还可以将上述处于待分配状态的秒杀对象的对象信息与查询请求关联发送至数据库缓存。

实际上，上述第一状态信息也可以仅包括秒杀对象的对象标识与其当前状态的映射关系，具体的处理方式及判断方式同上，不再赘述。

因为本地缓存保存的第一状态数据和数据库缓存保存的第二状态数据可能因为延时而不一致，所以在当前不存在处于待分配状态的秒杀对象的情况下，转入步骤416查询数据库缓存的第二状态信息；否则，在当前存在处于待分配状态的秒杀对象的情况下，转入步骤406。

在步骤406中，查询数据库缓存，确定是否存在待分配秒杀对象。

在一实施例中，上述第二状态信息包括各秒杀对象的对象信息与其当前状态的映射关系，而且上述业务服务器向数据库缓存发送携带处于待分配状态的秒杀对象的对象信息的查询请求，或将处于待分配状态的秒杀对象的对象信息与查询请求关联发送至数据库缓存，则数据库缓存接收到上述查询请求后，在自身保存的第二状态信息中查询处于待分配状态的秒杀对象对应的第二状态信息。若不存在第二状态信息表明其对应的秒杀对象处于待分配状态，则表明当前不存在处于待分配状态的秒杀对象；否则，若存在第二状态信息表明其对应的秒杀对象处于待分配状态，则表明当前存在处于待分配状态的秒杀对象。在存在处于待分配状态的秒杀对象的情况下，数据库缓存可以在确定出处于待分配状态的秒杀对象的对象信息后，可以向业务服务器返回携带上述处于待分配状态的秒杀对象的对象信息的缓存查询结果；当然，也可以将上述处于待分配状态的秒杀对象的对象信息与缓存查询结果关联返回至业务服务器。还可以向业务服务器返回携带当前处于待分配状态的秒杀对象数量的缓存查询结果，或者向业务服务器返回仅表明存在处于待分配状态的秒杀对象的缓存查询结果，此时因为缓存查询结果中并不包含具体的对象信息，因此能够减少所发送的数据量，进而减轻网络压力。另外，在存在的处于待分配状态的秒杀对象属于预设分组内时，可以向业务服务器返回携带上述分组标记的缓存查询结果。

在另一实施例中，上述第二状态信息包括各秒杀对象的对象信息与其当前状态的映射关系，同时数据库缓存中还保存有当前处于未分配状态的秒杀对象的第二待分配数量，而且业务服务器向数据库缓存发送携带处于待分配状态的秒杀对象的对象信息的查询请求，或将处于待分配状态的秒杀对象的对象信息与查询请求关联发送至数据库缓存。则数据库缓存接收到上述查询请求后，可以直接查看第二待分配数量：若第二待分配数量为零，则说明当前所有秒杀对象均已被分配，即当前不存在处于待分配状态的秒杀对象；若第二待分配数量大于零，则说明当前存在秒杀对象未被分配，即当前存在处于待分配状态的秒杀对象。

在又一实施例中，上述第二状态信息仅包括处于未分配状态的秒杀对象的对象信息与其当前状态的映射关系，当其中任一秒杀对象被分配后，将该秒杀对象对应的第一状态信息剔除，直至所有秒杀对象均处于已分配状态，此时本地缓存中不存在所述第一状态信息。接收到业务服务器发送的查询请求后，数据库缓存查询第二状态信息，具体的，业务服务器可以直接查看第一状态信息是否为空：若为空，则表明当前不存在处于待分配状态的秒杀对象；若不为空，则表明当前存在处于待分配状态的秒杀对象。

因为本地缓存保存的第一状态数据和数据库缓存保存的第二状态数据可能因为延时而不一致，所以在当前不存在处于待分配状态的秒杀对象的情况下，转入步骤422；在存在处于待分配状态的秒杀对象的情况下，转入步骤408，然后可以在确定出处于待分配状态的秒杀对象的对象信息后，向业务服务器发送携带上述处于待分配状态的秒杀对象的对象信息的缓存查询结果；或者，也可以将上述处于待分配状态的秒杀对象的对象信息与缓存查询结果关联发送至业务服务器。通过上述第二待分配数量简单直观的表明数据库缓存的第二状态信息表明的处于待分配状态的对象数量，相较于遍历的方式明显加快了数据库缓存中第二状态信息的查询速度，特别是在秒杀后期能够进一步阻挡秒杀请求，减少穿透到数据库的秒杀请求。

在步骤408中，查询数据库，确定是否存在处于待分配状态的秒杀对象。

业务服务器在接收到数据库缓存返回的缓存查询结果后，查询数据库以确定数据库中是否存在待分配秒杀对象。按照缓存查询结果的具体内容不同，业务服务器查询数据库的过程也有所区别：

在一实施例中，业务服务器向数据库发送查询请求，其中携带有数据库缓存返回的处于待分配状态的秒杀对象的对象信息，数据库接收该查询请求后，按照查询请求中携带的对象信息查询相应秒杀对象对应的第三状态信息。具体的，数据库可以基于上述对象信息中的对象标识查询相应对象标识对应的第三状态信息。若不存在第三状态信息表明其对应的秒杀对象处于待分配状态，则表明当前不存在处于待分配状态的秒杀对象；否则，若存在第三状态信息表明其对应的秒杀对象处于待分配状态，则表明当前存在处于待分配状态的秒杀对象。在存在处于待分配状态的秒杀对象的情况下，数据库可以在确定出处于待分配状态的秒杀对象的对象信息后，向业务服务器返回携带上述处于待分配状态的秒杀对象的对象信息的数据库查询结果；当然，也可以将上述处于待分配状态的秒杀对象的对象信息与数据库查询结果关联返回至业务服务器。

在另一实施例中，业务服务器向数据库发送查询请求，其中携带有数据库缓存返回的待分配状态的秒杀对象所述预设分组的分组标记，数据库接收该查询请求后，按照查询请求中携带的分组标记在相应分组中查询秒杀对象对应的第三状态信息。后续的查询结果及其处理情况参见前述实施例，不再赘述。通过对秒杀对象进行分组，在数据库缓存中查询第二状态信息和在数据库中查询第三状态信息时，并不需要查询所保存的全部状态信息，而只需要查询相应分组内的状态信息即可，有效减少了查询数据量，加快了查询速度。

在步骤410中，从待分配秒杀对象中确定目标秒杀对象。

业务数据库接收到数据库返回的数据库查询结果后，可以基于数据库查询结果中携带的处于待分配状态的秒杀对象的对象信息或者与数据库查询结果具有关联关系的处于待分配状态的秒杀对象的对象信息确定秒杀对象。具体的，在仅有一个处于待分配状态的秒杀对象的情况下，将该秒杀对象作为目标秒杀对象；在有多个处于待分配状态的秒杀对象的情况下，可以在多个上述秒杀对象中随机选择其中一个作为秒杀对象，也可以将与前一被分配秒杀对象编号最接近的秒杀对象作为目标秒杀对象，当然，还可以使用别的方式确定目标秒杀对象，本公开对此并不进行限制。

实际上，上述步骤404、步骤406、步骤408和步骤410之间是依次递进的关系，以秒杀活动共有100个秒杀对象为例对上述四个步骤进行说明：

步骤404：查询本地缓存中的第一状态信息，若第一状态信息表明不存在处于待分配状态的秒杀对象(100个秒杀对象已经全部被分配)，则转入步骤416；若第一状态信息表明存在80个处于待分配状态的秒杀对象，则转入步骤406。

步骤406，查询数据库缓存中上述80个秒杀对象对应的第二状态信息，若第二状态信息表明不存在处于待分配状态的秒杀对象(上述80个秒杀对象也已经全部被分配)，则转入步骤422；若第二状态信息表明上述80个秒杀对象中存在40个处于待分配状态的秒杀对象，则转入步骤408。

步骤408，查询数据库中上述40个秒杀对象对应的第三状态信息，若第三状态信息表明不存在处于待分配状态的秒杀对象(上述30个秒杀对象也已经全部被分配)，则转入步骤414；若第三状态信息表明上述30个秒杀对象中存在5个处于待分配状态的秒杀对象，则转入步骤410。

步骤410，在上述5个处于待分配状态的秒杀对象中确定出一个秒杀对象，用于分配给上述秒杀请求对应的用户。

在步骤412中，将秒杀对象分配至秒杀请求对应的用户。

业务服务器在确定秒杀对象后，向数据库发送对象分配指令，以使数据库按照该指令将上述秒杀对象分配至上述秒杀请求对应的用户。

在一实施例中，数据库保存的第三状态信息包括秒杀对象的对象信息和当前状态，此时，分配秒杀对象的过程为：将秒杀对象的当前状态由待分配状态更新为已分配状态。或者，数据库维护有记录所有处于已分配状态的秒杀对象的对象信息的已分配列表。此时，分配秒杀对象的过程为：在已分配列表中新增秒杀对象的对象信息表项。又或者，数据库维护有记录所有处于待分配状态的秒杀对象的对象信息的待分配列表。此时，分配秒杀对象的过程为：在待分配列表中删除秒杀对象的对象信息表项。实际上，根据第三状态信息在数据库中的保存形式，上述分配秒杀对象的过程可以具有多种形式，本公开对此并不进行限制。

但是，由于秒杀业务场景具有高并发的特点，因此数据库在短时间内可能接收到对应于多条秒杀请求的对象分配指令，因此在多条对象分配指令来源于不同业务服务器的情况下，可能导致查询阶段的第三状态信息表明上述秒杀对象处于待分配状态，但是在查询后至秒杀对象分配的这段时间内秒杀对象被分配至其他秒杀请求对应的用户(已被占位)，从而导致该秒杀对象的本次分配操作失败。

在上述秒杀对象分配成功的情况下，转入步骤414；否则，在上述秒杀对象分配失败的情况下，转入步骤418。

在步骤414中，更新本地缓存和数据库缓存。

需要说明的是：若由步骤408转入步骤414，则表明所有秒杀对象均处于已分配状态，即所有秒杀对象均已被秒杀。此时更新本地缓存和数据库缓存的过程为：将本地缓存中的第一状态信息和数据库缓存中的第二状态信息全部更新至不存在处于待分配状态的秒杀对象。其中，将数据库缓存中的第二状态信息全部更新至不存在处于待分配状态的秒杀对象可以由业务服务器向数据库缓存发送更新执行来实现。也可以为仅将本地缓存中的第一状态信息全部更新至不存在处于待分配状态的秒杀对象。更新完成后，业务服务器后续接收到的所有秒杀请求均会被本地缓存阻挡，而不会穿透到数据库缓存和数据库，保证了对后续无效秒杀请求的快速处理。

若由步骤412转入步骤414，则表明秒杀对象的秒杀记插入成功。此时更新本地缓存的过程为：将本地缓存中第一状态信息对应的秒杀对象状态更新至处于已分配状态。

上述数据库在秒杀记录的插入过程中会产生相应的日志文件，因此数据库缓存可以根据日志解析器解析得到的数据库中数据的状态变化信息更新数据库缓存。更新数据库缓存的过程为：将数据库缓存中第二状态信息对应的秒杀对象状态更新至处于已分配状态。

在步骤416中，向用户设备返回秒杀失败消息。

数据库中针对秒杀对象的秒杀记录插入失败后，会向业务服务器返回更新失败消息。业务服务器基于该更新失败消息生成秒杀失败消息并返回至用户设备，以使用户设备基于该消息通知用户秒杀失败。

在步骤418中，更新本地缓存和数据库缓存。

由步骤412转入步骤418，则表明秒杀对象的秒杀记插入失败。但是此时实际上秒杀对象也已经被分配，因此，此时更新本地缓存的过程为：将本地缓存中第一状态信息对应的秒杀对象状态更新至处于已分配状态。

在步骤420中，向用户设备返回秒杀成功消息。

数据库中针对秒杀对象的秒杀记录插入成功后，会向业务服务器返回更新成功消息。业务服务器基于该更新成功消息生成秒杀成功消息并返回至用户设备，以使用户设备基于该消息通知用户秒杀成功。

在一实施例中，业务服务器向用户设备返回的秒杀成功消息中可以携带秒杀对象的信息，如对象编号、商品信息等，以便于用户针对该对象进行查看、下单、付款、分享等后续操作。

在步骤422中，更新本地缓存。

由步骤406转入步骤422，则表明数据库缓存的更新快于本地缓存的更新。所有秒杀对象均处于已分配状态，即所有秒杀对象均已被秒杀。此时更新本地缓存和数据库缓存的过程为：将本地缓存中的第一状态信息和数据库缓存中的第二状态信息全部更新至不存在处于待分配状态的秒杀对象。

图5是根据本公开的实施例示出的一种秒杀业务处理装置的示意框图。本实施例所示的视频服务提供装置可以适用于秒杀业务处理应用，所述应用适用于业务服务器。所述业务服务器可以是个人计算机，工业计算机，工控机等能够为前端程序提供秒杀业务处理服务的网络设备。上述前端程序可以是安装在用户设备中的APP，可以是集成在浏览器中的H5页面，也可以是包含秒杀业务的小程序等。相应的，所述用户设备可以是手机、平板电脑、个人计算机、可穿戴设备、个人数字助理、云计算设备等电子设备。本公开对于前端程序及用户设备的具体形式并不进行限制。

如图5所示，所述秒杀业务处理装置可以包括：

第一查询模块501，被配置为根据接收到的用户发出的资源获取请求，查询所述业务服务器的本地缓存中记录的第一状态信息；

第二查询模块502，被配置为若所述第一状态信息中不包含待分配状态信息，则向所述用户返回分配失败消息，所述待分配状态信息用于表明所述业务服务器对应的数据库中存在处于待分配状态的目标资源，若所述第一状态信息中包含所述待分配状态信息，则查询所述业务服务器对应的数据库缓存中记录的第二状态信息；

第三查询模块503，被配置为若所述第二状态信息中不包含所述待分配状态信息，则向所述用户返回所述分配失败消息，若所述第二状态信息中包含所述待分配状态信息，则查询所述数据库中记录的所述目标资源的当前分配状态；

资源分配模块504，被配置为若所述数据库中不存在处于待分配状态的所述目标资源，则向所述用户返回所述分配失败消息并将所述第一状态信息更新为不包含所述待分配状态信息，若所述数据库中存在处于待分配状态的所述目标资源，则通过所述数据库为所述用户分配处于待分配状态的所述目标资源，并根据返回的资源分配结果更新所述第一状态信息。

可选的，其特征在于，

所述第二查询模块502还被配置为：向所述业务服务器对应的数据库缓存发送所述第一状态信息中包含的待分配资源信息，并接收所述数据库缓存返回的所述待分配资源信息对应的所述目标资源在所述第二状态信息中对应的分配状态；

所述第三查询模块503还被配置为：向所述数据库发送所述第二状态信息中包含的待分配资源信息，并接收所述数据库返回的所述第二状态信息对应的所述目标资源的当前分配状态。

可选的，其特征在于，

所述第二查询模块502还被配置为：向所述业务服务器对应的数据库缓存发送查询请求，并接收所述数据库缓存返回的包含状态标识的缓存查询结果，所述状态标识为第一值时表明所述第二状态信息中不包含待分配状态信息，所述状态标识为第二值时表明所述第二状态信息中包含待分配状态信息；

所述第三查询模块503还被配置为：向所述数据库发送查询请求，并接收所述数据库返回的包含状态标识的数据库查询结果；当所述状态标识为第三值时表明所述数据库中不存在处于待分配状态的所述目标资源，当所述状态标识为第四值时表明所述数据库中存在处于待分配状态的所述目标资源，且所述查询结果中包含所述数据库中记录的处于待分配状态的目标资源的资源信息。

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

第一更新模块505，被配置为在所述第二状态信息与所述第一状态信息不相同的情况下，将所述第一状态信息更新至与所述第二状态信息相同。

可选的，所述资源分配模块504包括：

指令发送单元504A，被配置为向所述数据库发送资源分配指令，以使所述数据库为所述用户分配处于待分配状态的所述目标资源；

结果接收单元504B，被配置为接收所述数据库返回的资源分配结果。

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

成功返回模块506，被配置为在所述资源分配结果表明存在所述目标资源被成功分配至所述用户的情况下，向所述用户返回分配成功消息；或者，

失败返回模块507，被配置为在所述资源分配结果表明不存在所述目标资源被成功分配至所述用户的情况下，向所述用户返回分配失败消息。

可选的，所述数据库缓存包括分布式缓存。

本公开的实施例还提出一种电子设备，包括：

处理器；

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

本公开的实施例还提出一种计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述任一实施例所述的资源分配方法。

本公开的实施例还提出一种计算机程序产品，所述计算机程序产品被配置为执行上述任一实施例所述的资源分配方法。

图6是根据本公开的实施例示出的一种电子设备的示意框图。例如，电子设备600可以是个人计算机，工业计算机，工控机等能够为前端程序提供秒杀业务处理服务的网络设备。

图6是根据本公开的实施例示出的一种电子设备的示意框图。例如，电子设备600可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图6，电子设备600可以包括以下一个或多个组件：处理组件602，存储器604，电源组件606，多媒体组件608，音频组件610，输入/输出(I/O)的接口612，传感器组件614，以及通信组件616。

处理组件602通常控制电子设备600的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件602可以包括一个或多个处理器620来执行指令，以完成上述资源分配方法的全部或部分步骤。此外，处理组件602可以包括一个或多个模块，便于处理组件602和其他组件之间的交互。例如，处理组件602可以包括多媒体模块，以方便多媒体组件608和处理组件602之间的交互。

存储器604被配置为存储各种类型的数据以支持在电子设备600的操作。这些数据的示例包括用于在电子设备600上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器604可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件606为电子设备600的各种组件提供电力。电源组件606可以包括电源管理系统，一个或多个电源，及其他与为电子设备600生成、管理和分配电力相关联的组件。

多媒体组件608包括在电子设备600和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件608包括一个前置摄像头和/或后置摄像头。当电子设备600处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件610被配置为输出和/或输入音频信号。例如，音频组件610包括一个麦克风(MIC)，当电子设备600处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器604或经由通信组件616发送。在一些实施例中，音频组件610还包括一个扬声器，用于输出音频信号。

I/O接口612为处理组件602和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件614包括一个或多个传感器，用于为电子设备600提供各个方面的状态评估。例如，传感器组件614可以检测到电子设备600的打开/关闭状态，组件的相对定位，例如所述组件为电子设备600的显示器和小键盘，传感器组件614还可以检测电子设备600或电子设备600一个组件的位置改变，用户与电子设备600接触的存在或不存在，电子设备600方位或加速/减速和电子设备600的温度变化。传感器组件614可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件614还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件614还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件616被配置为便于电子设备600和其他设备之间有线或无线方式的通信。电子设备600可以接入基于通信标准的无线网络，如WiFi，运营商网络(如2G、3G、4G或6G)，或它们的组合。在一个示例性实施例中，通信组件616经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件616还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在本公开一实施例中，电子设备600可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述资源分配方法。

在本公开一实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器604，上述指令可由电子设备600的处理器620执行以完成上述资源分配方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

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

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

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本公开实施例所提供的方法和装置进行了详细介绍，本文中应用了具体个例对本公开的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本公开的方法及其核心思想；同时，对于本领域的一般技术人员，依据本公开的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本公开的限制。

Claims

1.一种资源分配方法，其特征在于，应用于业务服务器，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，

所述查询所述业务服务器对应的数据库缓存中记录的第二状态信息，包括：向所述业务服务器对应的数据库缓存发送所述第一状态信息中包含的待分配资源信息，并接收所述数据库缓存返回的所述待分配资源信息对应的所述目标资源在所述第二状态信息中对应的分配状态；

3.根据权利要求1所述的方法，其特征在于，

所述查询所述业务服务器对应的数据库缓存中记录的第二状态信息，包括：向所述业务服务器对应的数据库缓存发送查询请求，并接收所述数据库缓存返回的包含状态标识的缓存查询结果，所述状态标识为第一值时表明所述第二状态信息中不包含待分配状态信息，所述状态标识为第二值时表明所述第二状态信息中包含待分配状态信息；

4.根据权利要求1所述的方法，其特征在于，还包括：

5.根据权利要求1所述的方法，其特征在于，所述通过所述数据库为所述用户分配处于待分配状态的所述目标资源，包括：

接收所述数据库返回的资源分配结果。

6.根据权利要求1所述的方法，其特征在于，所述数据库生成的对应于所述资源分配结果的日志文件被日志解析器解析后得到状态变更信息，所述状态变更信息被所述数据库缓存用于更新自身记录的所述第二状态信息。

7.一种资源分配系统，其特征在于，所述系统包括：

业务服务器，所述业务服务器的本地缓存中保存有所述目标资源对应的第一状态信息，用于在接收到所述资源获取请求后，通过与数据库缓存、数据库和/或API服务器的配合，实现如权利要求1至6中任一项所述的资源分配方法；

数据库缓存，保存有所述目标资源对应的第二状态信息；

数据库，保存有所述目标资源的当前分配状态。

8.一种资源分配装置，其特征在于，应用于业务服务器，所述装置包括：

9.一种电子设备，其特征在于，包括：

处理器；

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

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至6中任一项所述的资源分配方法。

10.一种计算机可读存储介质，其特征在于，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1至6中任一项所述的资源分配方法。