CN106599018A - 库存操作方法和*** - Google Patents

Abstract

本发明实施例提供一种库存操作方法。该方法包括：响应于下单请求，向主数据库发送第一更新指令，以用于将所述主数据库中的第一库存数据更新为第二库存数据；当所述主数据库更新失败时，利用从数据库中的第一库存数据对所述主数据库进行数据回滚操作。本发明实施例还提供了一种库存操作***。本申请实施例通过主数据和从数据库采用数据回滚以保证库存数据库中的数据相对真实地反映实际库存余量，从而可以在一定程度上防止超卖现象的发生。

Description

库存操作方法和***

技术领域

本申请涉及计算机技术领域中的电子库存仓储技术，尤其涉及一种库存操作方法和***。

背景技术

随着互联网的发展，很多商家为了吸引用户都会推出各种各样的优惠产品，并限制数量，让用户抢购。比较优惠的产品通常能在短时间内吸引大量用户前来购买，有时候能在几分钟甚至几秒到几十秒的时间内售罄。

由于产品的数量是有限的，激增的访问量、高频的并发量，对库存***都是一个很大的挑战。在高访问量下，高频率的读写数据库会严重降低库存***的性能，而并发地访问数据库，容易出现数据库中的库存量与实际库存量不一致的情况，导致发生库存超卖的现象。

对于库存扣减***，传统方案一般都是通过数据库(例如MySQL，一种关系型数据库管理***)进行控制，所有的读写都是在数据库上完成。通常高频率的读写数据库，性能比较低，且由于库存的扣减都会产生数据库共享锁，会导致读写速度比较慢。因为性能低或读写速度慢，会很容易出现数据库中的库存量无法真实反映实际库存量余量的情况。

作为一种替代方案，个别商家通过Redis数据库(Redis数据库是一种高性能的使用键值存储的内存数据库)进行库存操作，应对了超高的流量和并发请求，保证了库存扣减的高效，但是此时一旦当Redis数据库宕机，由于Redis数据库本身的持久化机制并不是实时同步地备份Redis的数据，而是异步备份的，因此依赖Redis持久化的数据回滚容易造成回滚后的库存数据大于真实的库存数据，发生超卖，严重时甚至会造成库存数据无法回滚的情况。

在实现本申请过程中，发明人发现相关技术中至少存在如下问题：由于超高流量和并发请求时数据库处理速度慢或者容易宕机，容易出现数据库中的库存量与实际库存量不一致的情况，导致库存超卖的现象。

发明内容

为了解决现有技术中容易发生库存数据与真实库存数据不一致的问题，第一方面，本申请实施例提供一种库存操作方法，包括：响应于下单请求，向主数据库发送第一更新指令，以用于将所述主数据库中的第一库存数据更新为第二库存数据；当所述主数据库更新失败时，利用从数据库中的第一库存数据对所述主数据库进行数据回滚操作。

第二方面，本申请实施例提供一种库存操作***，包括：

下单模块，配置用于响应于下单请求，向主数据库发送第一更新指令，以用于将所述主数据库中的第一库存数据更新为第二库存数据；

失败回滚模块，配置用于当所述主数据库更新失败时，利用从数据库中的第一库存数据对所述主数据库进行数据回滚操作。

第三方面，本申请实施例还提供了一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行本申请上述任一项库存操作方法。

第四方面，本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括存储在非易失性计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行上述任一项库存操作方法。

第五方面，本申请实施例还提供了一种电子设备，包括：至少一个处理器；以及存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本申请上述任一项库存操作方法。

本申请实施例通过主数据和从数据库采用数据回滚以保证库存数据库中的数据相对真实地反映实际库存余量，从而可以在一定程度上防止超卖现象的发生。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一实施例提供的一种库存操作方法的流程图；

图2是本申请一实施例提供的另一种库存操作方法的流程图；

图3是本申请一实施例提供的又一种库存操作方法的流程图；

图4是本申请一实施例提供的再一种库存操作方法的流程图；

图5是本申请一实施例提供的还一种库存操作方法的流程图；

图6a是本申请一实施例提供的库存操作方案的具体实现框架图；

图6b时本申请一实施例提供的库存操作方案的具体实现流程图；

图7是本申请一实施例提供的一种库存操作***的结构示意图；

