CN115641180A - 一种请求处理的方法、相关装置及设备 - Google Patents
一种请求处理的方法、相关装置及设备 Download PDFInfo
- Publication number
- CN115641180A CN115641180A CN202110814715.0A CN202110814715A CN115641180A CN 115641180 A CN115641180 A CN 115641180A CN 202110814715 A CN202110814715 A CN 202110814715A CN 115641180 A CN115641180 A CN 115641180A
- Authority
- CN
- China
- Prior art keywords
- order transaction
- transaction requests
- order
- inventory quantity
- requests
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请实施例公开了一种请求处理的方法、相关装置及设备,用于过滤无效请求,提高处理订单交易请求的稳定性。本申请实施例方法包括:获取目标时段内针对可交易对象的N个订单交易请求,其中,每个订单交易请求携带一个用户标识以及时间戳,可交易对象对应第一库存数量,N为大于1的整数;根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从N个订单交易请求中获取K个订单交易请求,根据每个订单交易请求所携带的用户标识,从K个订单交易请求中获取P个订单交易请求,其中,P个订单交易请求对应于P个不同的用户标识,从P个订单交易请求中获取Q个订单交易请求,向交易服务器发送Q个订单交易请求。
Description
技术领域
本申请实施例涉及数据处理技术领域,尤其涉及一种请求处理的方法、相关装置及设备。
背景技术
随着互联网时代的迅速发展,市场竞争显得愈加激烈。商家们为了拉动商品的销售量,或者是为了产品提高知名度,亦或是为了增加些消费用户群等,一般是通过促销或秒杀等抢购类活动来吸引用户消费,而由于秒杀活动会产生大规模的访问流量,以及在访问的过程中常常因为网络原因导致有时间差,不能保证消费用户之间的公平竞争。因此,现有的秒杀系统一般是通过采用异步方式,将高并发流量写入到消息队列中,同时利用异步服务的消费消息队列来处理消息请求。
但是,异步处理秒杀流量时会接收过多的无效请求,并使大量无效请求进入到消息队列中,严重增加消息队列的处理消息请求的压力,容易出现消息队列超负荷,从而导致秒杀系统崩溃的情况。
发明内容
本申请实施例提供了一种请求处理的方法、相关装置及设备,通过多级请求过滤方式,将N个订单交易请求经过层层过滤,得到Q个订单交易请求,能够将N个订单交易请求中的无效请求充分过滤掉,有效减少无效请求造成的流量负荷,降低对订单交易请求的处理压力,从而提高处理订单交易请求的稳定性和可靠性。
有鉴于此,本申请一方面提供一种请求处理的方法,包括:
获取目标时段内针对可交易对象的N个订单交易请求,其中,每个订单交易请求携带一个用户标识以及时间戳,可交易对象对应第一库存数量,N为大于1的整数;
根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从N个订单交易请求中获取K个订单交易请求,其中,K为小于N的整数;
根据每个订单交易请求所携带的用户标识,从K个订单交易请求中获取P个订单交易请求,其中,P个订单交易请求对应于P个不同的用户标识,P为小于K的整数;
从P个订单交易请求中获取Q个订单交易请求,其中,Q为小于或等于第一库存数量的整数,Q为小于P的整数;
向交易服务器发送Q个订单交易请求。
本申请的另一方面提供一种请求处理的装置,包括:
获取单元,用于获取目标时段内针对可交易对象的N个订单交易请求,其中,每个订单交易请求携带一个用户标识以及时间戳,可交易对象对应第一库存数量,N为大于1的整数;
处理单元,用于根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从N个订单交易请求中获取K个订单交易请求,其中,K为小于N的整数;
处理单元,还用于根据每个订单交易请求所携带的用户标识,从K个订单交易请求中获取P个订单交易请求,其中,P个订单交易请求对应于P个不同的用户标识,P为小于K的整数;
处理单元,还用于从P个订单交易请求中获取Q个订单交易请求,其中,Q为小于或等于第一库存数量的整数,Q为小于P的整数;
发送单元,用于向交易服务器发送Q个订单交易请求。
在一种可能的设计中,在本申请实施例的另一方面的一种实现方式中,所述处理单元具体可以用于:
根据P个订单交易请求对第二库存数量进行依次递减,得到剩余库存数量,其中,第二库存数量为用于展示可交易对象的库存数量;
若剩余库存数量不为零,则根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从P个订单交易请求中获取Q个订单交易请求。
在一种可能的设计中,在本申请实施例的另一方面的一种实现方式中,
发送单元,还用于若剩余库存数量为零,则向源端设备发送库存查询请求,以使源端设备根据库存查询请求查询可用库存数量,其中,源端设备用于提供可交易对象的库存数量;
处理单元,还用于接收源端设备发送的S个可用库存数量,并从(P-Q)个订单交易请求中获取S个订单交易请求,其中,S为小于第一库存数量的整数,S为小于(P-Q)的整数。
在一种可能的设计中,在本申请实施例的另一方面的一种实现方式中,
发送单元,还用于向源端设备发送批次库存查询请求,以使源端设备根据批次库存查询请求查询当前批次剩余库存数量,其中,当前批次剩余库存数量用于表示可交易对象的每批次交易活动的当前剩余的库存数量;
处理单元,还用于接收源端设备发送的当前批次剩余库存数量,根据当前批次剩余库存数据更新第二库存数量。
在一种可能的设计中,在本申请实施例的另一方面的一种实现方式中,
获取单元,还用于从云端服务器中读取源端设备上传的第一库存数量,云端服务器用于存储可交易对象的库存数量;
处理单元,还用于根据第一库存数量配置第二库存数量,其中,第二库存数量大于第一库存数量;
处理单元,还用于将第二库存数量同步至云端服务器。
在一种可能的设计中,在本申请实施例的另一方面的一种实现方式中,发送单元具体可以用于:
获取i个可访问数量,其中,i个可访问数量来源于交易服务器,i为小于第一库存数量的整数;
根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从Q个订单交易请求中获取i个订单交易请求,并将i个订单交易请求发送至交易服务器;
当接收到交易服务器发送的可处理提示时,将(Q-i)个订单交易请求发送至交易服务器。
在一种可能的设计中,在本申请实施例的另一方面的一种实现方式中,处理单元具体可以用于:
根据每个订单交易请求所携带的用户标识,从N个订单交易请求中获取不属于黑名单标识集的j个用户标识对应的j个订单交易请求,其中,j为小于N的整数;
按照每个订单交易请求所携带的时间戳的先后顺序,从j个订单交易请求中获取K个订单交易请求。
本申请另一方面提供了一种计算机设备,包括:存储器、收发器、处理器以及总线系统;
其中,存储器用于存储程序;
处理器用于执行存储器中的程序时实现如上述各方面的方法;
总线系统用于连接存储器以及处理器,以使存储器以及处理器进行通信。
本申请的另一方面提供了一种计算机可读存储介质,计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行上述各方面的方法。
本申请的另一个方面,提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。网络设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该网络设备执行上述各方面所提供的方法。
从以上技术方案可以看出,本申请实施例具有以下优点:
通过获取目标时段内针对可交易对象的N个订单交易请求,并根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从N个订单交易请求中获取K个订单交易请求,进而,根据每个订单交易请求所携带的用户标识,从K个订单交易请求中获取P个订单交易请求,然后,从P个订单交易请求中获取Q个订单交易请求,并向交易服务器发送Q个订单交易请求。通过上述方式,实现了多级请求过滤方式,将N个订单交易请求过滤为K个订单交易请求,再将K个订单交易请求过滤为P个订单交易请求,最后将P个订单交易请求过滤为Q个订单交易请求,能够将N个订单交易请求中的无效请求充分过滤掉,有效减少无效请求造成的流量负荷,降低对订单交易请求的处理压力,从而提高处理订单交易请求的稳定性和可靠性。
附图说明
图1是本申请实施例中请求控制系统的一个架构示意图;
图2是本申请实施例中请求处理的方法的一个实施例示意图;
图3是本申请实施例中请求处理的方法的另一个实施例示意图;
图4是本申请实施例中请求处理的方法的另一个实施例示意图;
图5是本申请实施例中请求处理的方法的另一个实施例示意图;
图6是本申请实施例中请求处理的方法的另一个实施例示意图;
图7是本申请实施例中请求处理的方法的另一个实施例示意图;
图8是本申请实施例中请求处理的方法的另一个实施例示意图;
图9是本申请实施例中请求处理的方法的一个原理流程示意图;
图10是本申请实施例中请求处理的方法的一个交易资格获取示意图;
图11是本申请实施例中请求处理的方法的一个请求过滤示意图;
图12是本申请实施例中请求处理的方法的一个库存数量同步示意图;
图13是本申请实施例中请求处理的装置的一个实施例示意图;
图14是本申请实施例中计算机设备的一个实施例示意图。
具体实施方式
本申请实施例提供了一种请求处理的方法、相关装置及设备,用于通过多级请求过滤方式,将N个订单交易请求经过层层过滤,得到Q个订单交易请求,能够将N个订单交易请求中的无效请求充分过滤掉,有效减少无效请求造成的流量负荷,降低对订单交易请求的处理压力,从而提高处理订单交易请求的稳定性和可靠性。
本申请的说明书和权利要求书及附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“对应于”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
应理解,本申请提供的请求处理的方法可以应用于通过交易请求在可交易对象的可交易时段内完成订单交易的场景中,作为示例,例如通过交易请求下单抢购促销时段内的促销洗衣液。作为另一个示例,例如通过交易请求限时秒杀的智能电冰箱。作为再一示例,例如通过交易请求限时低价抢购热带水果,在上述种种场景中,为了完成,现有技术中提供的解决方案为,通过采用异步方式,将高并发流量写入到消息队列中,同时利用异步服务的消费消息队列来处理消息请求,但是,异步处理秒杀流量时会接收过多的无效请求,并使大量无效请求进入到消息队列中,严重增加消息队列的处理消息请求的压力,容易导致系统崩溃的情况。
为了解决上述问题,本申请提出了一种请求处理的方法,该方法应用于图1所示的请求控制系统,请参阅图1,图1为本申请实施例中请求控制系统的一个架构示意图,如图所示,服务器通过获取用户从终端设备通过网关设备发送的目标时段内针对可交易对象的N个订单交易请求,服务器根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从N个订单交易请求中获取K个订单交易请求,进而,根据每个订单交易请求所携带的用户标识,从K个订单交易请求中获取P个订单交易请求,然后,从P个订单交易请求中获取Q个订单交易请求,并向交易服务器发送Q个订单交易请求。通过上述方式,实现了多级请求过滤方式,将N个订单交易请求过滤为K个订单交易请求,再将K个订单交易请求过滤为P个订单交易请求,最后将P个订单交易请求过滤为Q个订单交易请求,能够将N个订单交易请求中的无效请求充分过滤掉,有效减少无效请求造成的流量负荷,降低对订单交易请求的处理压力,从而提高处理订单交易请求的稳定性和可靠性。
其中,终端设备与网关设备之间通信连接,网关设备与服务器之间通信连接,服务器与交易服务器之间通信连接。
可以理解的是,图1中仅示出了一种终端设备,在实际场景中可以由更多种类的终端设备参与到请求处理的过程中,例如个人电脑(personal computer,PC),具体数量和种类因实际场景而定,具体此处不做限定。另外,图1中示出了一个服务器,但在实际场景中,也可以有多个服务器的参与,特别是在多模型训练交互的场景中,服务器的数量因实际场景而定,具体此处不做限定,以及,图1中示出的网关设备以及交易服务器的数量仅为一个示例,不用于限定网关设备以及交易服务器的数量,具体应当结合实际情况灵活确定数量。
需要注意的是,本实施例中,服务器或交易服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(content delivery network,CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等,但并不局限于此。
为了解决上述问题,本申请提出了一种请求处理的方法,该方法一般由服务器或终端设备执行,相应地,应用于请求处理的装置一般设置于服务器或终端设备中。
下面将对本申请中请求处理的方法进行介绍,请参阅图2以及图9,本申请实施例中请求处理的方法一个实施例包括:
在步骤S101中,获取目标时段内针对可交易对象的N个订单交易请求,其中,每个订单交易请求携带一个用户标识以及时间戳,可交易对象对应第一库存数量,N为大于1的整数;
在本实施例中,在可交易对象的目标时段内,用户可以在终端设备上针对可交易对象执行购买操作,则可以生成相应的订单交易请求,进而将订单交易请求通过网关设备接入服务器中,然后,服务器可以根据获取到的订单交易请求中携带的用户标识以及时间戳进行相应的处理,以完成订单交易请求的交易服务。
其中,可交易对象是指可交易的真实商品或虚拟商品,如话费、流量或视频网站会员等虚拟商品,或者如洗衣液、电视机或自行车等真实商品。
其中,目标时段是指根据实际应用需求针对可交易对象进行设置的可交易时段,该时段的时长通常都较为短暂,如10秒的秒杀时段、2个小时的促销时段,还可以是其他活动时段,如3个小时的拍卖时段等,此处不作具体限制。
其中,用户标识是用户身份标识码(identity,ID),用于指示购买可交易对象的用户身份,可以具体表现为整数(int)型的数字串,也可以具体表现为字符串等,此处不作具体限制。
其中,时间戳是订单交易请求的创建时间,如2021年4月2日20:01:30。
其中,第一库存数量是指可交易对象在库中实际存储的数量,即可交易对象的提供者拥有的可交易对象是实际数量。
其中,如图9所示,网关设备具体可以表现为视频接入网关,即视频接入层,还可以是其他网关设备,此处不作具体限制。视频接入网关可用于连接两个或更多个管理上的相异的网络/子网的节点,是一种存储转发设备,具有流媒体协议转换、流媒体分发服务、多路视频解码、视频画面分割等核心功能,还可以应用于在家庭或企业内的多个PC同时共享一个宽带网络接入。例如,家中的小孩可以接入网页来学习学校的课程,同时,另外一个家庭成员可以同时进行网上购物,通过视频接入网关可以实现多个人同时进行网络操作,而不需要等待其他人完成操作。
具体地,如图9所示,当有用户通过终端设备发起订单交易请求时,可以通过网关接口,如公共网关(Common Gateway Interface,CGI)接口,将订单交易请求接入网关设备,然后,通过网关设备将订单交易请求接入至服务器中,能够通过网关设备实现多个订单交易请求同时进行网络操作,从而使服务器能够在目标时段内获取到携带有用户标识以及时间戳的N个订单交易请求,以使后续可以根据用户标识以及时间戳对N个订单交易请求进行及时处理,能够在一定程度上提高接入订单交易请求的稳定性,从而在一定程度上提高处理订单交易请求的稳定性。
例如,假设有一种智能手机的秒杀活动,活动时间即目标时段为2021年3月21日20:00:00至20:01:00,目标时段内可以接收到100个用户预购买该种智能手机而发起的100个订单交易请求。
在步骤S102中,根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从N个订单交易请求中获取K个订单交易请求,其中,K为小于N的整数;
在本实施例中,在目标时段内获取到针对可交易对象的N个订单交易请求后,可以通过限流器来控制允许访问的订单交易请求的数量,进一步地,可以理解为是针对N个订单交易请求产生的流量,通过限流器来对流量访问的次数进行限制,使得在不超过系统的负载能力内,可以根据N个订单交易请求的时间戳的先后顺序,通过限流器来从N个订单交易请求中筛选出优先访问的K个订单交易请求,能够避免因大量的订单交易请求而导致超过可交易对象的库存数量,以及系统超负荷的情况,从而在一定程度上降低对订单交易请求的处理压力,从而提高处理订单交易请求的稳定性和可靠性。
具体地,如图9所示,当在目标时段内获取到针对可交易对象的N个订单交易请求后,可以看作是在请求接入层中对N个订单交易请求进行过滤,具体可以是根据系统的负载能力,采用限流器对获取到的N个订单交易请求进行限流,其中,限流器具体可以表现为北极星限流器,还可以是其他限流器,此处不作具体限制,可以理解的是,当订单交易请求的个数超过北极星限流器的限制时,为了保护系统的安全性以及稳定性,则可以对超过限制的订单交易请求进行拦截或返回,并生成超限提示等,或者,当订单交易请求的个数未超过北极星限流器的限制时,可以理解为,获取到的订单交易请求的个数在系统的可承载范围内,具体可以是按照每个订单交易请求的创建时间的先后顺序,依次通过北极星限流器,直至订单交易请求的访问量达到北极星限流器的上限,即从N个订单交易请求中筛选出北极星限流器允许访问或可负载的K个订单交易请求,其中,K个订单交易请求是根据实际使用的系统的负载能力,在北极星限流器上进行设置的,此处不作具体限制。
例如,假设在目标时间段内北极星限流器可以负载1000次的订单交易请求的访问,当获取到了2500个订单交易请求时,按照该2500个订单交易请求的时间戳的先后顺序,可以从该2500个订单交易请求中,筛选出第1至第1000个优先访问北极星限流器的1000个订单交易请求,并对第1001至第2500个访问的订单交易请求进行拦截。
在步骤S103中,根据每个订单交易请求所携带的用户标识,从K个订单交易请求中获取P个订单交易请求,其中,P个订单交易请求对应于P个不同的用户标识,P为小于K的整数;
在本实施例中,在获取到K个订单交易请求后,可以对K个订单交易请求进行进一步过滤,具体可以是通过对K个订单交易请求进行频率限制,可以理解为是针对发起K个订单交易请求的用户的限制,用于限制用户可以发起订单交易请求的次数,能够避免因用户频繁发起订单交易请求而导致支付掉单等无效请求出现,或不良用户的恶意刷单等情况,能够维护用户交易的公平性,保护系统处理订单交易请求的安全性,从而进一步保护系统处理订单交易请求的稳定性。
具体地,如图9所示,当获取到K个订单交易请求后,可以根据每个订单交易请求所携带的用户标识,将不满足频率限制的用户标识对应的订单交易请求从K个订单交易请求中过滤掉,具体可以表现为在目标时段内用户标识进行计数限制,通过统计每个用户标识出现的次数,然后,通过预设的次数来对每个用户标识出现的次数进行限制,可以理解为是限制一个用户标识在一定时间之内只能请求的次数,即当有一个用户标识出现的次数超过预设的次数限制时,可以对该用户标识对应订单交易请求进行拦截,或者,如果有P个用户标识的出现次数未超过预设的次数,则可以将该P个用户标识对应的P个订单交易请求从K个订单交易请求中筛选出来,并对超过预设的次数限制的用户标识对应的(K-P)个订单交易请求进行拦截,或从K个订单交易请求过滤掉该(K-P)个订单交易请求,能够有效减少因用户频繁发起订单交易请求而产生的无效请求或恶意请求,降低系统对订单交易请求的处理压力,从而提高处理订单交易请求的稳定性和可靠性。
例如,假设一种智能手机的秒杀活动,设置有一个用户ID限购一次,即一个用户标识只能发起一个订单交易请求,假设在活动时间内有100个订单交易请求,有85个用户标识都只发起了一个订单交易请求,则可以从该100个订单交易请求中筛选出该85个用户标识对应的85个订单交易请求。
在步骤S104中,从P个订单交易请求中获取Q个订单交易请求,其中,Q为小于或等于第一库存数量的整数,Q为小于P的整数;
在步骤S105中,向交易服务器发送Q个订单交易请求。
在本实施例中,在获取到P个订单交易请求后,可以对P个订单交易请求进行再进一步地过滤,具体可以是从P个订单交易请求中筛选出不超过可交易对象的第一库存数量的订单交易请求,可以理解为筛选出的订单交易请求具有可以进行交易结算的资格,如抢购资格,然后可以将具有交易结算的资格的订单交易请求发送至交易服务器,以使得用户能够通过该订单交易请求成功购买到可交易对象,能够避免出现超库存数量情况,还能够过滤不具备交易结算的资格的订单交易请求,降低系统对订单交易请求的处理压力,从而提高处理订单交易请求的稳定性和可靠性。
具体地,如图9所示,当获取到P个订单交易请求后,可以先根据可以交易请求的第一库存数量,确定P个订单交易请求中可以具备交易结算资格的请求数量,如Q个,进而,可以根据P个订单交易请求中每个订单交易请求的时间戳的先后顺序,将P个订单交易请求中的第一个至第Q个订单交易请求确定为具备交易结算资格的订单交易请求,即从P个订单交易请求中获取Q个订单交易请求,可以理解为将P个订单交易请求过滤为Q个订单交易请求,然后,可以将具备交易结算资格的Q个订单交易请求发送至交易服务器进行订单交易,以完成对可交易对象的交易。
例如,假设一种智能手机的秒杀活动,该智能手机的第一库存数量为5台,假设有50个订单交易请求,则可以按照订单交易请求的时间戳,将该50个订单交易请求中的第1个至第5个订单交易请求确定为可以购买这5台智能手机的5个订单交易请求。
在本申请实施例中,提供了一种请求处理的方法,通过上述方式,实现了多级请求过滤方式,将N个订单交易请求过滤为K个订单交易请求,再将K个订单交易请求过滤为P个订单交易请求,最后将P个订单交易请求过滤为Q个订单交易请求,能够将N个订单交易请求中的无效请求充分过滤掉,有效减少无效请求造成的流量负荷,降低对订单交易请求的处理压力,从而提高处理订单交易请求的稳定性和可靠性。
可选地,在上述图2对应的实施例的基础上,本申请实施例提供的请求处理的方法另一个可选实施例中,如图3所示,从P个订单交易请求中获取Q个订单交易请求,包括:
在步骤S301中,根据P个订单交易请求对第二库存数量进行依次递减,得到剩余库存数量,其中,第二库存数量为用于展示可交易对象的库存数量;
在步骤S302中,若剩余库存数量不为零,则根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从P个订单交易请求中获取Q个订单交易请求。
在本实施例中,在获取到P个订单交易请求后,如图11所示,本实施例可以采用第二库存数量自减的过滤以及结合令牌列表的过滤的两层漏斗的过滤方式,来将P个订单交易请求过滤为Q个订单交易请求,来降低系统对订单交易请求的处理压力,从而提高处理订单交易请求的稳定性和可靠性。
其中,第二库存数量是展示可交易对象的库存数量,可以理解为是系统上配置的每台机器上展示的可交易对象的库存数量的总和,例如,系统上配置有100台机器,假设每台机器都可以配置为100个库存,那么系统上的第二库存数量就会显示有10000个,可以理解为是具备交易结算资格的请求数量从100个扩展为10000个,能够在一定程度上提高对订单交易请求的负载能力。
其中,令牌列表的过滤是基于远程字典服务(Remote Dictionary Server,Redis)数据库中的链表(List)的令牌过滤,可以理解为是基于Redis的链表,创建关于可交易对象的第一库存数量的令牌链表,用于对订单交易请求进行过滤,其中,令牌链表中的令牌可以理解为是可交易对象的每一个库存。
具体地,如图10所示,当获取到P个订单交易请求后,可以对第二库存数量进行依次递减,如接收到一个订单交易请求,则第二库存数量就减1,即当前的剩余库存数量不为零,即先完全接收P个订单交易请求的访问,能够直观精确地反映第二库存数量的变化的同时,还能够通过设置第二库存数量来尽可能多的接收订单交易请求,能够在一定程度上满足更多的用户的交易需求,然后,可以根据令牌列表来对接收到P个订单交易请求进行过滤,即按照P个订单交易请求中每个订单交易请求的时间戳的先后顺序,如接收到一个订单交易请求,则令牌就减1,直至令牌列表中的令牌减为零,假设令牌总数为Q,则可以从P个订单交易请求中依次确定为具备交易结算资格的Q个订单交易请求,具体可以是通过Redis中的llen命令以及lpop命令来实现Redis的链表中令牌的递减,其中,采用lpop命令可以保证获取令牌(token)的原子性,能够在当剩余库存量不为零时,通过令牌列表来控制允许访问的订单交易请求的数量,降低系统对订单交易请求的处理压力,从而提高处理订单交易请求的稳定性和可靠性。
例如,假设一种智能手机的第一库存数量为100台,则可以同步至Redis中,以生成令牌数为100的令牌列表,假设系统上配置有100台机器,那么该智能手机的第二库存数量至少为10000台,假设接收到的订单交易请求为8000个,那么可以根据8000个订单交易请求来对第二库存数量自减,来完全接收该8000个订单交易请求,并得到剩余库存数量为2000台,然后,可以根据令牌列表中的100个令牌能够从8000个订单交易请求过滤出前100个订单交易请求。
可选地,在上述图3对应的实施例的基础上,本申请实施例提供的请求处理的方法另一个可选实施例中,如图4所示,该方法还包括:
在步骤S401中,若剩余库存数量为零,则向源端设备发送库存查询请求,以使源端设备根据库存查询请求查询可用库存数量,其中,源端设备用于提供可交易对象的库存数量;
在步骤S402中,接收源端设备发送的S个可用库存数量,并从(P-Q)个订单交易请求中获取S个订单交易请求,其中,S为小于第一库存数量的整数,S为小于(P-Q)的整数。
在本实施例中,当对第二库存数量进行自减,得到的剩余库存数量为零时,即从P跟订单交易请求中过滤了第二库存数量的个数的订单交易请求,然后,可以向源端设备发送库存查询请求,以使源端设备根据库存查询请求来查询交易结算时是否有超过预设的支付时间而未支付所对应的订单交易请求,若有,则将该订单交易请求对应的库存数量确定为可用库存数量,进而,可以根据获取到的可用库存数量,来从接收到的剩余订单交易请求中过滤出可用库存数量的订单交易请求,可以理解为是让更多的用户尽可能的获取到抢购资格以及减少可交易对象库存堆积的情况,从而在一定程度上提高处理订单交易请求的稳定性和可靠性。
具体地,如图10所示,当根据接收到的P订单交易请求进行第二库存数量进行自减,并得到的剩余库存数量为零时,则可以理解为系统从P个订单交易请求中,筛选出了第二库存数量的个数的订单交易请求,如第二库存数量为X个,其中,X小于P,则可以从P个订单交易请求中接收到X个订单交易请求,并从P个订单交易请求中获取到Q个订单交易请求,即Redis中的令牌列表为空,然后,通过向源端设备发送库存查询请求,以使源端设备根据库存查询请求查询可用库存数量,如S个可用库存数量,可以理解为Redis中的令牌列表为空,但是可用库存数量不为空,则可以根据S个可用库存数量,填充令牌列表中的令牌数,进而根据填充后的令牌列表中的令牌数,可以从(X-Q)个订单交易请求中过滤出前S个订单交易请求,并将该S个订单交易请求发送中交易服务器进行订单交易。
可以理解的是,上述根据填充后的令牌列表中的令牌数可以从(X-Q)个订单交易请求中过滤出前S个订单交易请求,与根据填充后的令牌列表中的令牌数可以从(P-Q)个订单交易请求中过滤出前S个订单交易请求相似,都是从中选取出第Q+1个至第Q+S个订单交易请求,此处不作具体限制。
例如,假设一种智能手机的第一库存数量为100台,则可以同步至Redis中,以生成令牌数为100的令牌列表,假设系统上配置有100台机器,那么该智能手机的第二库存数量至少为10000台,假设接收到的订单交易请求为12000个,那么可以根据12000个订单交易请求来对第二库存数量自减,可以接收该12000个订单交易请求中的前10000个订单交易请求,然后,可以根据令牌列表中的100个令牌能够从10000个订单交易请求过滤出前100个订单交易请求,但是,如果源端设备查询到该100个订单交易请求中有10个订单交易请求超过支付时间仍未支付,则可以将这10订单交易请求对应的库存数量10台,确定为可用库存数量10台并反馈给Redis,然后,可以通过读取Redis得到可用库存数量10台,则可以从接收到的9900个订单交易请求中过滤10订单交易请求。
可选地,在上述图3对应的实施例的基础上,本申请实施例提供的请求处理的方法另一个可选实施例中,如图5所示,该方法还包括:
在步骤S501中,向源端设备发送批次库存查询请求,以使源端设备根据批次库存查询请求查询当前批次剩余库存数量,其中,当前批次剩余库存数量用于表示可交易对象的每批次交易活动的当前剩余的库存数量;
在步骤S502中,接收源端设备发送的当前批次剩余库存数量,根据当前批次剩余库存数据更新第二库存数量。
在本实施例中,由于每一个可交易对象的每一次交易活动可以理解为一个批次库存的交易活动,为了避免在交易结算时因存在超过预设支付时间还未付款,而导致可交易对象有当前批次库存剩余,从而造成库存堆积,因此在向交易服务器发送将Q个订单交易请求后,可以向源端设备发送批次库存查询请求,来确认是否有库存剩余,若有剩余,则可以接收源端设备发送当前批次剩余库存数量,然后,根据当前批次剩余库存数量更新第二库存数量,以使后续能够根据更新的第二库存数量及时确定具有交易结算资格的请求,并发送至交易服务器进行交易,以避免可交易对象的库存堆积。
具体地,如图12所示,当向交易服务器发送将Q个订单交易请求后,可以先定时读取Redis中是否存在可交易对象的ID,来确保可交易对象是可继续交易的,进而,可以向源端设备发送批次库存查询请求,然后,源端设备根据批次库存查询请求也可以先确定是否存在可交易对象的ID,若存在,则继续查询当前批次ID,如batchID,然后,可以根据批次列表,如2037信息表,来确定当前批次剩余库存数量,并将查询到的当前批次剩余库存数量上传至Redis中,从而能够及时从Redis中准确读取到当前批次剩余库存数量,然后,能够根据当前批次剩余库存数量更新第二库存数量,不仅能够实现本地库存中的第二库存与源端设备中的当前批次剩余库存数量的同步,还能够使后续能够根据更新的第二库存数量及时确定具有交易结算资格的请求,并发送至交易服务器进行交易,以避免可交易对象的库存堆积。
例如,一个洗衣液的促销活动,假设洗衣液的第一库存数量为2000个,如果接收的订单交易请求为1800个,则批次剩余库存数量为200个,进而可以将原来的第二库存数量更新为200个。
可选地,在上述图3对应的实施例的基础上,本申请实施例提供的请求处理的方法另一个可选实施例中,如图6所示,该方法还包括:
在步骤S601中,从云端服务器中读取源端设备上传的第一库存数量,云端服务器用于存储可交易对象的库存数量;
在步骤S602中,根据第一库存数量配置第二库存数量,其中,第二库存数量大于第一库存数量;
在步骤S603中,将第二库存数量同步至云端服务器。
在本实施例中,在根据P个订单交易请求对第二库存数量进行依次递减,得到剩余库存数量之前,本实施例可以从云端服务器中读取源端设备上传的第一库存数量,然后,为了增强系统处理订单交易请求的健壮性,可以在根据第一库存数量配置第二库存数量时,基于第一库存数量增加一定的虚拟库存数量来得到第二库存数量,来扩充对订单交易请求的接收量,进而将第二库存数量同步至云端服务器,能够避免系统故障时,造成数据丢失的情况。
具体地,在根据P个订单交易请求对第二库存数量进行依次递减,得到剩余库存数量之前,可以从云端服务器中读取源端设备上传的第一库存数量,具体可以表现为从Redis中读取源端设备上传的第一库存数量,如图12所示,可以根据第一库存数量配置第二库存数量,如第二库存数量等于第一库存数量+M个,能够更加充分地扩展对订单交易请求的接收量,从而能够在一定程度上减少库存剩余的情况,然后,可以将配置好的第二库存数量同步至Redis中,以使源端设备能够实时检测第二库存数量,还能根据实际应用需求,将第二库存数量的配置调整写入Redis中,进而可以从Redis中读取第二库存数量的配置调整,来及时调整第二库存数量,以避免造成可交易对象的库存堆积的情况。
例如,假设远端服务器的实际库存只有100个库存,秒杀系统上配置有一百台机器,那么每台机器都可以配置为100+N个虚拟库存,如101个,那么秒杀系统上的本地库存会显示有10100个,可以使得10100个用户能够获取到抢购资格。
可选地,在上述图2对应的实施例的基础上,本申请实施例提供的请求处理的方法另一个可选实施例中,如图7所示,向交易服务器发送Q个订单交易请求包括:
在步骤S701中,获取i个可访问数量,其中,i个可访问数量来源于交易服务器,i为小于第一库存数量的整数;
在步骤S702中,根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从Q个订单交易请求中获取i个订单交易请求,并将i个订单交易请求发送至交易服务器;
在步骤S703中,当接收到交易服务器发送的可处理提示时,将(Q-i)个订单交易请求发送至交易服务器。
在本实施例中,在向交易服务器发送Q个订单交易请求时,本实施例可以先获取下游服务器的可访问量,如交易服务器的i个可访问数量,来表示交易服务器的负载能力,进而为了保护交易服务器的安全性和稳定性,然后,采用延时机制,将获取到的Q个订单交易请求划分为能够优先进行订单结算的i个订单交易请求,以及需要延迟处理的(Q-i)个订单交易请求,能够使得交易服务器能在负载能力范围为及时处理i个优先访问的订单交易请求,并能够在空闲状态,及时对已具备交易结算资格的(Q-i)个订单交易请求进行处理,不进行能够保护下游设备的稳定性,还能够减少可交易对象库存堆积的情况,从而在一定程度上提高处理订单交易请求的稳定性和可靠性。
具体地,如图9所示,当获取到Q个订单交易请求后,可以看作将Q个订单交易请求先从请求接入层透传至请求服务层中,根据交易服务器的负载能力,如交易服务器可承载的i个可访问数量来配置北极星限流器,然后,采用北极星限流器对具有交易结算资格的Q个订单交易请求进行限制,具体可以是当Q个订单交易请求未超过北极星限流器的限制时,可以将Q个订单交易请求都发送至交易服务器进行订单交易,或者,当Q个订单交易请求超过北极星限流器的限制时,可以根据每个订单交易请求所携带的时间戳的先后顺序,先从Q个订单交易请求中筛选出前i个订单交易请求发送至交易服务器,以使交易服务器优先处理该i个订单交易请求,并对超过北极星限流器限制的已具备交易结算资格的(Q-i)个订单交易请求进行延迟处理,如添加至延时消息队列中,还可以是其他处理方式,如对(Q-i)个订单交易请求进行缓存等,此处不做具体限制,然后,当接收到交易服务器反馈的空闲状态提示或可处理请求提示等,可以向交易服务器发送该(Q-i)个订单交易请求,以避免交易服务器超负荷,能够保护交易服务器的安全性和稳定性,从而提高系统处理订单交易请求的稳定性和可靠性。
例如,假设一交易服务器的负载的可访问数量为80次,具有交易结算资格的订单交易请求为100个,则可以先将前80个订单交易请求发送中交易服务器进行处理,当交易服务器处理完后,再将剩余的交易结算资格的20个订单交易请求发送至交易服务器进行处理。
可选地,在上述图2对应的实施例的基础上,本申请实施例提供的请求处理的方法另一个可选实施例中,如图8所示,根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从N个订单交易请求中获取K个订单交易请求,包括:
在步骤S801中,根据每个订单交易请求所携带的用户标识,从N个订单交易请求中获取不属于黑名单标识集的j个用户标识对应的j个订单交易请求,其中,j为小于N的整数;
在步骤S802中,按照每个订单交易请求所携带的时间戳的先后顺序,从j个订单交易请求中获取K个订单交易请求。
在本实施例中,在通过网关设备接收到用户发起的N个订单交易请求后,如图9所示,可以采用登录校验以及安全校验的中的任一方式对N个订单交易请求来进行安全过滤,或采用二者结合的方式,采用其他检验的方式,此处不作具体限制,以从N个订单交易请求中获取j个订单交易请求,然后可以按照每个订单交易请求所携带的时间戳的先后顺序,来对j订单交易请求进行过滤,以从j个订单交易请求中获取K个订单交易请求,以使得获取到的K个订单交易请求安全性高,从而在一定程度上提高系统处理订单交易请求的稳定性和安全性。
具体地,在用户发起订单交易请求之前,可以先对N个订单交易请求采用登录校验的方式进行一层过滤,具体可以表现为token验证的方式,还可以是其他验证方式,此处不作具体限制,token验证具体可以是通过用户发出登录请求,该登录请求可以携带用户名和密码发送到服务器中进行验证,当服务器验证成功时,会在后台生成一个token返回给客户端,然后,客户端将token存储到文本文件cookie中,同时,服务器将token存储到redis中,可以设置存储token的有效期,以使后续客户端的每次请求资源,如发起订单交易请求时,都必须携带token,可以使得服务器能够根据接收到订单交易请求首先校验是否携带token,以及token是否和redis中的token匹配,若不存在或不匹配y个token,则可以将这y个token对应的y个订单交易请求直接拦截并向客户端返回错误信息,若存在或匹配到z个token,则确定该z个token对应的z个订单交易请求通过登录校验,属于初步安全的订单交易请求,其中,y或z均为小于N的整数。
进一步地,可以再对z个订单交易请求采用安全校验的方式进行一层过滤,具体可以表现为黑白名单匹配检验的方式,还可以是其他校验形式,此处不作具体限制,具体可以是订单交易请求携带的用户标识与预设的黑名单或预设白名单中的用户标识进行匹配,其中,预设的黑名单是根据使用应用请求采用到不合法或有违规行为的用户标识的集合,预设的白名单是根据使用应用请求采用到合法或符合规定行为的用户标识的集合,若与白名单中的j个用户标识相匹配,或黑名单中不存在相匹配的j个用户标识,则可以确定该j个用户标识对应的j个订单交易请求通过安全校验,属于较为安全的订单交易请求。
进一步地,可以进一步对j个订单交易请求采用北极星限流的方式进行一层过滤,可以可以是按照每个订单交易请求所携带的时间戳的先后顺序,从j个订单交易请求中获取K个订单交易请求,该过滤方式与步骤S102根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从N个订单交易请求中获取K个订单交易请求的方式相似,此处不再赘余。
例如,假设接收到100个订单交易请求,如果与Redis中的相匹配的token有95个,则确定可以将该95个token对应的95个订单交易请求通过登录校验,进而,当95个订单交易请求中有不属于预设黑名单的用户标识89个,则可以将该89个用户标识对应的89个订单交易请求通过安全校验,然后,如果北极星限流器的上限为80个,则可以按照该89订单交易请求的时间戳的先后顺序,从该89订单交易请求中筛选出第1个至第80个订单交易请求,得到过滤后的80个订单交易请求。
下面对本申请中的请求处理的装置进行详细描述,请参阅图13,图13为本申请实施例中请求处理的装置的一个实施例示意图,请求处理的装置20包括:
获取单元201,用于获取目标时段内针对可交易对象的N个订单交易请求,其中,每个订单交易请求携带一个用户标识以及时间戳,可交易对象对应第一库存数量,N为大于1的整数;
处理单元202,用于根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从N个订单交易请求中获取K个订单交易请求,其中,K为小于N的整数;
处理单元202,还用于根据每个订单交易请求所携带的用户标识,从K个订单交易请求中获取P个订单交易请求,其中,P个订单交易请求对应于P个不同的用户标识,P为小于K的整数;
处理单元202,还用于从P个订单交易请求中获取Q个订单交易请求,其中,Q为小于或等于第一库存数量的整数,Q为小于P的整数;
发送单元203,用于向交易服务器发送Q个订单交易请求。
可选地,在上述图13对应的实施例的基础上,本申请实施例提供的请求处理的装置的另一实施例中,处理单元202具体可以用于:
根据P个订单交易请求对第二库存数量进行依次递减,得到剩余库存数量,其中,第二库存数量为用于展示可交易对象的库存数量;
若剩余库存数量不为零,则根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从P个订单交易请求中获取Q个订单交易请求。
可选地,在上述图13对应的实施例的基础上,本申请实施例提供的请求处理的装置的另一实施例中,
发送单元203,还用于若剩余库存数量为零,则向源端设备发送库存查询请求,以使源端设备根据库存查询请求查询可用库存数量,其中,源端设备用于提供可交易对象的库存数量;
处理单元202,还用于接收源端设备发送的S个可用库存数量,并从(P-Q)个订单交易请求中获取S个订单交易请求,其中,S为小于第一库存数量的整数,S为小于(P-Q)的整数。
可选地,在上述图13对应的实施例的基础上,本申请实施例提供的请求处理的装置的另一实施例中,
发送单元203,还用于向源端设备发送批次库存查询请求,以使源端设备根据批次库存查询请求查询当前批次剩余库存数量,其中,当前批次剩余库存数量用于表示可交易对象的每批次交易活动的当前剩余的库存数量;
处理单元202,还用于接收当前批次剩余库存数量,根据当前批次剩余库存数据更新第二库存数量。
可选地,在上述图13对应的实施例的基础上,本申请实施例提供的请求处理的装置的另一实施例中,
获取单元201,还用于从云端服务器中读取源端设备上传的第一库存数量,云端服务器用于存储可交易对象的库存数量;
处理单元202,还用于根据第一库存数量配置第二库存数量,其中,第二库存数量大于第一库存数量;
处理单元202,还用于将第二库存数量同步至云端服务器。
可选地,在上述图13对应的实施例的基础上,本申请实施例提供的请求处理的装置的另一实施例中,发送单元203具体可以用于:
获取i个可访问数量,其中,i个可访问数量来源于交易服务器,i为小于第一库存数量的整数;
根据每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从Q个订单交易请求中获取i个订单交易请求,并将i个订单交易请求发送至交易服务器;
当接收到交易服务器发送的可处理提示时,将(Q-i)个订单交易请求发送至交易服务器。
可选地,在上述图13对应的实施例的基础上,本申请实施例提供的请求处理的装置的另一实施例中,处理单元202具体可以用于:
根据每个订单交易请求所携带的用户标识,从N个订单交易请求中获取不属于黑名单标识集的j个用户标识对应的j个订单交易请求,其中,j为小于N的整数;
按照每个订单交易请求所携带的时间戳的先后顺序,从j个订单交易请求中获取K个订单交易请求。
本申请另一方面提供了另一种计算机设备示意图,如图14所示,图14是本申请实施例提供的一种计算机设备结构示意图,该计算机设备300可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上中央处理器(central processing units,CPU)310(例如,一个或一个以上处理器)和存储器320,一个或一个以上存储应用程序331或数据332的存储介质330(例如一个或一个以上海量存储设备)。其中,存储器320和存储介质330可以是短暂存储或持久存储。存储在存储介质330的程序可以包括一个或一个以上模块(图示没标出),每个模块可以包括对计算机设备300中的一系列指令操作。更进一步地,中央处理器310可以设置为与存储介质330通信,在计算机设备300上执行存储介质330中的一系列指令操作。
计算机设备300还可以包括一个或一个以上电源340,一个或一个以上有线或无线网络接口350,一个或一个以上输入输出接口360,和/或,一个或一个以上操作系统333,例如Windows ServerTM,Mac OS XTM,UnixTM,LinuxTM,FreeBSDTM等等。
上述计算机设备300还用于执行如图2至图8对应的实施例中的步骤。
本申请的另一方面提供了一种计算机可读存储介质,计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行如图2至图8所示实施例描述的方法中的步骤。
本申请的另一方面提供了一种包含指令的计算机程序产品当其在计算机或处理器上运行时,使得所述计算机或处理器执行如图2至图8所示实施例描述的方法中的步骤。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(read-only memory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
Claims (10)
1.一种请求处理的方法,其特征在于,包括:
获取目标时段内针对可交易对象的N个订单交易请求,其中,每个订单交易请求携带一个用户标识以及时间戳,所述可交易对象对应第一库存数量,所述N为大于1的整数;
根据所述每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从所述N个订单交易请求中获取K个订单交易请求,其中,所述K为小于所述N的整数;
根据所述每个订单交易请求所携带的用户标识,从所述K个订单交易请求中获取P个订单交易请求,其中,所述P个订单交易请求对应于P个不同的用户标识,所述P为小于所述K的整数;
从所述P个订单交易请求中获取Q个订单交易请求,其中,所述Q为小于或等于所述第一库存数量的整数,所述Q为小于所述P的整数;
向交易服务器发送所述Q个订单交易请求。
2.根据权利要求1所述的方法,其特征在于,所述从所述P个订单交易请求中获取Q个订单交易请求,包括:
根据所述P个订单交易请求对第二库存数量进行依次递减,得到剩余库存数量,其中,所述第二库存数量为用于展示所述可交易对象的库存数量;
若所述剩余库存数量不为零,则根据所述每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从所述P个订单交易请求中获取所述Q个订单交易请求。
3.根据权利要求2所述的方法,其特征在于,所述根据所述P个订单交易请求对第二库存数量进行依次递减,得到剩余库存数量之后,所述方法还包括:
若所述剩余库存数量为零,则向源端设备发送库存查询请求,以使所述源端设备根据所述库存查询请求查询可用库存数量,其中,所述源端设备用于提供所述可交易对象的库存数量;
接收所述源端设备发送的S个可用库存数量,并从(P-Q)个订单交易请求中获取S个订单交易请求,其中,所述S为小于所述第一库存数量的整数,所述S为小于所述(P-Q)的整数。
4.根据权利要求2所述的方法,其特征在于,所述若所述剩余库存数量不为零,则根据所述每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从所述P个订单交易请求中获取具有交易资格的所述Q个订单交易请求之后,所述方法还包括:
向所述源端设备发送批次库存查询请求,以使所述源端设备根据所述批次库存查询请求查询当前批次剩余库存数量,其中,所述当前批次剩余库存数量用于表示所述可交易对象的每批次交易活动的当前剩余的库存数量;
接收所述源端设备发送的所述当前批次剩余库存数量,根据所述当前批次剩余库存数据更新所述第二库存数量。
5.根据权利要求2所述的方法,其特征在于,所述根据所述P个订单交易请求对第二库存数量进行依次递减,得到剩余库存数量之前,所述方法还包括:
从云端服务器中读取所述所述源端设备上传的所述第一库存数量,所述云端服务器用于存储所述可交易对象的库存数量;
根据所述所述第一库存数量配置所述第二库存数量,其中,所述第二库存数量大于所述所述第一库存数量;
将所述第二库存数量同步至所述云端服务器。
6.根据权利要求1所述的方法,其特征在于,所述向交易服务器发送所述Q个订单交易请求包括:
获取i个可访问数量,其中,所述i个可访问数量来源于所述交易服务器,所述i为小于所述第一库存数量的整数;
根据所述每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从所述Q个订单交易请求中获取i个订单交易请求,并将所述i个订单交易请求发送至所述交易服务器;
当接收到所述交易服务器发送的可处理提示时,将(Q-i)个订单交易请求发送至所述交易服务器。
7.根据权利要求1所述的方法,其特征在于,所述根据所述每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从所述N个订单交易请求中获取K个订单交易请求,包括:
根据所述每个订单交易请求所携带的用户标识,从所述N个订单交易请求中获取不属于黑名单标识集的j个用户标识对应的j个订单交易请求,其中,所述j为小于所述N的整数;
按照所述每个订单交易请求所携带的时间戳的先后顺序,从所述j个订单交易请求中获取所述K个订单交易请求。
8.一种高并发秒杀请求的处理装置,其特征在于,包括:
获取单元,用于获取目标时段内针对可交易对象的N个订单交易请求,其中,每个订单交易请求携带一个用户标识以及时间戳,所述可交易对象对应第一库存数量,所述N为大于1的整数;
处理单元,用于根据所述每个订单交易请求所携带的时间戳,按照时间戳的先后顺序,从所述N个订单交易请求中获取K个订单交易请求,其中,所述K为小于所述N的整数;
所述处理单元,还用于根据所述每个订单交易请求所携带的用户标识,从所述K个订单交易请求中获取P个订单交易请求,其中,所述P个订单交易请求对应于P个不同的用户标识,所述P为小于所述K的整数;
所述处理单元,还用于从所述P个订单交易请求中获取Q个订单交易请求,其中,所述Q为小于或等于所述第一库存数量的整数,所述Q为小于所述P的整数;
发送单元,用于向交易服务器发送所述Q个订单交易请求。
9.一种计算机设备,其特征在于,包括:存储器、收发器、处理器以及总线系统;
其中,所述存储器用于存储程序;
所述处理器用于执行所述存储器中的程序时实现如权利要求1至7中任一项所述的方法;
所述总线系统用于连接所述存储器以及所述处理器,以使所述存储器以及所述处理器进行通信。
10.一种计算机可读存储介质,包括指令,当其在计算机上运行时,使得计算机执行如权利要求1至7中任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110814715.0A CN115641180A (zh) | 2021-07-19 | 2021-07-19 | 一种请求处理的方法、相关装置及设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110814715.0A CN115641180A (zh) | 2021-07-19 | 2021-07-19 | 一种请求处理的方法、相关装置及设备 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115641180A true CN115641180A (zh) | 2023-01-24 |
Family
ID=84939531
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110814715.0A Pending CN115641180A (zh) | 2021-07-19 | 2021-07-19 | 一种请求处理的方法、相关装置及设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115641180A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116204543A (zh) * | 2023-05-04 | 2023-06-02 | 天津金城银行股份有限公司 | 一种票据保活的方法、系统、计算机和可读存储介质 |
| CN116503000A (zh) * | 2023-06-27 | 2023-07-28 | 广州晨安网络科技有限公司 | 一种制造业订单库存erp管理方法及系统 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110599277A (zh) * | 2018-06-12 | 2019-12-20 | 北京京东尚科信息技术有限公司 | 一种库存扣减方法和装置 |
| CN112954004A (zh) * | 2021-01-26 | 2021-06-11 | 广州华多网络科技有限公司 | 秒杀活动服务响应方法及其装置、设备与介质 |
-
2021
- 2021-07-19 CN CN202110814715.0A patent/CN115641180A/zh active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110599277A (zh) * | 2018-06-12 | 2019-12-20 | 北京京东尚科信息技术有限公司 | 一种库存扣减方法和装置 |
| CN112954004A (zh) * | 2021-01-26 | 2021-06-11 | 广州华多网络科技有限公司 | 秒杀活动服务响应方法及其装置、设备与介质 |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116204543A (zh) * | 2023-05-04 | 2023-06-02 | 天津金城银行股份有限公司 | 一种票据保活的方法、系统、计算机和可读存储介质 |
| CN116204543B (zh) * | 2023-05-04 | 2023-08-08 | 天津金城银行股份有限公司 | 一种票据保活的方法、系统、计算机和可读存储介质 |
| CN116503000A (zh) * | 2023-06-27 | 2023-07-28 | 广州晨安网络科技有限公司 | 一种制造业订单库存erp管理方法及系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11113244B1 (en) | Integrated data pipeline | |
| US9218227B2 (en) | Method and system for user-designed application deployment | |
| CN108418821A (zh) | 基于Redis与Kafka的线上抢购系统高并发场景处理方法及装置 | |
| CN103903156A (zh) | 一种在社交网络中进行抢位促销的系统和方法 | |
| CN110084699A (zh) | 交易记录的聚合方法、装置、交易列表系统及存储介质 | |
| WO2020156008A1 (zh) | 基于区块链的信息分发方法和系统 | |
| US12231351B2 (en) | Determining resource usage metrics for cloud computing systems | |
| TW202101351A (zh) | 用於促進並行交易之方法、交易管理裝置及電腦可讀取媒體 | |
| CN106998314B (zh) | 账户交互方法及装置 | |
| KR20200119671A (ko) | 디지털 컨텐츠의 이용 권리 증서를 발행 수량 만큼 유통시키는 방법, 상기 방법을 수행하는 서버, 및 상기 방법을 실행하기 위하여 매체에 저장된 컴퓨터 프로그램 | |
| CN112995244B (zh) | 一种签约代扣方法、资源访问方法及设备 | |
| CN114169863A (zh) | 一种签约方法、装置、电子设备及计算机可读介质 | |
| CN115641180A (zh) | 一种请求处理的方法、相关装置及设备 | |
| CN108122124B (zh) | 信息推送方法、平台及系统 | |
| CN104537563B (zh) | 一种额度数据处理方法及服务器 | |
| US10885565B1 (en) | Network-based data discovery and consumption coordination service | |
| CN108874836B (zh) | 转移电子券的方法和装置 | |
| US20190102778A1 (en) | Secure online transaction system and method therefor | |
| CN110599184A (zh) | 用于网络服务账号交易的方法和装置、服务器和存储介质 | |
| CN118537125A (zh) | 确定订单簿的方法和装置 | |
| US20130191265A1 (en) | Cloud-based system for performing online trading | |
| CN116362731A (zh) | 一种业务处理方法、装置、电子设备及计算机可读介质 | |
| CN113362127A (zh) | 具有高可用性的二手车竞价系统 | |
| CA3195744A1 (en) | Client-side device bloom filter mapping | |
| WO2021125107A1 (ja) | 制御方法、装置、および、プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |