CN111260272A - 基于库存响应用户请求的方法、装置、设备及存储介质 - Google Patents

基于库存响应用户请求的方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN111260272A
CN111260272A CN201911215499.7A CN201911215499A CN111260272A CN 111260272 A CN111260272 A CN 111260272A CN 201911215499 A CN201911215499 A CN 201911215499A CN 111260272 A CN111260272 A CN 111260272A
Authority
CN
China
Prior art keywords
inventory
frequency
processing
server
target
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
Application number
CN201911215499.7A
Other languages
English (en)
Inventor
智伟
刘彩霞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Taikang Insurance Group Co Ltd
Original Assignee
Taikang Insurance Group Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Taikang Insurance Group Co Ltd filed Critical Taikang Insurance Group Co Ltd
Priority to CN201911215499.7A priority Critical patent/CN111260272A/zh
Publication of CN111260272A publication Critical patent/CN111260272A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • G06Q30/0633Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635Processing of requisition or of purchase orders

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请实施例提供了一种基于库存响应用户请求的方法、装置、设备及存储介质,旨在提高对用户请求的处理效率。所述方法应用于服务端,所述方法包括:获得所述服务端的处理频次,并根据所述处理频次和库存分段的目标处理频次,确定库存分段的目标数量;将所述服务端的总库存拆分成所述目标数量个库存分段;在获得多个用户请求后,将所述多个用户请求分配给所述目标数量个库存分段进行并行处理;其中,针对每个库存分段,处理分配给该库存分段的用户请求,包括:将该库存分段与该用户请求所对应的用户库存分别锁定;根据该用户请求,对锁定的库存分段和用户库存执行库存计算操作。

Description