图8是本申请一实施例提供的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示为本申请一实施例提供的一种库存操作方法的流程图，本实施例的技术方案可适用对库存进行操作的情况，特别是抢购秒杀等场景下的库存操作，该方法可以由库存操作的处理装置来执行，并配置在服务器端，以对各个数据库进行操作和调度。

本申请实施例提供的一种库存操作方法，包括如下步骤：

步骤101，响应于下单请求，向主数据库发送第一更新指令，以用于将所述主数据库中的第一库存数据更新为第二库存数据。

步骤102，当所述主数据库更新失败时，利用从数据库中的第一库存数据对所述主数据库进行数据回滚操作。

在本实施方式中，对于步骤101，服务器响应于接收到的用户的下单请求，向主数据库发送第一更新指令，以用于将主数据库的第一库存数据更新为第二库存数据。之后，对于步骤102，如果主数据库更新失败，例如主数据库写入数据失败或者主数据库写入数据超时等，则利用从数据库中的第一库存数据对主数据库进行数据回滚操作，以保证主数据库回滚到第一库存数据。

在本实施方式中，通过以上步骤，可以实现在主数据库因为故障等原因更新失败时，通过利用从数据库的数据对主数据库进行回滚，从而可以保证两个数据库中数据的一致性，保证数据库中记载的库存数据与真实的库存数据的一致性，进而可以有效地防止库存超卖的现象发生。

在一些可选实现方式中，上述主数据库的读写速度高于从数据库的读写速度。由于主数据库的读写高于从数据库的读写速度，使得在不发生故障的时间内，可以充分利用主数据库的读写速度来提高***的整体吞吐速度。同时，作为备份的从数据库读写速度较低，其通常成本也较低，从而可以从整体上降低成本。因此，从***整体而言，可以在保证较高性能的同时，也能尽可能降低成本。

在一些可选实现方式中，上述主数据库为内存数据库，从数据库为关系数据库。内存数据库是将数据放在内存中直接操作的数据库，例如Redis数据库。相对于传统的数据库，内存数据库的数据读写速度要高出几个数量级，能够极大地提高***的性能。关系数据库是传统数据库，其是建立在关系数据库模型基础上的数据库，借助于集合代数等概念和方法来处理数据库中的数据。关系数据库的数据内容按照关系表的方式存储在硬盘上，在需要使用时将数据调入内存进行处理。关系数据库处理速度较慢，但成本较低。由于从数据库在主数据库故障时使用，使用频率较低，使用传统的关系数据库不会造成库存***整体的性能明显下降，且能降低成本。

作为一种示例，主数据库可以例如是Redis数据库，从数据库可以例如是MySQL数据库。在具体的实现中，可以将对主数据库的调度与对从数据的操作与调度写在同一事务中，如果主数据库操作失败，则利用从数据库进行回滚，如果从数据库操作失败，则利用从数据库的最新历史成功记录进行回滚，从而时刻保持两个数据库数据的一致性，进而保证数据库中记载的库存数据与真实的库存数据的一致性，从而可以在一定程度上防止库存超卖。

在另一些可选的实施方式中，为了保证主数据库和从数据库的一致性，可以先对两个数据库中的数据进行相同的初始化操作，将相同的库存信息分别存储至主数据库和从数据库中，从而可以更好地保证主数据库和从数据库的一致性，进而可以防止库存超卖。

在另一些可选的实施方式中，为了避免相同的库存操作指令被多次重复操作，还可以加入防重机制。例如可以以订单ID为防重索引，将相应的库存操作***到防重表中，从而可以使从数据库待操作的指令都是不重复的，进而可以保证从数据库的数据真实可靠，若发现指令重复了，则可以实时地利用尚未更新的从数据库对主数据库进行数据回滚，从而可以保证两个数据库数据的一致性，进而可以有效地防止库存超卖。

在另一些可选的实施方式中，为了减轻进行库存扣减操作的主数据库的压力，还可以进行读写分离，即一部分主数据库集群可以负责读数据，例如执行用户请求的读取当前库存的操作，另一部分主数据库集群可以专门负责数据的写入，例如用户的下单请求、付款请求等。进一步地，由于写数据需要有极高的准确度，而读数据则可以允许数据不那么精确，因此还可以以写数据库为主，读数据库为辅，即优先处理写数据库的操作。

