一种高并发请求的处理方法及装置、服务器、存储介质
技术领域
本申请实施例涉及但不限于电子技术,尤其涉及一种高并发请求的处理方法及装置、服务器、存储介质。
背景技术
相关技术中,高并发请求的业务场景通常使用以下三种解决方式实现:(1)针对所有用户的高并发请求进行处理。(2)通过人工估算高并发请求场景的数据量。(3)使用远程字典服务(Remote Dictionary Server,Redis)作为缓存中间件,完成高并发请求场景中对欲购买的可售对象数量进行扣减的功能。但是,相关技术解决高并发场景存在每秒查询率不高等问题,因此,如何提升高并发请求场景下的查询效率,是本领域技术人员需要重点考虑的问题。
发明内容
有鉴于此,本申请实施例为解决相关技术中存在的至少一个问题而提供一种高并发请求的处理方法及装置、服务器、存储介质。
本申请实施例的技术方案是这样实现的:
一方面,本申请实施例提供一种高并发请求的处理方法,所述方法包括:
服务器接收终端发送的高并发请求,其中,所述高并发请求至少包括欲购买的可售对象的数量信息;所述可售对象在特定时刻开始出售且可售数量有限;
根据所述欲购买的可售对象的数量信息,调用特定的缓存服务对所述可售对象的库存数量进行扣减;其中,所述特定的缓存服务采用支持并发和多协程的开发语言实现;
在所述库存数量为零的情况下,停止对所述高并发请求进行处理。
另一方面,本申请实施例提供一种高并发请求的处理装置,所述装置包括:
接收模块,用于接收终端发送的高并发请求,其中,所述高并发请求至少包括欲购买的可售对象的数量信息;所述可售对象在特定时刻开始出售且可售数量有限;
控制模块,用于根据所述欲购买的可售对象的数量信息,调用特定的缓存服务对所述可售对象的库存数量进行扣减;其中,所述特定的缓存服务采用支持并发和多协程的开发语言实现;
停止模块,用于在所述库存数量为零的情况下,停止对所述高并发请求进行处理。
再一方面,本申请实施例提供一种服务器,包括存储器和处理器,所述存储器存储有可在处理器上运行的计算机程序,所述处理器执行所述程序时实现上述方法中的步骤。
再一方面,本申请实施例提供一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现上述方法中的步骤。
本申请实施例提供的高并发请求的处理方法,通过调用特定的缓存服务对所述可售对象的库存数量进行扣减;其中,所述特定的缓存服务采用支持并发和多协程的开发语言实现,这样,能够通过开放语言的本身特性提高内部实现方法之间的调用速度和处理请求速度以及每秒查询率。如此,提升了高并发请求场景下的查询效率,从而提升了处理请求的能力;并且,所述特定的缓存服务不需要进行外部访问,从而减少了外部依赖,简化部署过程,确保以最快的速度对用户的请求进行响应。
附图说明
图1为本申请实施例提供的一种高并发请求的处理方法实现流程示意图;
图2为本申请实施例提供的一种高并发请求的处理方法实现流程示意图;
图3为本申请实施例提供的一种高并发请求的处理方法实现流程示意图;
图4A为本申请实施例提供的一种高并发请求的处理方法实现流程示意图;
图4B为本申请实施例提供的分配计算资源方法实现流程示意图;
图5为本申请实施例高并发请求的处理装置的组成结构示意图;
图6为本申请实施例中服务器的一种硬件实体示意图。
具体实施方式
下面结合附图和实施例对本申请的技术方案进一步详细阐述。
图1为本申请实施例提供的一种高并发请求的处理方法实现流程示意图,如图1所示,该方法包括:
步骤S101,服务器接收终端发送的高并发请求,其中,所述高并发请求至少包括欲购买的可售对象的数量信息;所述可售对象在特定时刻开始出售且可售数量有限;
这里,所述服务器可以包括应用服务器和数据服务器,所述应用服务器用于执行业务逻辑,所述数据服务器用于进行数据存储。在以下实施例中,与数据相关的功能采用服务器中的数据服务器执行;与业务逻辑相关的功能采用应用服务器执行。
这里,所述高并发请求可以为秒杀场景中,大量用户购买可售对象时发送的请求。所述欲购买的可售对象可以为互联网医院中的医疗服务包、体检套餐和代金券等。
步骤S102,根据所述欲购买的可售对象的数量信息,调用特定的缓存服务对所述可售对象的库存数量进行扣减;其中,所述特定的缓存服务采用支持并发和多协程的开发语言实现;
这里,所述特定的缓存服务可以用于对可售对象进行数量的控制。以可售对象为服务包进行举例,在秒杀场景中,通过所述特定的缓存服务,可以对所述服务包的库存数量进行扣减,实现记录服务包剩余数量、控制服务包库存数量,避免在库存数量为零的情况下继续售卖所述服务包。
这里,所述支持并发和多协程的开发语言可以为Go语言。以Go语言为例,,由于所述Go语言本身的支持并发和多协程性,采用所述Go语言实现的所述特定的缓存服务具有以下特点:1)内部实现方法之间的调用速度;2)处理请求速度快;3)每秒查询率高。由此,确保了所述服务以最快的速度对用户的请求进行响应。
在一些实施例中,所述数量控制的场景可以为一种可售对象对应一个数量控制服务器。而对于数量控制功能而言,所述功能具有分布式的特点。
步骤S103,在所述库存数量为零的情况下,停止对所述高并发请求进行处理。
这里,所述库存数量为0时,停止对所述高并发请求进行后续业务处理,可以减少访问数据库的次数,提高数据库中数据的安全性。例如,以服务包为例,当服务包为0时,不再对秒杀服务包的请求进行处理,避免了对数据库的查询,减少访问数据库的次数,提高数据库中数据的安全性。
在实施的过程中,所述服务器包括应用服务器,所述方法由所述应用服务器来执行。
本申请实施例提供的高并发请求的处理方法,通过调用特定的缓存服务对所述可售对象的库存数量进行扣减;其中,所述特定的缓存服务采用支持并发和多协程的开发语言实现,这样,能够通过开放语言的本身特性提高内部实现方法之间的调用速度和处理请求速度以及每秒查询率。如此,提升了高并发请求场景下的查询效率,从而提升了处理请求的能力;并且,所述特定的缓存服务不需要进行外部访问,从而减少了外部依赖,简化部署过程,确保以最快的速度对用户的请求进行响应。
图2为本申请实施例提供的一种高并发请求的处理方法实现流程示意图,如图2所示,该方法包括:
步骤S210,服务器接收终端发送的高并发请求,其中,所述高并发请求至少包括欲购买的可售对象的数量信息;所述可售对象在特定时刻开始出售且可售数量有限;
步骤S220,根据所述欲购买的可售对象的数量信息,调用特定的缓存服务对所述可售对象的库存数量进行扣减;其中,所述特定的缓存服务采用支持并发和多协程的开发语言实现;
步骤S230,在所述库存数量非零的情况下,根据所述用户的标识信息确定所述用户的身份等级;
在一些实施例中,所述用户标识可以为用户的标识号(Identity Document,ID),所述标识号可以为用户注册的账号。这里,可以根据用户的ID和服务器维护的白名单,确定用户对应的身份。例如,用户A为第一等级(Very Important Person,VIP),根据用户A的ID,在白名单中可以确定所述用户A对应的身份为VIP。
在一些实施例中,所述用户标识可以为代表用户身份等级的常量,可以以键值对的形式包括在请求中。例如,所述用户标识可以用(level,1)的形式包括在请求中。根据所述键值对可以确定出用户的身份等级,例如,1表示最高的用户身份等级。
步骤S240,将所述高并发请求发送给与所述用户的身份等级对应的消息队列;
这里,每一所述用户身份等级对应一个消息队列(Message Queue,MQ)分区。例如,用户身份可以为一级用户(VIP用户)、二级用户(PLUS用户)和三级用户(普通用户),VIP用户对应第一MQ分区;PLUS用户对应第二MQ分区;普通用户对应第三MQ分区。根据发送秒杀请求的用户身份,将所述用户身份对应的秒杀请求以消息的形式发送给对应的MQ分区。
这里,所述MQ分区是一种消息队列,分为顺序队列和无序队列,将所述消息发送给MQ分区后的队列后,监听系统进行监听,并从消息队列中读取所述消息。例如,MQ队列中的消息有十台服务器读取时,第一台服务器收到1、3、6消息,第二台服务器收到2、4、8消息。
步骤S250,调用所述消息队列对应的计算资源响应所述队列中的高并发请求。
这里,上述步骤S250中,用户身份等级不同对应的所述计算资源不同,所述不同用户身份等级对应的计算资源分配方法包括:
步骤S251,获取第一特定值,所述第一特定值用于表征本年度预估的每一用户身份等级对应的可售对象的总量;
举例说明,所述第一特定值可以为2020年度,VIP等级用户秒杀订单的总量;或者,可以为2020年度,PLUS等级用户秒杀订单的总量;或者,可以为2020年度,普通等级用户秒杀订单的总量。
这里,上述步骤S251中,获取所述第一特征值包括:
步骤S2511,根据上年度的每一用户身份等级的用户量、欲购买的可售对象总量和高并发请求的可售对象数量,确定每一用户身份等级的第二特征值,其中,所述第二特征值为本年度每一用户身份等级的用户高并发请求系数;
这里,所述上年度的每一用户身份等级的用户量可以为上一年各等级有效用户量;所述欲购买的可售对象总量可以为上一年各等级用户所有日常订单集合;所述高并发请求的可售对象数量可以为上一年各等级用户秒杀订单集合,所述本年度每一用户身份等级的用户高并发请求系数可以为本年度每一用户身份等级的秒杀系数。
在一些实施例中,根据所述上一年各等级用户所有日常订单集合和上一年各等级用户秒杀订单集合计算秒杀系数可以包括:
步骤S2511a,根据上一年各等级有效用户量UPi、上一年各等级用户所有日常订单集合OPYi计算出上一年用户人均日常订单量OPAi;
这里,所述秒杀系数可以为去年同一级别用户的人均日常订单量与活动秒杀时的人均订单量的比值。
举例说明,假设用户身份等级为三个,所述三个身份级别按照等级由高到低的顺序分别表示为第1、2、3。
上一年用户集合:UPi,i∈{1,2,3}代表上一年第i个用户级别的有效用户的集合。
上一年用户所有日常订单集合:OPYi,i∈{1,2,3}代表上一年第i个用户等级的用户所有日常订单的集合。
上一年用户人均日常订单量:
i∈{1,2,3}代表上一年第i个用户等级的用户人均日常订单量。
步骤S2511b,根据上一年各等级有效用户量UPi、上一年各等级用户秒杀订单集合OPOi计算出上一年用户人均秒杀订单量OPi;
上一年用户秒杀订单集合:OPOi,i∈{1,2,3}代表上一年第i个用户等级的用户在秒杀时的拍下的所有订单集合。(模型中所有的秒杀订单均已秒杀时拍下的订单为标准,不关注订单状态是否成功)
上一年用户人均秒杀订单量:
i∈{1,2,3}代表上一年第i个用户等级的用户在秒杀时的人均拍下的订单量。
步骤S2511c,根据上一年用户人均日常订单量OPAi和上一年用户人均秒杀订单量OPi,计算出秒杀系数σ。
秒杀系数:
i∈{1,2,3}代表衡量不同等级的用户人均日常订单量和人均秒杀拍下的订单量之间的比例系数。
步骤S2512,根据每一所述第二特征值和本年度每一用户身份等级的欲购买的可售对象总量,确定第三特征值,其中,所述第三特征值为本年度每一用户身份等级的人均高并发请求的可售对象数量;
这里,所述本年度每一用户身份等级的欲购买的可售对象总量可以为本年各等级用户的人均日常订单量;所述本年度每一用户身份等级的人均高并发请求的可售对象数量可以为预估的本年各等级用户人均秒杀的订单量。
在一些实施例中,所述步骤S2512包括:
步骤S2512a,根据本年各等级用户集合UNi和本年各等级用户所有日常订单集合ONYi,计算出本年用户人均日常订单量ONAi;
本年各等级用户集合:UNi,i∈{1,2,3}代表上一年第i个用户级别的本年有效用户的集合。
本年各等级用户所有日常订单集合:ONYi,i∈{1,2,3}代表本年第i个用户等级的用户所有日常订单的集合。
本年用户人均日常订单量:
i∈{1,2,3}代表本年第i个用户等级的用户人均日常订单量。
步骤S2512b,根据秒杀系数σ和本年用户人均日常订单量ONAi,计算得出本年各等级用户人均秒杀订单量ONi。
这里,所述本年用户人均秒杀订单量:ONi,i∈{1,2,3}代表本年第i个用户等级的用户在秒杀时的人均拍下的订单量。
在一些实施例中,所述预估的本年各等级用户人均秒杀订单量:
i∈{1,2,3}。
步骤S2513,根据所述第三特征值和本年度每一用户身份等级的用户集合,确定每一所述第一特征值。
步骤S252,根据所述第一特征值,确定对应用户身份等级对应的计算资源;
这里,不同所述用户身份等级对应不同计算资源;这里,所述计算资源可以为服务器资源,例如,可以为服务器数量。
这里,可以根据不同等级的第一特征值比例,对所计算资源进行分配,例如,不同等级的第一特征值比例为:2:3:5;即,所述计算资源将按照2:3:5进行分配。
步骤S253,将每一用户身份等级对应的计算资源,按照比例分配给对应用户身份登记的消息队列。
本申请实施例提供的高并发请求的处理方法,首先,将所述高并发请求发送给与所述用户的身份等级对应的消息队列;调用所述消息队列对应的计算资源响应所述队列中的高并发请求。这样,能够按照用户级别对用户请求进行分流,保障处理请求的局部公平性。其次,获取第一特定值,所述第一特定值用于表征本年度预估的每一用户身份等级对应的可售对象的总量。这样,能够基于历史用户订单综合数据预估本年度可售对象的总量。最后,根据所述第一特征值,确定对应用户身份等级对应的计算资源,这样能够较为合理地分配计算资源以提高响应速度;同时,将各级别用户分开处理也能够满足高级别用户快速响应的特性。
图3为本申请实施例提供的一种高并发请求的处理方法实现流程示意图,如图3所示,该方法包括:
本申请实施例提供的一种高并发请求的处理方法,该方法包括:
步骤S301,服务器接收终端发送的高并发请求,其中,所述高并发请求至少包括欲购买的可售对象的数量信息;所述可售对象在特定时刻开始出售且可售数量有限;
步骤S302,根据所述欲购买的可售对象的数量信息,调用特定的缓存服务对所述可售对象的库存数量进行扣减;其中,所述特定的缓存服务采用支持并发和多协程的开发语言实现;
这里,所述高并发请求还包括用户的标识信息,对应地,在上述步骤S220之后,所述还包括:
步骤S303,在所述库存数量非零的情况下,根据所述用户的标识信息确定所述用户的身份等级;
其中,所述用户身份等级至少包括用户数量从少到多的第一身份等级、第二身份等级和第三身份等级;
步骤S304,将所述高并发请求发送给与所述用户的身份等级对应的消息队列;
步骤S305,调用所述消息队列对应的计算资源响应所述队列中的高并发请求。
其中,所述计算资源至少包括资源大小从小到大小依次排列的第一计算资源、第二计算资源和第三计算资源;所述消息队列至少包括:第一分区、第二分区和第三分区;
其中,所述第一至第三身份等级一一对应第一至第三计算资源,所述第一至第三计算资源一一对应所述第一至第三分区,
其中,第一至第三身份等级对应的高并发请求的响应时间依次递增。
这里,上述步骤S303至步骤S305对应于前述步骤S230至步骤S250,在实施时可以参照前述步骤的具体实施方式。
步骤S306,在当前消息队列对应的计算资源处于禁用状态的情况下,确定所述当前消息队列对应的当前用户身份等级;
步骤S307,将所述当前用户身份等级对应的高并发请求发送给目标用户身份等级对应的消息队列,其中,所述目标用户身份等级低于所述当前用户身份等级;
步骤S308,调用所述消息队列对应的计算资源优先响应所述当前用户身份等级对应的高并发请求。
举例说明,当前身份等级对应的服务器数量大于高一级,用于为高一级用户进行资源灾备,如果处理高一级用户请求的服务器出现故障,所述请求将由当前等级对应的服务器进行处理,并且优先处理所述高一级用户对应的请求。
本申请实施例提供的高并发请求的处理方法,通过调用下一级消息队列对应的计算资源优先响应所述当前用户身份等级对应的高并发请求,使得当前计算资源不可用时,当前用户的请求在下一级用户的计算资源中能够进行有限处理,保证了当前用户身份等级请求的可靠性。
以秒杀的高并发请求场景为例,在互联网医院中有许多促销秒杀活动。在这些促销场景下,欲购买的可售对象的请求会在瞬间激增。相关技术中,适用于互联网医院秒杀场景的系统在秒杀前需要进行充足的准备:(1)需要分析往年的秒杀数据,总结互联网医院用户的秒杀特性,以合理分配资源;(2)对秒杀系统进行优化设计以抵挡秒杀瞬时的高并发请求。
互联网医院秒杀场景的特点为:
(1)用户身份被划分等级。用户身份从高到底被划分为三个等级:VIP用户、PLUS用户和普通用户。不同用户的使用率依据各自身份各不相同。并且,根据实际数据分析比对可知,不同身份等级的用户量不同。例如,VIP用户的数量远小于PLUS用户数量,PLUS用户数量远小于普通用户数量。
(2)小流量秒杀。互联网医院秒杀活动的可售对象(产品)主要为部分药品、保险单等,由于欲购买的可售对象非普通民众每日必须消耗品,故相比较于日用品的秒杀活动,本场景下的秒杀活动具有小流量特点。
(3)连年同一用户身份等级用户人均日常订单量和秒杀中人均订单量成比例关系。以秒杀活动为例,通过对往年的秒杀活动不同级别用户的订单量进行综合数据分析,我们可知,同一级别的用户的人均日常下单量和秒杀中的人均订单量成连年比例关系。即,相邻两年中,同一级别的用户的人均日常下单量和秒杀中的人均订单量之间的比值相同,因此,根据所述比值以及下一年的用户人均日常订单量可以进行秒杀单量的预估,以更好的应对秒杀活动。即,用户日常订单量越多,在遇到促销活动时,更“需要”秒杀欲购买的可售对象。
(4)要求请求处理公平性。本场景需要在不同用户身份等级的用户间实现局部公平。即,同一身份等级的用户,先发送的请求先处理。
相关技术中,解决秒杀场景的采用以下方式:(1)针对所有用户的秒杀请求进行处理;(2)通过人工估算秒杀场景的数据量;(3)使用Redis作为缓存中间件,完成秒杀场景中对欲购买的可售对象数量进行扣减的功能。
对应地,相关技术中,解决秒杀场景的方式存在以下问题:(1)针对所有用户的秒杀请求进行处理,没有用户级别划分,有可能导致用户秒杀请求行为不公平,且不能满足高级别用户的快响应特性。(2)通过人工估算秒杀请求的数据量,可能造成数据量不准确,并易出现大规模误差,从而造成根据数据量进行分配的资源短缺或者浪费。(3)由于分布式数量控制通过Redis技术实现时,提升性能通常通过增加服务器实现,然而,在秒杀场景下,对产品的库存扣减,是从单一服务器进行扣减,因此,通过现有的Redis技术无法提升性能;并且,使用Redis作为缓存中间件,由于Redis可提供的每秒查询率(Queries Per Second,QPS)有限,不适用于集中操作热点数据的秒杀场景。
为解决相关技术中的问题,本申请实施例提供的方案对解决了处理请求公平性的问题;并且,可以根据历史数据以及本年用户数量和用户日常人均订单量预估本年秒杀请求对应的欲购买可售对象的订单量,以合理进行系统设计和计算资源的分配。本申请实施例提供的方案具有以下特征:(1)按照用户级别对用户请求进行分流,保障处理请求的局部公平性。(2)根据历史数据估算秒杀请求的数据量。通过分析连年同一用户身份等级的用户人均日常订单量和秒杀中人均订单量的比例关系,计算得到上一年的比例系数(秒杀系数),从而预估本年秒杀请求对应的欲购买可售对象的订单量。(3)采用Go语言编写特定的缓存服务。通过特定的缓存服务,能够提高QPS,提升请求处理的性能;并且,减少外部依赖,简化部署过程,确保以最快的速度对用户的请求进行响应。
图4A为本申请实施例提供的一种高并发请求的处理方法实现流程示意图,如图4A所示,该方法包括:
步骤S401,前台页面CDN接收用户的秒杀请求;
这里,所述内容分发网络(Content delivery networks,CDN),能够缓存静态资源,提升首次访问的速度。根据用户请求的类型,可以采用不同的方式进行处理:1)在用户请求为无逻辑的静态资源的情况下,由CDN对用户请求进行处理;2)在用户请求包括逻辑操作的情况下,由服务器对用户请求进行处理。
这里,所述请求中至少包括:商品信息、用户信息和活动组织方信息(店铺信息)。
步骤S402,前台对秒杀请求进行流量负载处理;
在一些实施例中,对秒杀请求进行流量负载处理是在网络负载均衡的场景下进行的。所述网络负载均衡是多台服务器以对称的方式组成一个服务器集合,每台服务器都具有等价的地位,都可以单独对外提供服务而无须其他服务器的辅助。在网络负载均衡的场景下,通过对秒杀请求进行流量负载处理,可以将秒杀请求均匀分配到对称结构中的特定服务器上,而接收到秒杀请求的服务器可以独立地响应。这样,能够保证服务器拿到数量相近的秒杀请求,能够协调请求发送给特定服务器,从而提升服务器集合对并发请求的处理能力,快速获取请求数据,提高并发请求的效率。
例如,服务器集合中A服务器用于处理下单请求,B服务器用于处理加购物车请求,流量负载处理可以协调下单请求给A服务器,加购物车请求给B服务器。
步骤S403,前台对秒杀请求进行分布式权限认证;
这里,分布式权限认证可以用于筛除满足特定条件的无效秒杀请求,保留有效秒杀请求。
在一些实施例中,所述特定条件可以为单一IP地址的每秒钟请求阈值。在单一IP地址的每秒钟请求值大于每秒钟请求阈值的情况下,判断所述单一IP地址可能为非正常用户,拦截所述IP地址,筛除所述IP地址发送的无效秒杀请求。例如,一个IP地址一秒钟请求了1w次,设定的每秒钟请求阈值为70次,判断该IP地址可能为非正常用户,拦截该IP地址,筛除所述IP地址发送的无效秒杀请求。
在一些实施例中,所述特定条件可以为流量阈值。在当前流量总数大于流量阈值时,将大于流量阈值的请求放在下一秒进行处理。
在一些实施例中,所述特定条件可以为特定的正则表达式。判断发送秒杀请求的用户ID不满足特定的正则表达式时,判断当前用户无效,筛除所述用户发送的秒杀请求。
步骤S404,后台进行分布式数量控制;
这里,所述分布式数量控制可以为对产品数量进行的库存扣减。在秒杀场景中,通常需要记录产品是否已经被卖光,而记录这一过程的动作便称之为扣减。采用分布式数量控制可以在产品的库存为0时,停止后续业务处理,减少访问数据库的次数,提高数据库中数据的安全性。例如,产品为服务包时,当服务包为0时,不再对秒杀服务包的请求进行处理,避免了对数据库的查询,减少访问数据库的次数,提高数据库中数据的安全性。
这里,对分布式数量的控制可以通过特定的缓存产品实现,所述特定的缓存产品通过go语言实现。这里,采用特定缓存产品后,OPS为24万每秒(24W/s),相比于相关技术中采用Redis的5W/s,计算性能更优。
这里,采用Go语言实现的缓存产品因为语言具有多协程特定,可以提供更高的QPS,且部署复杂度较低。没有访问其他外部服务的资源开销,极大程度的降低了资源成本。
这里,由于Redis缓存中不仅存储了秒杀数据,也存储了多元化的业务数据,因此,相比使用Redis缓存进行秒杀产品的数量扣减,通过Go语言编写的特定的缓存产品用于数量扣减性能更好。此外,使用所述特定的缓存产品可以将需要用到的数据提前读取,减少业务处理时间,提升访问速度。
步骤S405,后台进行身份校验;
在一些实施例中,服务器维护一套白名单,所述白名单用于根据用户ID确定对应的用户身份。例如,用户A为VIP,根据用户A的ID,在白名单中可以确定所述用户A对应的身份为VIP。
步骤S406,后台根据不同的用户身份等级进行MQ分区;
这里,每一用户身份等级对应一个MQ分区。例如,用户身份可以为VIP用户、PLUS用户和普通用户,VIP用户对应第一MQ分区;PLUS用户对应第二MQ分区;普通用户对应第三MQ分区。根据发送秒杀请求的用户身份,将所述用户身份对应的秒杀请求以消息的形式发送给对应的MQ分区。
这里,所述MQ分区是一种消息队列,分为顺序队列和无序队列,将所述消息发送给MQ分区后的队列后,监听系统进行监听,并从消息队列中读取所述消息。例如,MQ队列中的消息有十台服务器读取时,第一台服务器收到1、3、6消息,第二台服务器收到2、4、8消息。
步骤S407,后台根据不同的用户身份进行对应的业务处理;
这里,需要说明的是,对同一身份的秒杀请求执行先下单先处理的原则。这样,可以保证同一级别用户秒杀请求的“局部公平性”。这里,所述“局部公平性”可以为在秒杀场景中按照用户级别划分不同排队通道,将订单按照不同类别分发到不同排队通道中排队等待处理,以保证同一级别用户间的局部公平,即同一级别的用户中,先下单的用户将优先进入到排队队列中等待处理。
这里,需要说明的是,每一用户身份等级对应的计算资源不同,这里,所述计算资源可以为服务器的数量。同一用户身份等级对应的服务器组成一服务器集合,高一级服务器集合中包括的服务器数量小于低一级服务器集合。
在一些实施例中,服务器数量按照用户身份等级由高到低进行灾备。举例说明,当前身份等级对应的服务器数量大于高一级,用于为高一级用户进行资源灾备,如果处理高一级用户请求的服务器出现故障,所述请求将由当前等级对应的服务器进行处理,并且优先处理所述高一级用户对应的请求。
在一些实施例中,如图4B所示,上述步骤S407可以包括:
步骤S4071,根据上一年各等级有效用户量UPi、上一年各等级用户所有日常订单集合OPYi、上一年各等级用户秒杀订单集合OPOi计算出秒杀系数σ;
这里,上述步骤S4071可以包括:
步骤S4071a,根据上一年各等级有效用户量UPi、上一年各等级用户所有日常订单集合OPYi计算出上一年用户人均日常订单量OPAi;
这里,所述秒杀系数可以为去年同一级别用户的人均日常订单量与活动秒杀时的人均订单量的比值。
举例说明,假设用户身份等级为三个,所述三个身份级别按照等级由高到低的顺序分别表示为第1、2、3。
上一年用户集合:UPi,i∈{1,2,3}代表上一年第i个用户级别的有效用户的集合。
上一年用户所有日常订单集合:
i∈{1,2,3}代表上一年第i个用户等级的用户所有日常订单的集合。
上一年用户人均日常订单量:
i∈{1,2,3}代表上一年第i个用户等级的用户人均日常订单量。
步骤S4071b,根据上一年各等级有效用户量UPi、上一年各等级用户秒杀订单集合OPOi计算出上一年用户人均秒杀订单量OPi;
上一年用户秒杀订单集合:OPOi,i∈{1,2,3}代表上一年第i个用户等级的用户在秒杀时的拍下的所有订单集合。(模型中所有的秒杀订单均已秒杀时拍下的订单为标准,不关注订单状态是否成功)
上一年用户人均秒杀订单量:
i∈{1,2,3}代表上一年第i个用户等级的用户在秒杀时的人均拍下的订单量。
步骤S4071c,根据上一年用户人均日常订单量OPAi和上一年用户人均秒杀订单量OPi,计算出秒杀系数σ。
秒杀系数:
i∈{1,2,3}代表衡量不同等级的用户人均日常订单量和人均秒杀拍下的订单量之间的比例系数。
步骤S4072,根据计算得到的秒杀系数σ以及本年各等级用户的人均日常订单量ONAi可以计算出本年各等级用户人均秒杀订单量ONi;
这里,所述预估本年各等级用户人均秒杀订单量主要依据各等级的秒杀系数和用户人均日常订单量。根据往年活动的订单量分析可知,在任意连续两年中,同一等级用户的人均日常订单量和秒杀活动时的人均订单量的比值几乎相同,可以利用此规律进行下一年的活动订单量预估以更好地进行资源分配应对秒杀活动。
这里,上述步骤S4072可以包括:
步骤S4072a,根据本年各等级用户集合UNi和本年各等级用户所有日常订单集合ONYi,计算出本年用户人均日常订单量ONAi;
本年各等级用户集合:UNi,i∈{1,2,3}代表上一年第i个用户级别的本年有效用户的集合。
本年各等级用户所有日常订单集合:ONYi,i∈{1,2,3}代表本年第i个用户等级的用户所有日常订单的集合。
本年用户人均日常订单量:
i∈{1,2,3}代表本年第i个用户等级的用户人均日常订单量。
步骤S4072b,根据秒杀系数σ和本年用户人均日常订单量ONAi,计算得出本年各等级用户人均秒杀订单量ONi。
这里,所述本年用户人均秒杀订单量:ONi,i∈{1,2,3}代表本年第i个用户等级的用户在秒杀时的人均拍下的订单量。
在一些实施例中,所述预估的本年各等级用户人均秒杀订单量:
i∈{1,2,3}。
步骤S4073,由预估的本年的各等级用户人均秒杀订单量ONi和本年各等级用户集合UNi可以预估出本年各等级用户秒杀订单总量Oi。
在一些实施例中,所述预估本年的用户秒杀订单总量:
i∈{1,2,3}代表预估的本年的第i个用户等级的用户在秒杀时会拍下的订单量。
步骤S4074,根据预估出的本年各等级用户秒杀订单总量按比例分配业务处理的计算资源,以使各等级用户更快地得到秒杀结果。
这里,所述按比例分配业务处理的计算资源,即按照本年各等级用户秒杀订单总量按比例分配计算资源对请求进行处理。这样,可以较为合理地分配计算资源以提高响应速度;同时,将各级别用户分开处理也可以满足高级别用户快速响应的特性。
这里,需要说明的是用户身份等级由低到高对应的用户数量一次递增。
步骤S408,后台将业务处理的结果存入数据库。
这里,所述业务处理的结果至少可以包括:订单信息、订单号、金额和地址。
本申请实施例提供的高并发请求的处理方法,首先,通过对请求进行用户身份等级的划分,并为不同的用户身份等级分配不同的计算资源,进行对应的业务处理,实现了同一级别用户秒杀请求的“局部公平性”。其次,根据预估出的本年各等级用户秒杀订单总量按比例分配业务处理的计算资源,能够使得各等级用户更快地得到秒杀结果。最后,通过特定的缓存产品实现分布式数量的控制能够替代Redis实现的缓存,提高每秒查询率,实现最小化响应时间的数量扣减。
基于前述的实施例,本申请实施例提供一种高并发请求的处理装置,该装置包括所包括的各单元、以及各单元所包括的各模块,可以通过服务器中的处理器来实现;当然也可通过具体的逻辑电路实现。在实施的过程中,所述服务器包括服务器集群,实现时可以为后台服务器或应用服务器;处理器可以为中央处理器(Central Processing Unit,CPU)、微处理器(Microprocessor Unit,MPU)、数字信号处理器(Digital Signal Processing,DSP)或现场可编程门阵列(Field Programmable Gate Array,FPGA)等。
图5为本申请实施例高并发请求的处理装置的组成结构示意图,如图5所示,所述装置500包括接收模块501、控制模块502和停止模块503,其中:
接收模块501,用于接收终端发送的高并发请求,其中,所述高并发请求至少包括欲购买的可售对象的数量信息;所述可售对象在特定时刻开始出售且可售数量有限;
控制模块502,用于根据所述欲购买的可售对象的数量信息,调用特定的缓存服务对所述可售对象的库存数量进行扣减;其中,所述特定的缓存服务采用支持并发和多协程的开发语言实现;
停止模块503,用于在所述库存数量为零的情况下,停止对所述高并发请求进行处理。
在一些实施例中,所述装置500还包括第一确定模块、第一发送模块和第一响应模块,其中:第一确定模块,用于在所述库存数量非零的情况下,根据所述用户的标识信息确定所述用户的身份等级;第一发送模块,用于将所述高并发请求发送给与所述用户的身份等级对应的消息队列;第一响应模块,用于调用所述消息队列对应的计算资源响应所述队列中的高并发请求。
在一些实施例中,所述装置500还包括获取模块、第二确定模块和分配模块,其中:获取模块,用于获取第一特定值,所述第一特定值用于表征本年度预估的每一用户身份等级对应的可售对象的总量;第二确定模块,用于根据所述第一特征值,确定对应用户身份等级对应的计算资源;分配模块,用于将每一用户身份等级对应的计算资源,按照比例分配给对应用户身份登记的消息队列。
在一些实施例中,所述装置500还包括第三确定模块、第四确定模块和第五确定模块,其中:第三确定模块,用于根据上年度的每一用户身份等级的用户量、欲购买的可售对象总量和高并发请求的可售对象数量,确定每一用户身份等级的第二特征值,其中,所述第二特征值为本年度每一用户身份等级的用户高并发请求系数;第四确定模块,用于根据每一所述第二特征值和本年度每一用户身份等级的欲购买的可售对象总量,确定第三特征值,其中,所述第三特征值为本年度每一用户身份等级的人均高并发请求的可售对象数量;第五确定模块,用于根据所述第三特征值和本年度每一用户身份等级的用户集合,确定每一所述第一特征值。
在一些实施例中,所述装置500还包括第六确定模块、第二发送模块和第二响应模块,其中:第六确定模块,用于在当前消息队列对应的计算资源处于禁用状态的情况下,确定所述当前消息队列对应的当前用户身份等级;第二发送模块,用于将所述当前用户身份等级对应的高并发请求发送给目标用户身份等级对应的消息队列,其中,所述目标用户身份等级低于所述当前用户身份等级;第二响应模块,用于调用所述消息队列对应的计算资源优先响应所述当前用户身份等级对应的高并发请求。
以上装置实施例的描述,与上述方法实施例的描述是类似的,具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节,请参照本申请方法实施例的描述而理解。
需要说明的是,本申请实施例中,如果以软件功能模块的形式实现上述的高并发请求的处理方法,并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台服务器(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read Only Memory,ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样,本申请实施例不限制于任何特定的硬件和软件结合。
对应地,本申请实施例提供一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现上述方法中的步骤。
对应地,本申请实施例提供一种服务器,包括存储器和处理器,所述存储器存储有可在处理器上运行的计算机程序,所述处理器执行所述程序时实现上述方法中的步骤。
这里需要指出的是:以上存储介质和设备实施例的描述,与上述方法实施例的描述是类似的,具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节,请参照本申请方法实施例的描述而理解。
需要说明的是,图6为本申请实施例中服务器的一种硬件实体示意图,如图6所示,该服务器600的硬件实体包括:处理器601、通信接口602和存储器603,其中
处理器601通常控制服务器600的总体操作。
通信接口602可以使服务器通过网络与其他终端或服务器通信。
存储器603配置为存储由处理器601可执行的指令和应用,还可以缓存待处理器601以及服务器600中各模块待处理或已经处理的数据(例如,图像数据、音频数据、语音通信数据和视频通信数据),可以通过闪存(FLASH)或随机访问存储器(Random AccessMemory,RAM)实现。
应理解,说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此,在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外,这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
在本申请所提供的几个实施例中,应该理解到,所揭露的设备和方法,可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,如:多个单元或组件可以结合,或可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口,设备或单元的间接耦合或通信连接,可以是电性的、机械的或其它形式的。
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的,作为单元显示的部件可以是、或也可以不是物理单元;既可以位于一个地方,也可以分布到多个网络单元上;可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
另外,在本申请各实施例中的各功能单元可以全部集成在一个处理单元中,也可以是各单元分别单独作为一个单元,也可以两个或两个以上单元集成在一个单元中;上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:移动存储设备、只读存储器(Read Only Memory,ROM)、磁碟或者光盘等各种可以存储程序代码的介质。
或者,本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台服务器(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括:移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。