基于库存响应用户请求的方法、装置、设备及存储介质
技术领域
本申请实施例涉及互联网技术领域,尤其涉及一种基于库存响应用户请求的方法、装置、设备及存储介质。
背景技术
随着互联网技术的发展和终端设备的普及,越来越多的终端用户参与至线上交易活动。在交易期间,用户通过终端设备与服务端(电商平台)通信,旨在实现货币与商品之间的交换,或者实现积分与商品之间的交换,再或者实现积分与积分之间的交换。考虑到商品或积分具有一定的财务属性,或者为了向用户显示正确的商品库存,服务端需要严格确保商品库存或积分库存在交易期间实时准确。其中,商品库存和积分库存可以是服务端自身的商品库存和积分库存,也可以是入驻服务端的商家的商品库存和积分库存。
为此,相关技术提出利用分布式锁,将服务端的库存数据串行化处理。具体地,针对每个用户请求,首先检验该用户请求是否获得锁,在该用户请求获得了锁的情况下,将该用户请求所对应的用户相关数据和服务端库存锁定,然后进行交易处理,最后在交易完成后对用户相关数据和服务端库存进行解锁。如此,解锁后的服务端库存可参与至针对下一个用户请求的处理进程中。
采用相关技术提出的上述方式处理用户请求时,虽然能确保商品库存或积分库存在交易期间实时准确。但是在用户请求并发量大的情况下,例如在商品秒杀场景下,或者例如在限时积分红包领取场景下,采用上述方式处理用户请求的效率较低,导致用户请求响应时间过长。
发明内容
本申请实施例提供一种基于库存响应用户请求的方法、装置、设备及存储介质,旨在提高服务端对用户请求的处理效率。
本申请实施例第一方面提供了一种基于库存响应用户请求的方法,应用于服务端,所述方法包括:
获得所述服务端的处理频次,并根据所述处理频次和库存分段的目标处理频次,确定库存分段的目标数量;
将所述服务端的总库存拆分成所述目标数量个库存分段;
在获得多个用户请求后,将所述多个用户请求分配给所述目标数量个库存分段进行并行处理;
其中,针对每个库存分段,处理分配给该库存分段的用户请求,包括:将该库存分段与该用户请求所对应的用户库存分别锁定;根据该用户请求,对锁定的库存分段和用户库存执行库存计算操作。
可选地,所述获得所述服务端的处理频次,并根据所述处理频次和库存分段的目标处理频次,确定库存分段的目标数量,包括:
周期性地获得服务端的处理频次;
确定当前周期所获得的处理频次与上一周期所获得的历史处理频次是否处于同一个频次水平;
在所述处理频次和所述历史处理频次处于不同的频次水平的情况下,根据所述处理频次和库存分段的目标处理频次,确定在当前周期库存分段所对应的目标数量。
可选地,所述方法还包括:
在所述处理频次和所述历史处理频次处于同一个频次水平的情况下,结束当前周期的确定库存分段的目标数量的流程。
可选地,多个不同的频次水平分别由多个不同的频次区间所表征;所述方法还包括:
根据一段时间内处理一个用户请求的耗时时间,和/或,一段时间内重新确定库存分段的目标数量的次数,对所述多个频次区间各自的频次范围进行调整。
可选地,在根据所述处理频次和库存分段的目标处理频次,确定在当前周期库存分段所对应的目标数量之前,所述方法还包括:
将所述上一周期所获得的历史处理频次和上一周期所确定的库存分段的历史数量的比值,确定为所述库存分段的目标处理频次。
可选地,所述将所述服务端的总库存拆分成所述目标数量个库存分段,包括:
将上一周期所确定的各个库存分段分别锁定;
根据各个被锁定的库存分段,确定所述服务端的总库存;
将所述服务端的总库存拆分成当前周期所确定的目标数量个库存分段。
可选地,在确定库存分段的目标数量后,所述方法还包括:
将库存分段的目标数量存入内存数据库;
所述在获得多个用户请求后,将所述多个用户请求分配给所述多个库存分段进行并行处理,包括:
在获得多个用户请求后,针对每个用户请求,从所述内存数据库中读取所述目标数量;
根据所读取的所述目标数量确定一个分段编号,将该用户请求分配给该分段编号所对应的库存分段。
本申请实施例第二方面提供一种基于库存响应用户请求的装置,应用于服务端,所述装置包括:
目标数量确定模块,用于获得所述服务端的处理频次,并根据所述处理频次和库存分段的目标处理频次,确定库存分段的目标数量;
总库存拆分模块,用于将所述服务端的总库存拆分成所述目标数量个库存分段;
用户请求分配模块,用于在获得多个用户请求后,将所述多个用户请求分配给所述目标数量个库存分段进行并行处理;
用户请求处理模块,用于针对每个库存分段,处理分配给该库存分段的用户请求,包括:将该库存分段与该用户请求所对应的用户库存分别锁定;根据该用户请求,对锁定的库存分段和用户库存执行库存计算操作。
可选地,所述目标数量确定模块包括:
处理频次获得子模块,用于周期性地获得服务端的处理频次;
频次水平确定子模块,用于确定当前周期所获得的处理频次与上一周期所获得的历史处理频次是否处于同一个频次水平;
目标数量确定子模块,用于在所述处理频次和所述历史处理频次处于不同的频次水平的情况下,根据所述处理频次和库存分段的目标处理频次,确定在当前周期库存分段所对应的目标数量。
可选地,所述装置还包括:
流程结束模块,用于在所述处理频次和所述历史处理频次处于同一个频次水平的情况下,结束当前周期的确定库存分段的目标数量的流程。
可选地,多个不同的频次水平分别由多个不同的频次区间所表征;所述装置还包括:
频次区间调整模块,用于根据一段时间内处理一个用户请求的耗时时间,和/或,一段时间内重新确定库存分段的目标数量的次数,对所述多个频次区间各自的频次范围进行调整。
可选地,所述装置还包括:
目标处理频次确定模块,用于在根据所述处理频次和库存分段的目标处理频次,确定在当前周期库存分段所对应的目标数量之前,将所述上一周期所获得的历史处理频次和上一周期所确定的库存分段的历史数量的比值,确定为所述库存分段的目标处理频次。
可选地,所述总库存拆分模块包括:
库存分段锁定子模块,用于将上一周期所确定的各个库存分段分别锁定;
总库存确定子模块,用于根据各个被锁定的库存分段,确定所述服务端的总库存;
总库存拆分子模块,用于将所述服务端的总库存拆分成当前周期所确定的目标数量个库存分段。
可选地,所述装置还包括:
目标数量存储模块,用于在确定库存分段的目标数量后,将库存分段的目标数量存入内存数据库;
所述用户请求分配模块包括:
目标数量读取子模块,用于在获得多个用户请求后,针对每个用户请求,从所述内存数据库中读取所述目标数量;
用户请求分配子模块,用于根据所读取的所述目标数量确定一个分段编号,将该用户请求分配给该分段编号所对应的库存分段。
本申请实施例第三方面提供一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时,实现如本申请第一方面所述的方法中的步骤。
本申请实施例第四方面提供一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行时实现本申请第一方面所述的方法的步骤。
采用本申请实施例提供的基于库存响应用户请求的方法,根据服务端的处理频次和库存分段的目标处理频次,合理确定出库存分段的目标数量,然后将服务端的总库存拆分成所述目标数量个库存分段。如此,在服务端获得多个用户请求后,可以将多个用户请求分配给所述目标数量个库存分段。其中,针对每个库存分段,服务端在处理分配给该库存分段的用户请求时,首先将该库存分段与该用户请求所对应的用户库存分别锁定,然后根据该用户请求,对锁定的库存分段和用户库存执行库存计算操作,以确保库存分段实时准确,进而确保了服务端总库存的实时准确。
因此,采用本申请实施例提供的基于库存响应用户请求的方法,在确保服务端总库存实时准确的前提下,利用多个库存分段实现了对多个用户请求的并行处理,提高了对用户请求的处理效率。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对本申请实施例的描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1是本申请一实施例提出的基于库存响应用户请求的方法的流程图;
图2是本申请另一实施例提出的基于库存响应用户请求的方法的流程图;
图3是本申请一实施例提出的确定库存分段的目标数量的流程图;
图4(a)是本申请一实施例提出的确定处理频次与历史处理频次是否处于同一个频次水平的示意图;
图4(b)是本申请另一实施例提出的确定处理频次与历史处理频次是否处于同一个频次水平的示意图;
图5是本申请一实施例提出的总库存分段的流程图;
图6是本申请一实施例提出的总库存分段的示意图;
图7是本申请一实施例提出的基于库存响应用户请求的装置的示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例,均应属于本申请保护的范围。
在互联网技术领域的线上交易场景中,通常涉及货币与商品之间的交换,或者积分与商品之间的交换,再或者积分与积分之间的交换。其中,交换操作包括但不限于:交易、兑换、抽奖等等。以抽奖为例,用户以50积分作为抽奖门票,通过参与抽奖活动可能获得:小礼品、抵扣券、20积分、100积分等等。如果在抽奖活动获得了100积分,则相当于用户通过50积分交换到了100积分。
考虑到商品或积分具有一定的财务属性,或者为了向用户显示正确的商品库存,再或者出于其他目的,服务端需要严格确保商品库存或积分库存在交易期间实时准确。例如防止在交易期间,商品或积分被多发、少发、漏发或者错发。
为了达到确保商品库存或积分库存在交易期间实时准确的目的,相关技术提出利用分布式锁,将服务端的库存数据串行化处理。即针对每个用户请求,首先检验该用户请求是否获得锁,在该用户请求获得了锁的情况下,将该用户请求所对应的用户相关数据和服务端库存锁定,然后进行交易处理,最后在交易完成后对用户相关数据和服务端库存进行解锁。如此,解锁后的服务端库存可参与至针对下一个用户请求的处理进程中。
采用相关技术提出的上述方式处理用户请求时,虽然能确保商品库存或积分库存在交易期间实时准确。但是在用户请求并发量大的情况下,例如在商品秒杀场景下,或者例如在限时积分红包领取场景下,采用上述方式处理用户请求的效率较低,导致用户请求响应时间过长。
为此,本申请实施例提出基于库存响应用户请求的方法,旨在提高对用户请求的处理效率。参考图1,图1是本申请一实施例提出的基于库存响应用户请求的方法的流程图。如图1所示,该方法包括以下步骤:
步骤S11:获得所述服务端的处理频次,并根据所述处理频次和库存分段的目标处理频次,确定库存分段的目标数量;
步骤S12:将所述服务端的总库存拆分成所述目标数量个库存分段;
步骤S13:在获得多个用户请求后,将所述多个用户请求分配给所述目标数量个库存分段进行并行处理。
其中,针对每个库存分段,处理分配给该库存分段的用户请求,包括:将该库存分段与该用户请求所对应的用户库存分别锁定;根据该用户请求,对锁定的库存分段和用户库存执行库存计算操作。
其中,服务端的处理频次可以具体指:吞吐量TPS(Transactions Per Second),即系统在单位时间内处理请求的数量。但不局限于此,例如服务端的处理频次还可以具体指:每秒查询率QPS(Query Per Second)、每秒请求并发数量等等。
以服务端的处理频次具体是指吞吐量TPS为例,服务端可以通过TPS监控工具(例如开源分析工具tcprstat)实时获得服务端的吞吐量TPS。
其中,库存分段的目标处理频次可以是人为指定的。例如,监控人员根据服务端的硬件性能或软件性能等,指定与服务端性能相对应的目标处理频次。或者,库存分段的目标处理频次也可以通过其他方式确定,如本申请后文所记载的内容,在周期性地获得服务端的处理频次,从而确定当前周期是否对服务端的总库存重新分段的实施例中,可以将上一周期所获得的历史处理频次和上一周期所确定的库存分段的历史数量的比值,确定为库存分段的目标处理频次。再或者,库存分段的目标处理频次也可以是:在对服务端的总库存的当前的处理频次。
示例地,在确定库存分段的目标数量时,可以将处理频次与目标处理频次之间的比值确定为库存分段的目标数量。如此,每个库存分段以目标处理频次的速率处理用户请求,各个库存分段的处理频次的加和与所获得的服务端的处理频次相当,因此能满足服务端对处理频次的要求。
其中,服务端的总库存可以是服务端自身的总库存。以商业保险平台为例,该平台支持用户积分库存与平台总积分库存之间的积分增减操作。例如该平台提供多个积分红包,并允许用户领取这些积分红包。如此,每当一份积分红包被领取,平台总积分库存中扣减相应数量的积分,而领取到积分红包的用户的用户积分库存中增加相应数量的积分。其中,平台总积分库存是服务端自身的积分库存。
或者,服务端的总库存也可以是入驻服务端的商家的总库存。以电商平台为例,该电商平台内入驻有多个商家,其中某一商家具有一个商家总积分库存,该商家允许消费者利用积分兑换商品。如此,当某一消费者利用其消费者积分库存中的部分积分兑换到该商家的商品时,该消费者的消费者积分库存中扣减相应数量的积分,而该商家的商家总积分库存中增加相应数量的积分。由于该商家的经营活动依靠电商平台的技术支持,该商家的商家总积分库存通常由电商平台管理运行,因此该商家的商家总积分库存可视为服务端的积分库存。
其中,在将服务端的总库存拆分成目标数量个库存分段时,为了确保总库存在拆分时依然保持实时准确,可以首先建立目标数量个库存分段,然后锁定各个库存分段和总库存,然后将总库存的库存数据拆分给各个库存分段,最后释放各个库存分段的锁。
在某些实施例中,为了尽可能地实现负载均衡,可以将总库存的库存数据平均地拆分给多个库存分段。示例地,假设总库存的库存数据是“96000积分”,库存分段的数量为12个,则每个库存分段所平均分配的库存数据是8000积分。
在某些实施例中,具体可以利用基于redis的分布式锁机制,锁定各个库存分段和总库存,即为各个库存分段和总库存加锁。其中,redis的本质是一个key-value类型的数据库。
在某些实施例中,服务端可以利用数据库存储各个库存分段的库存数据。示例地,每个库存分段对应一个分段编号和相应的库存数据(即表征库存量的数据),每个库存分段的库存数据占用数据库的一行,每个库存分段的分段编号作为该库存分段所占用的数据库行的主键。
其中,在服务端将多个用户请求分配给目标数量个库存分段进行并行处理时,为了尽可能地实现负载均衡,可以将多个用户请求趋于平均地分配给各个库存分段,服务端基于多个库存分段对多个用户请求进行并行处理。示例地,服务端可以将多个用户请求轮询地分配给各个库存分段进行并行处理。或者示例地,服务端可以将多个用户请求随机分配给各个库存分段进行并行处理。
其中,服务端在针对每个库存分段,处理分配给该库存分段的用户请求时,将该用户请求所对应的用户库存锁定,例如将发送该用户请求的用户的用户库存锁定。同时,服务端将该库存分段分段锁定。如此,服务端可以在用户库存的库存数据和库存分段的库存数据之间,进行库存增减操作。假设该用户请求具体是:利用50积分换取服务端提供的小礼物。则服务端可以将用户库存的库存数据扣减50积分,同时将库存分段的库存数据增加50积分。或者假设该用户请求具体是:向购物车中添加2件目标商品。则服务端可以将用户库存的库存数据增加2,同时将库存分段的库存数据扣减2。
通过执行上述包括步骤S11至步骤S13的响应用户请求的方法,一方面,在服务端获得多个用户请求后,可以将多个用户请求分配给所述目标数量个库存分段进行并行处理,从而提高了服务端对多个用户请求的处理效率。另一方面,针对每个库存分段,服务端在处理分配给该库存分段的用户请求时,首先将该库存分段与该用户请求所对应的用户库存分别锁定,然后根据该用户请求,对锁定的库存分段和用户库存执行库存计算操作,以确保库存分段实时准确,进而确保了服务端总库存的实时准确。
为了能进一步提高用户请求处理效率,参考图2,图2是本申请另一实施例提出的基于库存响应用户请求的方法的流程图。如图2所示,该方法还可以包括以下步骤:
步骤S12’:将库存分段的目标数量存入内存数据库;
步骤S13-1:在获得多个用户请求后,针对每个用户请求,从所述内存数据库中读取所述目标数量;
步骤S13-2:根据所读取的所述目标数量确定一个分段编号,将该用户请求分配给该分段编号所对应的库存分段。
其中,步骤S12’可以与步骤S12调换执行顺序,或者步骤S12’与步骤S12可同时执行。换言之,本申请不限定步骤S12’与步骤S12之间的执行顺序。
其中,内存数据库是将数据放在内存中直接操作的数据库,相对于磁盘,内存的数据读写速度要高出几个数量级,将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。示例地,本申请在实施期间,内存数据库可具体选用redis数据库。
以秒杀场景为例,假设库存分段的目标数量为12,内存数据库选用redis数据库。当秒杀开始时,服务端陆续接收到大量用户请求后,服务端针对每个用户请求,首先执行步骤S13-1,即从redis数据库中查询库存分段的目标数量是12。然后执行步骤S13-2,即根据目标数量12,确定一个分段编号,将该用户请求分配给该分段编号对应的库存分段。如此,服务端基于各个库存分段,在秒杀业务期间对高并发的用户请求进行并行处理。
上述示例中,在执行步骤S13-2时,服务端根据目标数量12确定分段编号的具体方式,可参考上文所列举的示例。例如,服务端轮询地从1到12确定一个分段编号,从而可以将多个用户请求轮询地分配给12个库存分段进行并行处理。或者例如,服务端可以在[1,12]的区间内随机确定一个整数,作为分段编号,从而可以将多个用户请求随机分配给各个库存分段进行并行处理。
上述示例中,由于库存分段的目标数量存储于内存数据库中,因此使得服务端可以将短时间内的高并发用户请求迅速分配给各个库存分段,防止用户请求在分配环节拥塞。而考虑到在用户请求并发很高的情况下,库存分段的目标数量较大,各个库存分段的库存数据需要占用较大的存储空间,为了避免服务端设备内存因存储大量库存数据而耗尽,可选用磁盘数据库存储各个库存分段的库存数据。如此,有效提高用户请求处理效率的情况下,进一步兼顾了服务端硬件性能的条件限制,使得本申请在实施期间服务端可平顺运行。
考虑到服务端计算资源的限制,比如数据库性能的限制,又考虑到用户请求的并发量会随着时间而变化,为了使得服务端在大多数时间下,能以较少的计算资源实现用户请求的最大化处理效率,本申请在实施期间,服务端可以选择的一种实施方式是:周期性地重新确定库存分段的目标数量,并对服务端的总库存进行重新拆分。如此,当用户请求的并发量下降后,可以及时重新确定一个数值较小的目标数量,从而将服务端总库存拆分成数量较少的库存分段,进而减少对服务端计算资源(如数据库资源)的占用。或者当用户请求的并发量升高后,可以及时重新确定一个数值较大的目标数量,从而将服务端总库存拆分成数量较多的库存分段,进而确保服务端能及时应对用户请求并发量的上涨。
具体地,参考图3,图3是本申请一实施例提出的确定库存分段的目标数量的流程图。如图3所示,该流程具体包括以下子步骤:
子步骤S11-1:周期性地获得服务端的处理频次;
子步骤S11-2:确定当前周期所获得的处理频次与上一周期所获得的历史处理频次是否处于同一个频次水平;
子步骤S11-3:在所述处理频次和所述历史处理频次处于不同的频次水平的情况下,根据所述处理频次和库存分段的目标处理频次,确定在当前周期库存分段所对应的目标数量。
其中,在上述子步骤S11-1中,服务端可以每隔固定时间段(例如5分钟、15分钟或30分钟等)检测一下其处理频次,然后将检测到的处理频次作为当前周期的处理频次。或者服务端可以在当前周期内持续检测其处理频次,然后将持续检测的多个处理频次中的一个作为当前周期的处理频次,例如可以将当前周期内的最大处理频次作为当前周期的处理频次。
参考图4(a),图4(a)是本申请一实施例提出的确定处理频次与历史处理频次是否处于同一个频次水平的示意图。如图4(a)所示,每个频次水平可以以一个频次区间所表征,多个不同的频次水平分别以多个首尾连接的频次区间所表征。在执行上述子步骤S11-2时,如图4(a)所示,由于上一周期(假设是10点30分至10点45分)所获得的历史处理频次为240,当前周期(假设是10点45分至11点整)的处理频次为565,两者分别处于不同的频次区间,因此确定当前周期所获得的处理频次与上一周期所获得的历史处理频次未处于同一个频次水平。
如此,执行上述子步骤S11-3。通过执行子步骤S11-3,可以及时重新确定一个数值较大的目标数量,从而可以将服务端总库存拆分成数量较多的库存分段,进而可以确保服务端能及时应对用户请求并发量的上涨。
参考图4(b),图4(b)是本申请另一实施例提出的确定处理频次与历史处理频次是否处于同一个频次水平的示意图。如图4(b)所示,每个频次水平可以以一个频次区间所表征,多个不同的频次水平分别以多个首尾连接的频次区间所表征。在执行上述子步骤S11-2时,如图4(b)所示,由于上一周期(假设是10点45分至11点整)所获得的历史处理频次为565,当前周期(假设是11点整至11点15分)的处理频次为325,两者分别处于不同的频次区间,因此确定当前周期所获得的处理频次与上一周期所获得的历史处理频次未处于同一个频次水平。
如此,执行上述子步骤S11-3。通过执行子步骤S11-3,可以及时重新确定一个数值较小的目标数量,从而可以将服务端总库存拆分成数量较少的库存分段,进而可以减少对服务端计算资源(如数据库资源)的占用。
其中,在执行子步骤S11-3时,在某些实施例中,如前所述,库存分段的目标处理频次可以是人为指定的。在确定当前周期库存分段所对应的目标数量时,可以将当前周期的处理频次与目标处理频次之间的比值,确定为当前周期库存分段的目标数量。
或者在另一些实施例中,库存分段的目标处理频次也可以是:上一周期所确定的各个库存分段在当前的实际处理频次。
或者在另一些实施例中,在执行子步骤S11-3之前,可以将所述上一周期所获得的历史处理频次和上一周期所确定的库存分段的历史数量的比值,确定为所述库存分段的目标处理频次。
示例地,假设上一周期所获得的历史处理频次为240,确定的库存分段的历史数量为12。如此,库存分段的目标处理频次等于240/12,即20。然后在执行子步骤S11-3时,可以根据当前周期的处理频次(假设为565)和库存分段的目标处理频次20,确定在当前周期库存分段所对应的目标数量。如前所述,可以将当前周期的处理频次与目标处理频次之间的比值,确定为当前周期库存分段的目标数量。如此,当前周期库存分段的目标数量等于565/20,向上取整等于29。应当理解的,在当前周期的处理频次与目标处理频次之间的比值不等于整数的情况下,除了可以采用向上取整的取整策略外,还可以采用向下取整、或者四舍五入的取整策略,本申请对此不限定。
此外,考虑到服务端在执行子步骤S11-3时,本身会消耗部分计算资源和计算时间,为了尽量减少服务端的这部分消耗,如图3所示,在所述处理频次和所述历史处理频次处于同一个频次水平的情况下,结束当前周期的确定库存分段的目标数量的流程。如此,在两个前后相邻周期的处理频次变化较小的情况下,可以暂时不执行子步骤S11-3,即暂时不重新计算库存分段的目标数量,进而不重新对服务端的总库存进行重新拆分,可以尽量减少服务端因执行子步骤S11-3和前述步骤S12而产生的消耗,从而进一步提高服务端对用户请求的处理效率。
同样地,考虑到服务端在执行子步骤S11-3时,本身会消耗部分计算资源和计算时间。在多个不同的频次水平分别由多个不同的频次区间所表征的情况下,一方面,如果各个频次区间的范围较窄,则每个周期执行子步骤S11-3和步骤S12的可能性较大,导致服务端频繁执行子步骤S11-3和步骤S12,服务端在一段时间内(例如5个周期内)对总库存进行重新拆分的总时间较长。但是其好处是:可以在用户请求并发量稍有上涨时,及时扩充库存分段数量,使得用户请求的处理时间较短;或者可以在用户请求并发量稍有下降时,及时减少库存分段数量,使得服务端的计算资源被及时收回。
另一方面,如果各个频次区间的范围较宽,则每个周期执行子步骤S11-3和步骤S12的可能性较小,导致服务端在用户请求并发量稍有上涨时,不能及时扩充库存分段数量,使得用户请求的处理时间较长;或者可以在用户请求并发量稍有下降时,不能及时减少库存分段数量,使得服务端的计算资源不能被及时收回。但是其好处是:服务端在每个周期执行子步骤S11-3和步骤S12的可能性较小,使服务端在一段时间内(例如10个周期内)对总库存进行重新拆分的总时间较短。
有鉴于此,为了使服务端对上述两方面加以平衡,服务端还可以根据一段时间内处理一个用户请求的耗时时间,和/或,一段时间内重新确定库存分段的目标数量的次数,对所述多个频次区间各自的频次范围进行调整。
其中,一段时间是指:一段比获得服务端的处理频次的周期更长的时间。例如服务端每15分钟获得处理频次,则一段时间可以是60分钟、120分钟或者180分钟等等。
用户请求的耗时时间可以是:一段时间内处理所有用户请求的平均耗时时间,或者一段时间内多个用户请求的耗时时间中的最大耗时时间,或者一段时间内多个用户请求的耗时时间中的中位数。
以用户请求的耗时时间是:120分钟内处理所有用户请求的平均耗时时间为例。示例地,假设服务端内预设有三套频次区间,每套频次区间中各个频次区间的范围互不相同。
其中第一套是:[0,50]、(50、100]、(100、200]、(200、300]、(300、400]、(400、600]、(600、800]、(800、1000]、(1000、1200]。
其中第二套是:[0,100]、(100、200]、(200、300]、(300、500]、(500、800]、(800、1200]。
其中第三套是:[0,200]、(200、400]、(400、700]、(700、1200]。
在某些实施例中,每一套频次区间对应不同的用户请求平均耗时区间。例如第三套对应的平均耗时区间为[0秒,2秒],第二套对应的平均耗时区间为(2秒,4秒],第一套对应的平均耗时区间为(4秒,6秒]。假设在8点整至10点整,所有用户请求耗时的平均耗时为1.5秒,则应当切换至第三套频次区间。假设在10点整至12点整,所有用户请求耗时的平均耗时为3.2秒,则应当从第三套频次区间切换至第二套频次区间,从而缩小各个频次区间的范围。
或者在另一些实施例中,每一套频次区间对应不同的重新确定目标数量的次数区间。例如第一套对应的次数区间为[0,2],第二套对应的次数区间为[3,5],第三套对应的次数区间为[6,8]。假设在8点整至10点整,重新确定目标数量的次数为3次,则应当切换至第二套频次区间。假设在10点整至12点整,重新确定目标数量的次数为7次,则应当从第二套频次区间切换至第三套频次区间,从而扩大各个频次区间的范围。
应当理解的,上述示例中的具体数值仅为介绍方案方便,本申请在实施期间,实际所涉及的数值可能与上述示例中的数值不同。并且,上述示例仅是多种调整频次范围的具体方式中的一种,上述示例不应理解为对本申请的限定。
参考图5,图5是本申请一实施例提出的总库存分段的流程图。如图5所示,在确定在当前周期库存分段所对应的目标数量之后,为了将服务端的总库存拆分成目标数量个库存分段,可以具体执行以下步骤:
步骤S12-1:将上一周期所确定的各个库存分段分别锁定;
步骤S12-2:根据各个被锁定的库存分段,确定所述服务端的总库存;
步骤S12-3:将所述服务端的总库存拆分成当前周期所确定的目标数量个库存分段。
具体地,参考图6,图6是本申请一实施例提出的总库存分段的示意图。上一周期所确定的库存分段的历史数量为12个,12个库存分段当前剩余的库存数据分别是6631、4598、2847、6605、4836、2360、6040、5152、2212、3887、6934、4172。基于redis的分布式锁机制,将12个库存分段进行锁定,然后从磁盘数据库中读取各个库存分段当前剩余的库存数据,并计算出服务端当前的总库存等于56274,即合并12个库存分段当前剩余的库存数据后的加和。
如图6所示,在执行上述子步骤S11-3后,当前周期库存分段所对应的目标数量为4个。总库存拆分时,首先利用磁盘数据库的4行,分别建立一个分段库存,总共新建4个分段库存。然后锁定这4个分段库存,将服务端当前的总库存等于56274均分至4个分段库存,如此,4个分段库存的库存数据分别是14069、14069、14068以及14068。再将每个分段库存的库存数据写入磁盘数据库中的对应行,最后释放这4个库存分段,使得服务端可以在获得多个用户请求后,基于这4个库存分段对多个用户请求进行并行处理。
此外,服务端还可以将内存数据库中的记录的“12”替换为“4”。即服务端将上一周期的库存分段所对应的历史数量,替换为当前周期的库存分段所对应的目标数量。如此,服务端在获得多个用户请求后,针对每个用户请求,从所述内存数据库中读取所述目标数量;然后根据所读取的所述目标数量确定一个分段编号,将该用户请求分配给该分段编号所对应的库存分段。
基于同一发明构思,本申请一实施例提供一种基于库存响应用户请求的装置,该装置应用于服务端。参考图7,图7是本申请一实施例提出的基于库存响应用户请求的装置的示意图。如图7所示,该装置包括:
目标数量确定模块71,用于获得所述服务端的处理频次,并根据所述处理频次和库存分段的目标处理频次,确定库存分段的目标数量;
总库存拆分模块72,用于将所述服务端的总库存拆分成所述目标数量个库存分段;
用户请求分配模块73,用于在获得多个用户请求后,将所述多个用户请求分配给所述目标数量个库存分段进行并行处理;
用户请求处理模块74,用于针对每个库存分段,处理分配给该库存分段的用户请求,包括:将该库存分段与该用户请求所对应的用户库存分别锁定;根据该用户请求,对锁定的库存分段和用户库存执行库存计算操作。
可选地,所述目标数量确定模块包括:
处理频次获得子模块,用于周期性地获得服务端的处理频次;
频次水平确定子模块,用于确定当前周期所获得的处理频次与上一周期所获得的历史处理频次是否处于同一个频次水平;
目标数量确定子模块,用于在所述处理频次和所述历史处理频次处于不同的频次水平的情况下,根据所述处理频次和库存分段的目标处理频次,确定在当前周期库存分段所对应的目标数量。
可选地,所述装置还包括:
流程结束模块,用于在所述处理频次和所述历史处理频次处于同一个频次水平的情况下,结束当前周期的确定库存分段的目标数量的流程。
可选地,多个不同的频次水平分别由多个不同的频次区间所表征;所述装置还包括:
频次区间调整模块,用于根据一段时间内处理一个用户请求的耗时时间,和/或,一段时间内重新确定库存分段的目标数量的次数,对所述多个频次区间各自的频次范围进行调整。
可选地,所述装置还包括:
目标处理频次确定模块,用于在根据所述处理频次和库存分段的目标处理频次,确定在当前周期库存分段所对应的目标数量之前,将所述上一周期所获得的历史处理频次和上一周期所确定的库存分段的历史数量的比值,确定为所述库存分段的目标处理频次。
可选地,所述总库存拆分模块包括:
库存分段锁定子模块,用于将上一周期所确定的各个库存分段分别锁定;
总库存确定子模块,用于根据各个被锁定的库存分段,确定所述服务端的总库存;
总库存拆分子模块,用于将所述服务端的总库存拆分成当前周期所确定的目标数量个库存分段。
可选地,所述装置还包括:
目标数量存储模块,用于在确定库存分段的目标数量后,将库存分段的目标数量存入内存数据库;
所述用户请求分配模块包括:
目标数量读取子模块,用于在获得多个用户请求后,针对每个用户请求,从所述内存数据库中读取所述目标数量;
用户请求分配子模块,用于根据所读取的所述目标数量确定一个分段编号,将该用户请求分配给该分段编号所对应的库存分段。
基于同一发明构思,本申请另一实施例提供一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时,实现如本申请上述任一实施例所述的方法中的步骤。
基于同一发明构思,本申请另一实施例提供一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时,实现本申请上述任一实施例所述的方法中的步骤。
对于装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白,本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此,本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上,使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种基于库存响应用户请求的方法、装置、设备及存储介质,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种基于库存响应用户请求的方法,其特征在于,应用于服务端,所述方法包括:
获得所述服务端的处理频次,并根据所述处理频次和库存分段的目标处理频次,确定库存分段的目标数量;
将所述服务端的总库存拆分成所述目标数量个库存分段;
在获得多个用户请求后,将所述多个用户请求分配给所述目标数量个库存分段进行并行处理;
其中,针对每个库存分段,处理分配给该库存分段的用户请求,包括:将该库存分段与该用户请求所对应的用户库存分别锁定;根据该用户请求,对锁定的库存分段和用户库存执行库存计算操作。
2.根据权利要求1所述的方法,其特征在于,所述获得所述服务端的处理频次,并根据所述处理频次和库存分段的目标处理频次,确定库存分段的目标数量,包括:
周期性地获得服务端的处理频次;
确定当前周期所获得的处理频次与上一周期所获得的历史处理频次是否处于同一个频次水平;
在所述处理频次和所述历史处理频次处于不同的频次水平的情况下,根据所述处理频次和库存分段的目标处理频次,确定在当前周期库存分段所对应的目标数量。
3.根据权利要求2所述的方法,其特征在于,所述方法还包括:
在所述处理频次和所述历史处理频次处于同一个频次水平的情况下,结束当前周期的确定库存分段的目标数量的流程。
4.根据权利要求2所述的方法,其特征在于,多个不同的频次水平分别由多个不同的频次区间所表征;所述方法还包括:
根据一段时间内处理一个用户请求的耗时时间,和/或,一段时间内重新确定库存分段的目标数量的次数,对所述多个频次区间各自的频次范围进行调整。
5.根据权利要求2所述的方法,其特征在于,在根据所述处理频次和库存分段的目标处理频次,确定在当前周期库存分段所对应的目标数量之前,所述方法还包括:
将所述上一周期所获得的历史处理频次和上一周期所确定的库存分段的历史数量的比值,确定为所述库存分段的目标处理频次。
6.根据权利要求2至5任一所述的方法,其特征在于,所述将所述服务端的总库存拆分成所述目标数量个库存分段,包括:
将上一周期所确定的各个库存分段分别锁定;
根据各个被锁定的库存分段,确定所述服务端的总库存;
将所述服务端的总库存拆分成当前周期所确定的目标数量个库存分段。
7.根据权利要求1至5任一所述的方法,其特征在于,在确定库存分段的目标数量后,所述方法还包括:
将库存分段的目标数量存入内存数据库;
所述在获得多个用户请求后,将所述多个用户请求分配给所述多个库存分段进行并行处理,包括:
在获得多个用户请求后,针对每个用户请求,从所述内存数据库中读取所述目标数量;
根据所读取的所述目标数量确定一个分段编号,将该用户请求分配给该分段编号所对应的库存分段。
8.一种基于库存响应用户请求的装置,其特征在于,应用于服务端,所述装置包括:
目标数量确定模块,用于获得所述服务端的处理频次,并根据所述处理频次和库存分段的目标处理频次,确定库存分段的目标数量;
总库存拆分模块,用于将所述服务端的总库存拆分成所述目标数量个库存分段;
用户请求分配模块,用于在获得多个用户请求后,将所述多个用户请求分配给所述目标数量个库存分段进行并行处理;
用户请求处理模块,用于针对每个库存分段,处理分配给该库存分段的用户请求,包括:将该库存分段与该用户请求所对应的用户库存分别锁定;根据该用户请求,对锁定的库存分段和用户库存执行库存计算操作。
9.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该计算机程序被处理器执行时,实现如权利要求1至7任一所述的方法中的步骤。
10.一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行时实现如权利要求1至7任一所述的方法的步骤。
CN201911215499.7A 2019-12-02 2019-12-02 基于库存响应用户请求的方法、装置、设备及存储介质 Pending CN111260272A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911215499.7A CN111260272A (zh) 2019-12-02 2019-12-02 基于库存响应用户请求的方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911215499.7A CN111260272A (zh) 2019-12-02 2019-12-02 基于库存响应用户请求的方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN111260272A true CN111260272A (zh) 2020-06-09