在另一些可选的实施方式中，还可以加入预占与锁定机制。在具体实现中，用户下单后可以先给用户一个预占库存以允许用户有一个支付的时间，如果用户超时未支付或者关闭支付则撤销该预占，将位置腾出来给其他用户，从而可以保证商品购买过程的可持续性。通过预占与锁定机制可以允许数据库有一定的缓冲时间，从而在一定程度上防止数据库因为短时间内需要处理的数据太多而发生宕机或者出错。

在另一些可选的实施方式中，还可以采用部分处理机制，即如果等待秒杀的商品为10个，可以只处理前100个请求，对之后的进来的请求显示“秒杀结束”之类的提示信息，然后再进来的这100个请求中先付款成功的先得，后付款的也提示已秒杀结束，从而可以极大地减轻服务器和数据库的压力，使数据库处理的数据量可以大大减少，从而可以有效地防止库存超卖。

在另一些可选的实施方式中，还可以将同一商品参与活动的库存分布在多个数据库中，即多个数据库中的库存相加即为该商品所有的参加活动的库存，并通过负载均衡等手段将进来的请求分散至各个数据库，从而提高处理效率，当其中某个数据库出故障时，还可以通过迁移等方式将可用库存迁移至其他数据库中，从而可以减轻服务器和数据库的压力，进而可以有效地防止库存超卖。

如图2所示为本申请一实施例提供的另一种库存操作方法的流程图，本实施例为与图1中主数据库更新失败的情况相对的主数据库更新成功的情况。其中，步骤201与图1中的步骤101相同。包括如下步骤：

步骤201，响应于下单请求，向主数据库发送第一更新指令，以用于将主数据库中的第一库存数据更新为第二库存数据。

步骤202，当主数据库更新成功时，参照历史订单表对主数据库更新时生成的订单ID进行防重索引。

步骤203，当订单ID在历史订单表中时，利用从数据库中的第一库存数据对主数据库进行数据回滚操作。

步骤204，当订单ID不在历史订单表中时，基于订单ID更新历史订单表。

在本实施方式中，历史订单表为对主数据库历史更新生成的订单ID进行反复防重索引后生成的订单表。其中，反复防重索引的过程如步骤202、步骤203以及步骤204所述。首先，在步骤201中，服务器响应于接收到的下单请求，向主数据发送第一更新指令以用于将主数据库中的第一库存数据更新为第二库存数据。继而，在步骤202中，响应于主数据库更新成功，参照历史订单表对主数据库更新时生成的订单ID进行防重索引，如果历史订单表中存在相同的订单ID号和相同的任务或操作时，例如，订单号均为12345678，任务均为对主数据库和从数据库进行库存扣减，则可以视为相同的订单号和相同的任务，由于订单号和任务都相同，所以无法写入防重表。若订单ID不同，则可以直接写入。因此，之后在步骤203中，当订单ID号和相关的库存任务在历史订单表中时，利用从数据库的第一库存数据对主数据库进行回滚，其中，库存任务根据与之相关的订单ID和相应的订单请求生成，订单请求可以包括下单请求、支付关闭请求、支付失败请求以及退款请求。最后在步骤204中，当订单ID不在历史订单表中时，基于订单ID更新历史订单表。通过将之前不存在的订单ID写入历史订单表中，可以作为之后的订单ID的防重索引表。

本实施方式所描述的方法，通过在主数据库更新成功之后，对主数据库更新生成的订单ID进行防重索引，从而可以在一定程度上避免由于重复下单造成库存数据与真实的库存数据不一致的情况。

进一步参考图3，其示出了本申请一实施例提供的又一种库存操作方法的流程图。本实施例为与图2中“订单ID不在历史订单表中”时后续处理的情况。其中，步骤301与图2中的204相同。具体包括如下步骤：

步骤301，当订单ID不在历史订单表中时，基于订单ID更新历史订单表。

步骤302，向从数据库发送第二更新指令，以用于将从数据库中的第一库存数据更新为第二库存数据。

在本实施方式中，在步骤301中，当订单ID不在历史订单表中时，基于订单ID更新历史订单表，可以将该订单ID与相应的任务***历史订单表中，继而在步骤302中，可以基于该订单表中的相应的记录，向从数据库发送第二更新指令，以用于将从数据库中的第一数据更新为第二数据。

在本实施方式中，第二更新指令是区别于原始的数据库更新指令的指令，例如当需要对数据库中的数据进行更新时，原始的指令一般为“更新”指令，而本实施方式中的第二更新指令为“***”指令，其中，“***”指令比“更新”指令执行的更快，例如“更新”指令达到几千次每秒时，“***”指令可以达到几万次每秒，所以通过使用该第二更新指令更新数据库，与使用数据库原始的更新指令相比，可以达到更快的处理速度，从而提高处理效率，进一步地，可以有效地防止超卖。

