本发明涉及互联网技术领域，尤其涉及一种库存管理的方法及装置。
背景技术：
随着库存系统的发展，库存系统需要管理的仓库数量越来越多、区域范围也越来越大，这就需要库存系统还需要保证数据的一致性。比如，销售场景中若存在同一订单内包括多个子订单，即一单多行的情况，则需要每个子订单都成功；调拨场景中通常有几百甚至上千行需要完成加库、减库操作，也同样需要上述并行的几百甚至上千行调拨操作中每行都成功；交货场景中若存在一单多行的情况，为了确保收货人可以在同一时间收到完整订单，则需要该单内的每行所对应的数量的商品统一发货等。
目前，若想满足上述各场景需求，则需要多个数据库节点之间进行协调。但是，考虑到当前库存系统的分布式处理情况，若要保证跨库数据一致性，各个节点对被锁资源的释放，需要等到本次订单事务最终提交，即在一次订单事务被处理完后，才统一释放被锁资源，这样一来就需要耗费大量时间等待事务的最终提交。尤其是对于一些涉及大规模促销的应用场景，不仅需要耗费大量时间进行等待，同时当请求并发数量达到一定数量时，就会产生大量积压的事务，甚至出现死锁，即库存系统报错，和/或一定数量的商品虽然在库却无法进行销售，这样就会导致系统性能的严重下滑。
技术实现要素：
本发明实施例提供一种库存管理的方法及装置，能够缓减系统性能严重下滑的问题。
为达到上述目的，本发明实施例采用如下技术方案：
第一方面，本发明实施例提供的方法，包括：
获取并解析业务请求消息，得到解析结果，其中，业务请求消息指示的操作类型至少包括：对于指定库存的扣减；
根据所述解析结果，生成对应所述业务请求消息的日志表，并将所述日志表中每条库存数据的状态设置为待处理；
当所述日志表中的至少一条库存数据所对应的库存扣减失败时，对所述日志表对应的库存中，已被成功扣减的部分执行加库,并对所述日志表中的每条库存数据进行处理，得到处理结果，其中，所述日志表对应的全部库存包括：所述日志表中的每一条库存数据在所述指定库存中对应的库存；
根据所述处理结果更改每条库存数据的状态。
结合第一方面，在第一方面的第一种可能的实现方式中，所述对所述日志表对应的库存中，已被成功扣减的部分执行加库,并对所述日志表中的每条库存数据进行处理，得到处理结果，具体包括：
将所述日志表中所有数据进行分组，得到减库存集合，所述减库存集合中每条库存数据的处理类型为对于指定库存的扣减；
处理所述减库存集合中的每条数据，得到减库存处理结果；
在完成减库存操作后，若存在所述加库存集合，则处理所述加库存集合中的每条库存数据，得到加库存处理结果，所述加库存集合中每条库存数据的处理类型为对于指定库存的加库。
结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，在所述得到减库存处理结果之后，所述方法还包括：
释放临时锁，所述临时锁对应所述日志表中减库存处理结果为成功的库存数据。
结合第一方面的第二种可能的实现方式,在第三种可能的实现方式中，在所述释放临时锁之后，所述方法还包括：
若所述减库存处理结果为全部成功，则为所述减库存处理结果对应的库存数据设置正式锁。
结合第一方面的第一种可能的实现方式,在第四种可能的实现方式中，在所述处理结果为所述减库存处理结果时，所述根据所述处理结果更改每条库存数据的状态，具体包括：
若所述减库存处理结果为全部成功，则将所述减库存集合中的每条库存数据的状态修改为成功；
若所述减库存处理结果为部分成功，则将所述减库存集合中的每条库存数据的状态修改为减库存处理结果不一致。
结合第一方面的第四种可能的实现方式,在第五种可能的实现方式中，在所述将所述减库存集合中的每条库存数据的状态修改为减库存处理结果不一致之后，所述方法还包括：
将已完成扣减操作的库存数据进行加库，并将所述减库存集合中的每条库存数据的状态修改为失败，其中，扣减操作对应的扣减数量与加库对应的数量相同。
结合第一方面的第一种可能的实现方式,在第六种可能的实现方式中，在所述处理结果为所述加库存处理结果时，所述根据所述处理结果更改每条库存数据的状态，具体包括：
若所述加库存处理结果为全部成功，则将所述加库存集合中的每条库存数据的状态修改为成功；
若所述加库存处理结果为部分成功，则将所述加库存集合中的每条库存数据的状态修改为加库存处理结果不一致。
结合第一方面的第六种可能的实现方式,在第七种可能的实现方式中，在所述根据所述处理结果更改每条库存数据的状态之后，所述方法还包括：
再次执行加库操作，直至所述加库存集合中的每条库存数据处理成功，并将所述加库存集合中的每条库存数据的状态修改为成功。
第二方面，本发明实施例提供的装置，包括：
获取模块，用于获取并通过解析模块解析业务请求消息，得到解析结果，其中，业务请求消息指示的操作类型至少包括：对于指定库存的扣减；
生成模块，用于根据所述解析模块得到的所述解析结果，生成对应所述业务请求消息的日志表，并通过状态设置模块将所述日志表中每条库存数据的状态设置为待处理；
处理模块，用于当所述日志表中的至少一条库存数据所对应的库存扣减失败时，对所述日志表对应的库存中，已被成功扣减的部分执行加库,并对所述日志表中的每条库存数据进行处理，得到处理结果，其中，所述日志表对应的全部库存包括：所述日志表中的每一条库存数据在所述指定库存中对应的库存；
所述状态设置模块，还用于根据所述处理模块得到的所述处理结果更改每条库存数据的状态。
结合第二方面，在第二方面的第一种可能的实现方式中，所述处理模块，具体用于：
将所述日志表中所有数据进行分组，得到减库存集合，所述减库存集合中每条库存数据的处理类型为对于指定库存的扣减；
处理所述减库存集合中的每条数据，得到减库存处理结果；
所述装置还包括：
释放模块，用于释放临时锁，所述临时锁对应所述日志表中减库存处理结果为成功的库存数据；
锁设置模块，用于若所述减库存处理结果为全部成功，则为所述减库存处理结果对应的库存数据设置正式锁。
结合第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，在所述处理结果为所述减库存处理结果时，所述状态设置模块，具体用于：
若所述减库存处理结果为全部成功，则将所述减库存集合中的每条库存数据的状态修改为成功；
若所述减库存处理结果为部分成功，则将所述减库存集合中的每条库存数据的状态修改为减库存处理结果不一致；
所述处理模块，还用于将已完成扣减操作的库存数据进行加库，并通过所述状态设置模块将所述减库存集合中的每条库存数据的状态修改为失败，其中，扣减操作对应的扣减数量与加库对应的数量相同。
结合第二方面的第一种可能的实现方式，在第二方面的第三种可能的实现方式中，在所述处理结果为所述加库存处理结果时，所述状态设置模块，具体用于：
若所述加库存处理结果为全部成功，则将所述加库存集合中的每条库存数据的状态修改为成功；
若所述加库存处理结果为部分成功，则将所述加库存集合中的每条库存数据的状态修改为加库存处理结果不一致；
所述处理模块，还用于再次执行加库操作，直至所述加库存集合中的每条库存数据处理成功，并通过所述状态设置模块将所述加库存集合中的每条库存数据的状态修改为成功。
本发明实施例提供的一种库存管理的方法及装置，相比较于现有技术中，因请求并发数量达到一定数量而导致系统性能的严重下滑，本发明实施例能够根据得到的解析结果生成日志表，并将日志表中每条库存数据的状态设置为待处理。当日志表中的至少一条库存数据所对应的库存扣减失败时，对日志表对应的库存中，已被成功扣减的部分执行加库,并对日志表中的每条库存数据进行处理，得到处理结果，之后根据处理结果更改每条库存数据的状态。上述处理过程是基于已生成的日志表中每条库存数据进行的，且最终会通过日志表的形式，将处理结果一一呈现。并且，由于业务请求消息指示的操作类型至少包括对于指定库存的扣减，因此，采用上述实现方法能够对库存的扣减和加库操作进行区分处理，且秉承着“先扣减，后加库”的操作方式进行库存数据的处理。也就意味着，在库存管理的过程中，库存系统可以依据当前需要区分管理库存的扣减和加库操作，并将加库操作作为扣减操作的补偿手段，从而确保在请求并发数量达到一定数量后，基于“实时扣，异步加”的库存管理原则进行库存管理。这样一来，若在指定库存的扣减过程中出现扣减错误或是部分库存扣减失败，则可以通过加库操作进行补偿，即恢复到扣减之前的初始状态。由此可见，则不会出现因先加库，且在加库失败时，采用扣减方式进行补偿所导致的超卖现象的发生。因此，能够缓减系统性能严重下滑的问题。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1为本发明实施例提供的一种库存系统架构的示意图；
图2为本发明实施例提供的一种库存管理的装置结构示意图；
图3为本发明实施例提供的一种库存管理的方法流程图；
图4a、图4b为本发明实施例提供的具体实例的示意图。
具体实施方式
为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明作进一步详细描述。下文中将详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。
本发明实施例可以应用于一种库存系统，例如，如图1所示库存系统的结构示意图。库存系统10可以被具体划分为三个部分，这三个部分分别为：销售渠道11、销售环节12，以及销售准备销售履约13。其中，销售渠道11具体可以包括线上销售平台14和线下销售平台15；销售环节12具体可以包括CIS
(Information Service System，库存信息服务系统)16、C店库存系统(英文：C-store Inventory Management System，CIMS)17和GAIA(或称为GAIA Inventory System，即平台库存系统)18；销售准备销售履约13具体可以包括采购平台20和物流系统21。此外，在库存系统10中还需要包括大数据平台19，为库存系统10提供数据支持。库存系统10中各个部分的连接关系如图1所示，在线上销售品台14或线下销售平台15产生订单消息后，该订单消息可以被传送至CIS16，由CIS16根据该订单消息的来源，确定将属于自营业务的订单消息路由至GAIA18，之后由GAIA18根据订单消息对应数量的商品、采购平台20的采购现况，以及物流系统21的物流状态，确定该商品的库存；或是确定将属于C店业务的订单那消息路由至CIMS17处理。其中，平台库存系统，用于接收订单消息；在平台库存系统所管理的库存中，临时锁定订单消息对应的数量的商品；根据接收到的与订单消息相关联的支付消息，检测是否完成支付，若是则将订单消息对应的数量的商品的临时锁定，转换为正式锁定，订单消息至少包括：商品编码和商品数量信息。
在上述平台库存系统中，设置有如图2所示的库存管理的装置30，该装置30可以用于执行后文所提出的诸如图3所示的方法流程。该装置30至少包括获取模块31、解析模块32、生成模块33、处理模块34和状态设置模块35。
其中，获取模块31，用于获取并通过解析模块32解析业务请求消息，得到解析结果，其中，业务请求消息指示的操作类型至少包括：对于指定库存的扣减。生成模块33，用于根据解析模块32得到的解析结果，生成对应业务请求消息的日志表，并通过状态设置模块将日志表中每条库存数据的状态设置为待处理。处理模块34，用于当日志表中的至少一条库存数据所对应的库存扣减失败时，对日志表对应的库存中，已被成功扣减的部分执行加库,并对日志表中的每条库存数据进行处理，得到处理结果，其中，日志表对应的全部库存包括：日志表中的每一条库存数据在指定库存中对应的库存。状态设置模块35，还用于根据处理模块34得到的处理结果更改每条库存数据的状态。
在本发明实施例的一个可能的实现方式中，处理模块34，具体用于：将日志表中所有数据进行分组，得到减库存集合，减库存集合中每条库存数据的处理类型为对于指定库存的扣减；处理减库存集合中的每条数据，得到减库存处理结果。
该装置30还包括：
释放模块36，用于释放临时锁，临时锁对应日志表中减库存处理结果为成功的库存数据。锁设置模块37，用于若减库存处理结果为全部成功，则为减库存处理结果对应的库存数据设置正式锁。
在本发明实施例的一个可能的实现方式中，在处理结果为减库存处理结果时，状态设置模块35，具体用于：
若减库存处理结果为全部成功，则将减库存集合中的每条库存数据的状态修改为成功；若减库存处理结果为部分成功，则将减库存集合中的每条库存数据的状态修改为减库存处理结果不一致。
处理模块34，还用于将已完成扣减操作的库存数据进行加库，并通过状态设置模块35将减库存集合中的每条库存数据的状态修改为失败，其中，扣减操作对应的扣减数量与加库对应的数量相同。
在本发明实施例的一个可能的实现方式中，在处理结果为加库存处理结果时，状态设置模块35，具体用于：
若加库存处理结果为全部成功，则将加库存集合中的每条库存数据的状态修改为成功；若加库存处理结果为部分成功，则将加库存集合中的每条库存数据的状态修改为加库存处理结果不一致。
处理模块34，还用于再次执行加库操作，直至加库存集合中的每条库存数据处理成功，并通过状态设置模块35将加库存集合中的每条库存数据的状态修改为成功。
本发明实施例提供一种库存管理的方法，该方法可以由如图1所示库存系统10中的GAIA18中设置的诸如图2所示的装置30来执行，该方法如图3所示，具体包括：
S1、获取并解析业务请求消息，得到解析结果。
其中，业务请求消息指示的操作类型至少包括：对于指定库存的扣减。
在本发明实施例中，业务请求消息具体可以为订单系统下发的请求消息，用于表示某用户在门店、网站等销售途径完成下单操作，同时，业务请求消息经过解析后所得到的解析结果中可以包括该用户所需商品的品类、数量及需求时间等至少一种相关信息。此外，业务请求消息还可以包括用于反映线上销售情况的消息，或是至少两个库存之间产生调拨所生成的消息，或是进行门店交货时所产生的消息等。在本发明实施例中，对于业务请求消息的来源、生成时机以及后续用途不做具体限定。
需要说明的是，GAIA能够在获取并解析业务请求消息后，得到解析结果，且根据该业务请求消息能够明确该消息所指示的操作类型。在本发明实施例中，业务请求消息指示的操作类型不仅包括对于指定库存的扣减，还可以包括对于指定库存的加库。比如，在业务请求消息为反映线上销售情况的消息时，该业务请求消息指示的操作类型为库存的扣减；在业务请求消息为至少两个库存之间产生调拨所生成的消息时，该业务请求消息指示的操作类型为某一个或是多个仓库内库存的扣减及除产生扣减以外的某一个或是多个仓库内库存的加库，例如，仓库A中有100件商品a需要调拨至仓库B，仓库C中有20件商品a同样需要调拨至仓库B，那么仓库B在完成调拨之后会增加120件商品a，即仓库A中扣减100件商品a的库存，仓库B中加库120件商品a的库存，仓库C中扣减20件商品a的库存；在业务请求消息为进行门店交货时所产生的消息时，该业务请求消息指示的操作类型为该门店对应库存的扣减。
S2、根据解析结果，生成对应业务请求消息的日志表，并将日志表中每条库存数据的状态设置为待处理。
为了方便统计、管理，在本发明实施例中，GAIA可以依据业务请求消息对应的解析结果，生成日志表。在日志表中包括至少一条库存数据，每条库存数据可以用于表示一批满足特定要求的订单、或是一个订单、或是一个订单中的一部分等，在此不做限定。其中，特定要求具体可以为这一批订单中与商品相关的内容完全相同，比如，用户所需商品的种类、数量等内容相同；或是，这一批订单存在一定关联，比如，这一批订单包括订单A、订单B和订单C，其中，订单A中的商品与订单B和订单C中的商品需要搭配使用，且在订单A中的商品的数量也满足与订单B和订单C中商品进行搭配使用的数量等。需要说明的是，对于特定要求的内容可以由进行库存系统管理的工作人员预先设定，具体设置方式不仅限于上述方式，还可以根据本次统计、管理所看重的因素进行调整，在此不做限定。并且，为了有效区分每条库存数据在不同时刻的状态，比如，在完成处理和未完成处理时，同一条库存数据的状态时不同的，因此，可以将初始状态下日志表中所有库存数据的状态设置为待处理。
S3、当日志表中的至少一条库存数据所对应的库存扣减失败时，对日志表对应的库存中，已被成功扣减的部分执行加库,并对日志表中的每条库存数据进行处理，得到处理结果。
其中，日志表对应的全部库存包括：日志表中的每一条库存数据在指定库存中对应的库存。这里提到的在指定库存中对应的库存，指的可以为这一条库存数据所对应的指定库存中特定商品的相关信息，比如，商品的种类、标识、数量等具体信息，在此不做限定。
在扣减过程中，一旦出现扣减失败的情况，为了能够恢复库存扣减之前的状态，则需要将日志表中已经成功扣减的那部分库存执行加库。也就是通过加库操作来恢复扣减失败前库存数据的状态。
需要说明的是，处理结果可以包括全部成功、部分成功或是全部不成功。
对每条库存数据进行处理时，GAIA可以根据当前待处理的这条库存数据所指示的操作类型，找到指定仓库完成相应的加库、扣减操作，并在操作完成后得到全部成功或是部分成功的处理结果。比如，若这一条数据指示的操作内容为对仓库A进行100件商品a的扣减操作，且对仓库B进行20件商品b的加库操作，那么，若仓库A仅完成了80件商品a的扣减操作，且仓库B完成了20件商品b的加库操作，则由于仓库A扣减未成功，而仓库B加库成功，因此，处理结果为部分成功。同理，若这一条数据指示的操作内容仅包括对仓库B进行20件商品b的加库操作，且仓库B完成了20件商品b的加库操作，则处理结果为全部成功。
需要说明的是，日志表中各条库存数据的处理过程往往是相互独立的，因此，日志表中各条库存数据可以同时处理。但考虑到库存系统的资源是有限的，在诸如双11、双12等售卖高峰期，在尽可能确保库存数据一致性的情况下，还要考虑到系统的稳定性等因素，因此，为了避免超卖情况的发生，本发明实施例主要引用“实时扣，异步加”的处理方式，即优先处理日志表中库存的扣减，并在系统处于负载较低的状态时完成加库操作。这样既能避免因超卖而给用户带来下单成功却付款失败的较差体验，同时，也能够保证在确保库存数据尽可能保证一致性的情况下，使库存系统稳定运行，有效避免在库存系统高负荷时因加库操作而导致的系统瘫痪等性能严重下滑的问题。
S4、根据处理结果更改每条库存数据的状态。
需要说明的是，为了降低库存系统的能耗，调整数据的状态可以周期性进行，且每次更改库存数据的状态时都可以采取批量更改或是指定数量的更改。比如，每次进行库存数据状态的调整时，可以只针对同样调整方式的一定量数据进行批量调整。同理，为了保证上述“实时扣，异步加”的基本准则，对于日志表中各条库存数据的状态的更改过程，也可以依据先更改扣减操作对应的数据，再更改加库操作对应的数据的更改方式。在本发明实施例中，对于数据的状态的更改时机、更改方式等内容不做具体限定，可以由工作人员根据实际应用场景的需求、或是当前库存系统的运行情况等进行预先设定或是调整，比如，在库存系统稳定运行的情况下，为了确保数据一致性也可以采用实时更改的方式，即在得到某条数据的处理结果后立即更改该条数据的状态。
本发明实施例能够根据得到的解析结果生成日志表，并将日志表中每条库存数据的状态设置为待处理。当日志表中的至少一条库存数据所对应的库存扣减失败时，对日志表对应的库存中，已被成功扣减的部分执行加库,并对日志表中的每条库存数据进行处理，得到处理结果，之后根据处理结果更改每条库存数据的状态。上述处理过程是基于已生成的日志表中每条库存数据进行的，且最终会通过日志表的形式，将处理结果一一呈现。并且，由于业务请求消息指示的操作类型至少包括对于指定库存的扣减，因此，采用上述实现方法能够对库存的扣减和加库操作进行区分处理，且秉承着“先扣减，后加库”的操作方式进行库存数据的处理。也就意味着，在库存管理的过程中，库存系统可以依据当前需要区分管理库存的扣减和加库操作，并将加库操作作为扣减操作的补偿手段，从而确保在请求并发数量达到一定数量后，基于“实时扣，异步加”的库存管理原则进行库存管理。这样一来，若在指定库存的扣减过程中出现扣减错误或是部分库存扣减失败，则可以通过加库操作进行补偿，即恢复到扣减之前的初始状态。由此可见，则不会出现因先加库，且在加库失败时，采用扣减方式进行补偿所导致的超卖现象的发生。因此，能够缓减系统性能严重下滑的问题，比如：能够在高并发场景下，在保证库存管理系统性能不下滑的前提下，保证跨数据库的事务一致。缓减系统性能严重下滑的问题
考虑到库存系统运行过程中的稳定性，为了响应“实时扣，异步加”的管理库存的方式，在本发明实施例的一个实现方式中，对日志表对应的库存中，已被成功扣减的部分执行加库,并对日志表中的每条库存数据进行处理，得到处理结果，可以具体实现为：将日志表中所有数据进行分组，得到减库存集合，减库存集合中每条库存数据的处理类型为对于指定库存的扣减；处理减库存集合中的每条数据，得到减库存处理结果。
也就意味着，在进行库存管理时，需要先对日志表中包括的所有库存数据进行分组，而这一分组过程主要是依据业务请求消息指示的操作类型而进行的，即将需要进行库存扣减的所有库存数据划分至减库存集合，同时，可以将需要进行库存加库的所有库存数据划分至加库存集合。之后，先对减库存集合中的所有库存数据进行处理，并在得到减库存处理结果之后，对加库存集合中的所有库存数据进行处理，以得到加库存处理结果。需要说明的是，考虑到加库操作也可以为扣减操作的补偿方式，因此，若经过扣减操作后发现存在未成功完成扣减的库存数据，那么针对这一条扣减操作还可以存在与该条库存数据对应的且归属于加库存集合的库存数据，其中，这条归属于加库存集合的库存数据所指示的对指定库存进行加库的商品及数量，与未成功扣减的库存数据所指示的对指定库存进行扣减的商品及数量相同。
需要说明的是，采用这种有序的管理方式，可以用有限的库存资源来保障消费者的利益，即避免超卖现象给用户带来的不必要的影响。也正是因为GAIA优先执行了扣减操作，才能使库存管理过程中保证了扣减过程对数据带来的影响，即保证了扣减库存数据的一致性。这样就不会出现在售卖高峰期，因未及时进行某仓库的库存扣减、或是因未及时将某仓库的库存扣减同步至其他仓库，而导致的其他用户仍然能够完成还未完成扣减、或是同步操作的商品的下单操作，从而在确保库存系统稳定运行的情况下，为用户提供较优的服务。
由此可见，在本发明实施例中，优先确保扣减操作的进行，并在扣减操作完成后，利用库存系统中的资源进行加库操作，即通过“实时扣，异步加”来避免超卖情况的发生，同时尽可能确保库存系统中库存数据的一致性。
在本发明实施例的一个实现方式中，在库存数据的处理过程中还涉及到临时锁和正式锁。在得到减库存处理结果之后，该方法还包括：释放临时锁，临时锁对应日志表中减库存处理结果为成功的库存数据。并在释放临时锁之后，若减库存处理结果为全部成功，则为减库存处理结果对应的库存数据设置正式锁。
考虑到一个完整的订单可能对应日志表中的多条库存数据，而当这多条库存数据的条数较多时，很可能需要多次处理操作才能将这多条库存数据执行完，因此，在未完成整个订单对应的多条库存数据的处理过程之前，每处理完一条库存数据，都需要对成功扣减的库存设置临时锁。待整个处理操作完成后，则需要释放所有临时锁。而对于被释放临时锁的库存数据，可能会被重新设置正式锁，或是直接不进行其他锁设置的操作。比如，若同一订单对应的所有扣减操作均成功，则在释放临时锁后，需要为这些库存数据设置正式锁，这样才能保证其他用户无法对这些库存数据进行下单；若同一订单对应的所有扣减操作中存在未成功的情况，则直接释放所有成功扣减的库存数据已被设置的临时锁，这样一来，这些库存数据仍然能够被其他用户下单，也就不会影响这些库存数据对应数量的商品的售卖。
针对处理结果为减库存处理结果的情况，在本发明实施例的一个实现方式中，根据处理结果更改每条库存数据的状态，具体包括：若减库存处理结果为全部成功，则将减库存集合中的每条库存数据的状态修改为成功；若减库存处理结果为部分成功，则将减库存集合中的每条库存数据的状态修改为减库存处理结果不一致；将已完成扣减操作的库存数据进行加库，并将减库存集合中的每条库存数据的状态修改为失败，其中，扣减操作对应的扣减数量与加库对应的数量相同。
针对处理结果为加库存处理结果的情况，在本发明实施例的一个实现方式中，根据处理结果更改每条库存数据的状态，具体包括：若加库存处理结果为全部成功，则将加库存集合中的每条库存数据的状态修改为成功；若加库存处理结果为部分成功，则将加库存集合中的每条库存数据的状态修改为加库存处理结果不一致。在根据处理结果更改每条库存数据的状态之后，该方法还包括：再次执行加库操作，直至加库存集合中的每条库存数据处理成功，并将加库存集合中的每条库存数据的状态修改为成功。
针对上述对于库存的扣减和加库的操作而言，为了便于对日志表进行操作，同时确保库存系统方便管理日志表中的各条库存数据，在本发明实施例的一个实现方式中，可以将库存数据的状态在不同情况下设置为不同的标记状态。比如，若库存数据的状态为待处理，则在日志表中将库存数据的状态记为W；若库存数据的状态为成功，则在日志表中将库存数据的状态记为Y；若库存数据的状态为失败，则在日志表中将库存数据的状态记为N；若库存数据的状态为减库存处理结果不一致，则在日志表中将库存数据的状态记为P；若库存数据的状态为加库存处理结果不一致，则在日志表中将库存数据的状态记为PA。
在本发明实施例的一个实现方式中，对于未达到一致的库存数据，即日志表中库存数据的状态为加库存处理结果不一致或减库存处理结果不一致的库存数据，可以采用JOB补偿方式，使其最终一致，其中，JOB可以理解为程序语言层面的一种用于调用一条或者多条线程的任务模块(具体可以实现为程序代
码)，并且各任务模块可以依据实际情况设定，比如：一个JOB可以用于执行加库存的操作，或者执行减库存的操作等。由此可见，采用JOB补偿方式进行处理的数据范围至少包括：日志表中状态为P的库存数据，此情况属于做减库存集合时就失败了，且在进行加库操作时没有成功；日志表中状态为PA的库存数据，此情况属于做加库存集合时失败了，且在反复执行加库存操作后仍没有成功；一段时间之前(如15分钟)，在日志表中的状态还为待处理，即W的库存数据，此情况修改库存数据的状态为失败，但得到的处理结果可能为全部成功或是部分成功，这就需要JOB自行判断。处理方案具体包括：针对状态为P的库存数据，则从日志表中查出待处理库存数据，然后将成功行进行回滚，也就是将扣减成功的库存数据进行加库，以恢复处理过程之前的日志表中库存数据的状态，处理完成后将数据的状态修改为失败，即N；针对状态为PA的库存数据，则从日志表中查出待处理数据，然后将状态为失败的库存数据行进行再次处理直至成功；处理完成后将库存数据的状态修改为成功，即Y；针对一段时间之前，状态还是W的库存数据，则从日志表查出待处理库存数据，并判断为全部成功还是部分成功，针对部分成功的情况，则判断是减库存集合处理存在部分成功，还是加库存集合处理存在部分成功，之后根据情况进行库存数据的状态修改，使其最终状态为成功，即Y，或是失败，即N。举例来说，可以采用如图4a所示的方法流程，其所在的具体运行环境的执行流程可以如图4b所示。在图4a和图4b中，SQL操作：用于表示数据库语句的执行；GET REDIS锁并进行判断：用于表示从redis中获取应用锁，并进行判断，redis是缓存中间件；Commit data：用于表示数据库事务提交；Rollback：用于表示数据库事务回滚。由于在做库存扣减之前须要拿到应用锁，从而保证不出现超卖的现象，所以扣减的动作是排他的、串行的。所以在此次请求数据检查失败后，应该尽快释放应用锁，让其他消费者的请求拿到应用锁，做相应的操作。由于应用锁是起排他作用的，在减库存的场景中，一定要先拿到应用锁才能进行操作，从而防止了两个请求并发的来减库存，造成超卖。所以，每次处理前先拿应用锁，处理完成后，不管全部成功还是全部失败都会去释放应用锁。如果不释放，其他的请求就都堵在那，得不到处理了，这是不行的。因此对于整单失败的数据，比如日志中的状态为N，则需尽快放掉应用锁，让其他消费者的请求得到处理。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。