Family

ID=70954161

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911215499.7A Pending CN111260272A (zh) 2019-12-02 2019-12-02 基于库存响应用户请求的方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN111260272A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112380026A (zh) * 2021-01-13 2021-02-19 常州微亿智造科技有限公司 任务处理方法、装置和存储介质
CN113723892A (zh) * 2021-09-13 2021-11-30 北京沃东天骏信息技术有限公司 数据处理方法、装置、电子设备及存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150100465A1 (en) * 2013-10-08 2015-04-09 Google Inc. High Volume Consumer E-commerce
CN104516895A (zh) * 2013-09-27 2015-04-15 阿里巴巴集团控股有限公司 商品对象库存信息处理方法及系统
CN106170016A (zh) * 2016-07-28 2016-11-30 深圳市创梦天地科技有限公司 一种处理高并发数据请求的方法和系统
CN106550010A (zh) * 2016-09-21 2017-03-29 南京途牛科技有限公司 一种实时控制分布式系统调用外系统服务频次的方法及系统
CN107341624A (zh) * 2016-04-29 2017-11-10 苏宁云商集团股份有限公司 一种业务数据的处理方法及装置
CN108897615A (zh) * 2018-05-31 2018-11-27 康键信息技术(深圳)有限公司 秒杀请求处理方法、应用服务器集群及存储介质
CN109714407A (zh) * 2018-12-19 2019-05-03 网易(杭州)网络有限公司 服务器资源调节方法及装置、电子设备和存储介质
CN109803160A (zh) * 2019-02-03 2019-05-24 北京奇艺世纪科技有限公司 一种资源分配方法、装置及系统

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104516895A (zh) * 2013-09-27 2015-04-15 阿里巴巴集团控股有限公司 商品对象库存信息处理方法及系统
US20150100465A1 (en) * 2013-10-08 2015-04-09 Google Inc. High Volume Consumer E-commerce
CN107341624A (zh) * 2016-04-29 2017-11-10 苏宁云商集团股份有限公司 一种业务数据的处理方法及装置
CN106170016A (zh) * 2016-07-28 2016-11-30 深圳市创梦天地科技有限公司 一种处理高并发数据请求的方法和系统
CN106550010A (zh) * 2016-09-21 2017-03-29 南京途牛科技有限公司 一种实时控制分布式系统调用外系统服务频次的方法及系统
CN108897615A (zh) * 2018-05-31 2018-11-27 康键信息技术(深圳)有限公司 秒杀请求处理方法、应用服务器集群及存储介质
CN109714407A (zh) * 2018-12-19 2019-05-03 网易(杭州)网络有限公司 服务器资源调节方法及装置、电子设备和存储介质
CN109803160A (zh) * 2019-02-03 2019-05-24 北京奇艺世纪科技有限公司 一种资源分配方法、装置及系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112380026A (zh) * 2021-01-13 2021-02-19 常州微亿智造科技有限公司 任务处理方法、装置和存储介质
CN113723892A (zh) * 2021-09-13 2021-11-30 北京沃东天骏信息技术有限公司 数据处理方法、装置、电子设备及存储介质