本实施方式所描述的方法，通过先进行防重索引，之后只基于不重复的记录生成第二更新指令，从而可以使从数据库的数据不存在重复的，进而可以利用从数据库对主数据库进行防重，从而可以很好地保证主数据库和从数据库数据的一致性，进而保证数据库中记载的库存数据与真实的库存数据的一致性，进一步地，可以有效地防止库存超卖。

进一步参考图4，其示出了本申请一实施例提供的再一种库存操作方法的流程图。本实施例为在图3中的步骤302之后“从数据库更新失败”的情况的流程图。其中，步骤401与步骤302相同。具体包括如下步骤：

步骤401，向从数据库发送第二更新指令，以用于将从数据库中的第一库存数据更新为第二库存数据。

步骤402，当从数据库更新失败时，利用从数据库的第一库存数据对从数据进行数据回滚操作。

步骤403，尝试再次执行第二更新指令。

在本实施方式中，当订单ID不在历史订单ID表中时，将该订单ID和相应的库存任务***历史订单ID表中，形成新的订单ID表，并向从数据库发送第二更新指令以用于将从数据库中的第一库存数据更新为第二库存数据。之后，若从数据库更新失败，则利用从数据库的历史记录中的第一库存数据对从数据库进行数据回滚操作，然后，尝试再次执行第二更新指令。进一步地，若多次尝试(例如可以设为3次)后均更新失败，则可以重新向从数据库发送相应的指令，或者同时对主数据库进行回滚以达成主数据库和从数据库的同步，本申请在此方面没有限制。在一些可选的实施例中，若从数据库更新成功，则可以删除相应的第二更新指令以防止相同的指令被重复执行，具体实现中，可以建立针对从数据库的指令表保存待从数据库执行的指令，当从数据执行完成一条指令就删除一条以防止相同的指令被重复执行，本申请在此方面没有限制。

通过本实施方式的以上步骤，可以实现在从数据库更新失败时也能及时对从数据库进行回滚从而保证从数据库数据的准确性，保证数据库中的库存数据与真实的库存数据的一致性，进而可以有效地防止超卖的现象发生。

如图5所示为本申请一实施例提供的还一种库存操作方法的流程图。本实施例为在图3中的步骤302之后“从数据库更新成功”的情况的流程图。其中，步骤501与步骤302相同。具体包括如下步骤：

步骤501，向从数据库发送第二更新指令，以用于将从数据库中的第一库存数据更新为第二库存数据。

步骤502，当从数据库更新成功时，响应于支付失败通知或退款请求，生成库存还原指令，以用于将从数据库中的第二库存数据还原为第一库存数据。

步骤503，利用从数据库中的成功还原后的第一库存数据对主数据库进行数据回滚操作。

在本实施方式中，步骤501与步骤302相同，在此不再赘述。当从数据库基于第二更新指令更新成功时，服务器响应于接收到的支付失败通知或者退款请求，生成相应的库存还原指令，以用于将从数据库中的第二库存数据还原为第一库存数据。由于支付失败或者收到退款请求，原本成功扣减的库存需要加回来，所以之后可以利用成功还原后的从数据库中的第一库存数据对主数据库进行数据回滚操作以使主数据库中的数据与从数据库中的数据达成一致，以保证数据库中的库存数据与真实的库存数据的一致性，进而可以有效地防止库存超卖。

图6a所示为本申请一实施例提供的库存操作方案的具体实现框架图。其中，主数据库为Redis数据库，从数据库为MySQL数据库。

图6b所述为本申请一实施例提供的库存操作方案的具体实现流程图。

其中，扣减过程可以参考图6b中上半部分，基于下单请求，主数据库更新，当主数据库更新失败时，利用从数据库的数据进行回滚；当主数据库更新成功时，对库存任务进行防重，如果重复，利用从数据库回滚，如果不重复，生成从数据库更新指令，之后从数据库基于该库存更新指令进行更新，更新失败则回滚。

库存还原的过程可以参考图6b中的下半部分，基于库存还原请求，对主数据库和从数据库进行更新，主数据库更新失败时，利用从数据库的数据进行回滚；主数据库更新成功时，对任务进行防重，如果重复，利用从数据库进行回滚，如果不重复，则生成从数据库更新指令，之后从数据库基于改库存更新指令进行更新，更新失败则回滚。

例如：库存***中存在以下几个概念：1.总库存，2.预占库存，3.已卖库存，4.可用库存，一个商品库存操作的方法和过程：

1.初始化商品的总库存和可用库存，分别存至Redis和MySQL数据库。

2.扣减库存：用户下单时，从Redis中减可用库存，加预占库存，同时生成库存操作指令“减可用加预占”。如果下单失败则进行库存还原，回滚Redis库存，同时生成库存操作指令“加可用，减预占”。

3.库存还原：以订单ID为防重索引，将库存操作的任务***到防重表中。支付失败，生成操作指令“加可用减预占”；支付成功，生成操作指令“减预占加已卖”；产生退款，生成操作指令“减预占加可用”。

4.库存同步：由调度任务实时分析指令，执行库存还原任务，将库存数据更新至Redis与数据库中，完成后删除该任务。

以上方案至少存在以下有益效果：

1.使用Redis对库存进行操作，性能高效，是数据库不可比拟的。

2.以指令方式进行数据同步，同时做防重处理，保证不会超卖。

3.库存支持预占与锁定模式，支持下单超时、关闭后的快速回复，保证商品购买过程的可持续性。

4.Redis异常库存可快速回滚。

如图7所示为本申请一实施例提供的一种库存操作***的结构示意图，本实施例的技术方案可适用于服务器对主数据库和从数据库的库存操作，该***可执行上述任意实施例所述的库存操作方法，并配置在服务器端。

本实施例提供的一种库存操作***700，包括：下单模块701和失败回滚模块702。其中，下单模块，配置用于响应于下单请求，向主数据库发送第一更新指令，以用于将所述主数据库中的第一库存数据更新为第二库存数据；以及失败回滚模块，配置用于当所述主数据库更新失败时，利用从数据库中的第一库存数据对所述主数据库进行数据回滚操作。通过以上模块，库存操作***可以实现在主数据库发生故障时，及时使用从数据库对其进行库存回滚，保证数据库中的库存与真实的库存一致，从而可以防止库存超卖。

进一步地，所述***还包括：防重索引模块，配置用于当所述主数据库更新成功时，参照历史订单表对所述主数据库更新时生成的订单ID进行防重索引；防重回滚模块，配置用于当所述订单ID在所述历史订单表中时，利用从数据库中的第一库存数据对所述主数据库进行数据回滚操作；更新模块，配置用于当所述订单ID不在所述历史订单表中时，基于所述订单ID更新所述历史订单表。

进一步地，所述***还包括配置用于：向所述从数据库发送第二更新指令，以用于将所述从数据库中的第一库存数据更新为第二库存数据。

进一步地，所述***还包括配置用于：当所述从数据库更新失败时，利用所述从数据库的第一库存数据对所述从数据进行数据回滚操作；尝试再次执行所述第二更新指令。

进一步地，所述***还包括配置用于：当所述从数据库更新成功时，响应于支付失败通知或退款请求，生成库存还原指令，以用于将所述从数据库中的第二库存数据还原为第一库存数据；同时利用从数据库中的成功还原后的第一库存数据对所述主数据库进行数据回滚操作。

本申请实施例提供了一种非易失性计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令可执行上述任意方法实施例中的库存操作方法；

作为一种实施方式，本发明的非易失性计算机存储介质存储有计算机可执行指令，所述计算机可执行指令设置为:

响应于下单请求，向主数据库发送第一更新指令，以用于将所述主数据库中的第一库存数据更新为第二库存数据；

当所述主数据库更新失败时，利用从数据库中的第一库存数据对所述主数据库进行数据回滚操作。

作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本申请实施例中的库存操作方法对应的程序指令/模块(例如，附图7所示的下单模块701和失败回滚模块702)。所述一个或者多个模块存储在所述非易失性计算机可读存储介质中，当被处理器执行时，执行上述任意方法实施例中的库存操作方法。

非易失性计算机可读存储介质可以包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需要的应用程序；存储数据区可存储根据库存操作装置的使用所创建的数据等。此外，非易失性计算机可读存储介质可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，非易失性计算机可读存储介质可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至库存操作装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括存储在非易失性计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行上述任一项库存操作方法。

图8是本申请一实施例提供的电子设备的结构示意图，如图8所示，该设备包括：