Similar Documents

Publication Publication Date Title
US11336589B2 (en) Allocating virtual resource based on blockchain
CN104966214B (zh) 一种电子券的交互方法和装置
KR101959153B1 (ko) 데이터베이스에서의 계좌와 관련된 거래 요청의 효율적인 처리를 위한 시스템
US8316373B2 (en) Concurrent data processing and electronic bookkeeping
CN108897615A (zh) 秒杀请求处理方法、应用服务器集群及存储介质
CN105409171B (zh) 突发模式控制
CN110333951B (zh) 一种商品抢购请求分配方法
CN111260272A (zh) 基于库存响应用户请求的方法、装置、设备及存储介质
CN110060140A (zh) 海量数据对账方法、装置、介质和计算机设备
CN111738709A (zh) 交易处理方法及装置
CN110852559A (zh) 资源的分配方法和装置、存储介质、电子装置
CN112950285A (zh) 积分的处理方法、装置、服务器及存储介质
US10678192B1 (en) Optimization of production systems
US20220068075A1 (en) Methods and apparatuses for creating times card voucher and methods and apparatuses for writing off times card voucher
CN107967650A (zh) 一种核心银行系统的批量账务数据处理方法及装置
CN112015577B (zh) 一种智能合约的调用方法和装置
CN112035681B (zh) 基于知识图谱的信用卡费率信息确定方法及装置
CN107194712B (zh) 共享账户变动信息记录方法及装置、内部账户补账方法及系统
Dennis Booth et al. An adaptive self‐scheduling loop scheduler
CN112288460A (zh) 提示用户登录平台的方法、装置、设备及存储介质
Kim et al. Virtual machines placement for network isolation in clouds
CN110096352A (zh) 进程管理方法、装置及计算机可读存储介质
CN115907949A (zh) 银行交易数据处理方法及装置
CN110275771A (zh) 一种业务处理方法、物联网计费基础设施系统及存储介质
CN102013075A (zh) 一种金融产品数据分配服务器及分配方法

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20200609