一个或多个处理器810以及存储器820，图8中以一个处理器810为例。

库存操作方法的设备还可以包括：输入装置830和输出装置840。

处理器810、存储器820、输入装置830和输出装置840可以通过总线或者其他方式连接，图8中以通过总线连接为例。

存储器820为上述的非易失性计算机可读存储介质。处理器810通过运行存储在存储器820中的非易失性软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例库存操作方法。

输入装置830可接收输入的数字或字符信息，以及产生与库存操作装置的用户设置以及功能控制有关的键信号输入。输出装置840可包括显示屏等显示设备。

上述产品可执行本申请实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法。

作为一种实施方式，上述电子设备包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

响应于下单请求，向主数据库发送第一更新指令，以用于将主数据库中的第一库存数据更新为第二库存数据；

当主数据库更新失败时，利用从数据库中的第一库存数据对主数据库进行数据回滚操作。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括:智能手机(例如iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括:音频、视频播放器(例如iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器:提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、***总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (11)

1.一种库存操作方法，包括：

响应于下单请求，向主数据库发送第一更新指令，以用于将所述主数据库中的第一库存数据更新为第二库存数据；

当所述主数据库更新失败时，利用从数据库中的第一库存数据对所述主数据库进行数据回滚操作。

2.根据权利要求1所述的方法，其中，所述方法包括：

当所述主数据库更新成功时，参照历史订单表对所述主数据库更新时生成的订单ID进行防重索引；

当所述订单ID在所述历史订单表中时，利用从数据库中的第一库存数据对所述主数据库进行数据回滚操作；

当所述订单ID不在所述历史订单表中时，基于所述订单ID更新所述历史订单表。

3.根据权利要求2所述的方法，其中，在当所述订单ID不在所述历史订单表中时，基于所述订单ID更新所述历史订单表之后，所述方法包括：

向所述从数据库发送第二更新指令，以用于将所述从数据库中的第一库存数据更新为第二库存数据。

4.根据权利要求3所述的方法，其中，在向所述从数据库发送第二更新指令，以用于将所述从数据库中的第一库存数据更新为第二库存数据之后，所述方法还包括：

当所述从数据库更新失败时，利用所述从数据库的第一库存数据对所述从数据库进行数据回滚操作；

尝试再次执行所述第二更新指令。

5.根据权利要求3所述的方法，其中，在向所述从数据库发送第二更新指令，以用于将所述从数据库中的第一库存数据更新为第二库存数据之后，所述方法还包括：

当所述从数据库更新成功时，响应于支付失败通知或退款请求，生成库存还原指令，以用于将所述从数据库中的所述第二库存数据还原为所述第一库存数据；

利用所述从数据库中的成功还原后的第一库存数据对所述主数据库进行数据回滚操作。

6.一种库存操作***，包括：

下单模块，配置用于响应于下单请求，向主数据库发送第一更新指令，以用于将所述主数据库中的第一库存数据更新为第二库存数据；

失败回滚模块，配置用于当所述主数据库更新失败时，利用从数据库中的第一库存数据对所述主数据库进行数据回滚操作。

7.根据权利要求6所述的***，其中，所述***还包括：

防重索引模块，配置用于当所述主数据库更新成功时，参照历史订单表对所述主数据库更新时生成的订单ID进行防重索引；

防重回滚模块，配置用于当所述订单ID在所述历史订单表中时，利用从数据库中的第一库存数据对所述主数据库进行数据回滚操作；

更新模块，配置用于当所述订单ID不在所述历史订单表中时，基于所述订单ID更新所述历史订单表。

8.根据权利要求7所述的***，其中，所述***还包括配置用于：

向所述从数据库发送第二更新指令，以用于将所述从数据库中的第一库存数据更新为第二库存数据。

9.根据权利要求8所述的***，其中，所述***还包括配置用于：

当所述从数据库更新失败时，利用所述从数据库的第一库存数据对所述从数据库进行数据回滚操作；

尝试再次执行所述第二更新指令。

10.根据权利要求8中所述的***，其中，所述***还包括配置用于：

当所述从数据库更新成功时，响应于支付失败通知或退款请求，生成库存还原指令，以用于将所述从数据库中的所述第二库存数据还原为所述第一库存数据；

利用所述从数据库中的成功还原后的第一库存数据对所述主数据库进行数据回滚操作。

11.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；

其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-5中任一项所述的库存操作方法。