CN111752957A - 一种基于缓存化的销售锁定方法及系统 - Google Patents

Abstract

本发明公开了一种基于缓存化的销售锁定方法及系统，该方法包括如下步骤：S1：将商品信息按照商品编码取模分成若干份，按照预设规则分别存储于Redis相应编码的缓存库中；S2：获取并解析商品的销售锁定请求，得到请求列表；S3：根据请求列表，在同一事务内，记录库存变化中间表，然后对Redis相应编码的缓存库中的商品信息进行更新；S4：根据库存变化中间表，使用秒级JOB异步更新数据库中的商品信息。本发明避免使用单一的Redis缓存库存储大量数据，提升查询的效率，使用LUA脚本的原子性代替数据库事务保证数据的一致性，利用Redis单线程的特性，进行库存并发控制，使用灰度状态来解决数据切到缓存过程中有请求过来时，处理数据导致缓存和数据库数据不一致的问题。

Description

一种基于缓存化的销售锁定方法及系统

技术领域

本发明涉及计算机软件技术领域，特别涉及一种基于缓存化的销售锁定方法及系统。

背景技术

随着互联网的发展，传统的商店逐渐被网上购物平台所取代。越来越多的用户选择在网上购物，同时网购平台为了吸引用户，推出了多种多样的促销活动，例如：秒杀、抢购、拼购等。促销活动会产生瞬间的高并发，对整个交易链路处理效率提出了很高的要求，库存数量的维护是其中核心的一环，高效处理也至关重要。

目前的库存扣减方法中，销售锁定(临时锁+正式锁)和交货锁定(物流交货)采用基于数据库+应用锁技术的方案做库存数量维护，而且业务方面的处理采用的是串行的处理方式，处理效率非常低下，不能满足目前的业务场景。尤其是在抢购的场景下，同一商品销售锁定请求会出现高并发，相同商品并发请求时，先获取锁的请求先执行，且需等待库存管理系统的处理结果返回后，才会依次执行后面的请求。整个过程中，多次与数据库进行交互，需要消耗大量的网络延时，而且DB(数据库)的TPS处理能力也是有限的，随着DB(数据库)存储数据量增大，TPS处理能力也会逐渐下降，从而数据库的处理时间也会增加。用户购物界面会一直处于等待状态，这大大降低了顾客在网上购物的体验。

综上所述，目前的库存扣减方法中，存在以下问题：

1、采用串行的处理方式，在高并发的情况下，处理效率低；

2、相同商品保存到同一个数据库中，单台DB处理同一商品的销售锁定TPS一般不超过200，对数据库服务器的性能要求高。而且几十台DB，也只能支持上千的TPS，性能严重不足，不能满足秒杀、抢购等热点商品的促销业务，造成很不好的用户体验。

发明内容

为了解决现有技术的问题，本发明实施例提供了一种基于缓存化的销售锁定方法及装置，以克服现有技术中的销售锁定在处理高并发时DB性能瓶颈，促销时TPS处理能力低而系统库存结构单一，不能满足业务需求，以及需要预先维护活动等问题。

为解决上述一个或多个技术问题，本发明采用的技术方案是：

一方面，提供了一种基于缓存化的销售锁定方法：

S1：将商品信息按照商品编码取模分成若干份，按照预设规则分别存储于Redis相应编码的缓存库中；

S2：获取并解析所述商品的销售锁定请求，得到请求列表；

S3：根据所述请求列表，在同一事务内，记录库存变化中间表，然后对所述Redis相应编码的缓存库中的所述商品信息进行更新；

S4：根据所述库存变化中间表，使用秒级JOB异步更新数据库中的所述商品信息。

进一步的，所述步骤S3具体包括：

S3.1：根据所述请求列表的条数，选择开启多线程处理请求或单线程处理请求；

S3.2：遍历所述请求列表中的请求，校验所述请求的内容，若校验通过则执行步骤S3.3，否则，将未通过的请求封装，并继续校验所述请求列表中的剩余请求；

S3.3：查询所述请求是否在销售锁定表中，若不在，则在所述销售锁定表新增所述请求后，执行步骤S3.4，否则直接执行步骤S3.4；

S3.4：记录库存变化中间表，并对所述Redis相应编码的缓存库中的所述商品信息进行更新。

进一步的，所述对所述Redis相应编码的缓存库中的所述商品信息进行更新具体包括：

使用Lua脚本原子操作Redis缓存，计算所述请求对应的商品的库存是否满足所述请求，若满足，则修改所述商品信息中的库存数量，否则返回失败。

进一步的，所述步骤S4具体包括：

S4.1：查询所述库存变化中间表中是否有数据，若有，则开启DB事务，更新数据库中的所述商品信息，否则不作处理；

S4.2：判断所述DB事务操作是否成功，若成功，则提交所述DB事务操作，否则回滚后执行步骤S4.3；

S4.3：重新根据所述库存变化中间表的数据执行所述DB事务操作，直至执行成功。

进一步的，所述根据所述请求列表，对所述Redis相应编码的缓存库中的所述商品信息进行更新前还包括：

设置商品的灰度状态包括灰度内、灰度外和切换中；

判断所述请求列表中的请求对应的商品的灰度状态，若是在切换中，则直接返回处理失败。

另一方面，提供了一种信息无痕曝光采集装置，所述装置包括：

划分模块，用于将商品信息按照商品编码取模分成若干份，按照预设规则分别存储于Redis相应编码的缓存库中；

解析模块，用于获取并解析所述商品的销售锁定请求，得到请求列表；

第一更新模块，用于根据所述请求列表，在同一事务内，记录库存变化中间表，然后对所述Redis相应编码的缓存库中的所述商品信息进行更新；

第二更新模块，用于根据所述库存变化中间表，使用秒级JOB异步更新数据库中的所述商品信息。

进一步的，所述第一更新模块包括：

第一判断单元，用于根据所述请求列表的条数，选择开启多线程处理请求或单线程处理请求；

检验单元，用于遍历所述请求列表中的请求，校验所述请求的内容；

第一查询单元，用于查询所述请求是否在销售锁定表中；

第一更新单元，用于记录库存变化中间表，并对所述Redis相应编码的缓存库中的所述商品信息进行更新。

进一步的，所述第一更新单元具体用于：

使用Lua脚本原子操作Redis缓存，计算所述请求对应的商品的库存是否满足所述请求，若满足，则修改所述商品信息中的库存数量，否则返回失败。

进一步的，所述第二更新模块包括：

第二查询单元，用于查询所述库存变化中间表中是否有数据；

第二判断单元，用于判断所述DB事务操作是否成功，若成功，则提交所述DB事务操作，否则回滚后重新根据所述库存变化中间表的数据执行所述DB事务操作；

第二更新单元，用于开启DB事务，更新数据库中的所述商品信息。

进一步的，所述装置还包括：

设置模块，用于设置商品的灰度状态包括灰度内、灰度外和切换中；

判断模块，用于判断所述请求列表中的请求对应的商品的灰度状态，若是在切换中，则直接返回处理失败。

本发明实施例提供的技术方案带来的有益效果是：

1、本发明实施例提供的基于缓存化的销售锁定方法及装置，将商品信息按照商品编码取模分成若干份，按照预设规则分别分别存储于Redis的相应编码的缓存库中，避免使用单一的Redis缓存库存储大量数据，提升查询的效率；

2、本发明实施例提供的基于缓存化的销售锁定方法及装置，通过利用LUA脚本的原子性代替数据库事务保证数据的一致性，利用Redis单线程的特性，进行库存并发控制；

3、本发明实施例提供的基于缓存化的销售锁定方法及装置，通过将复杂的数据结构放入缓存(Redis缓存库)，再利用LUA进行库存数量查询运算以及扣减，提高处理效率，且通过秒级JOB异步更新数据库，并设置秒级JOB采用重试机制，最终保证缓存和数据库中的数据一致；

4、本发明实施例提供的基于缓存化的销售锁定方法及装置，使用灰度内、灰度外、切换中三种状态，判断数据的位置，然后进行维护，使用灰度状态来解决数据切到缓存过程中，有请求过来时，处理数据导致缓存和数据库数据不一致的问题。

附图说明

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

图1是根据一示例性实施例示出的基于缓存化的销售锁定方法的流程图；

图2是根据一示例性实施例示出的根据所述请求列表，对Redis相应编码的缓存库中的商品信息进行更新，并在库存变化中间表中记录的流程图；

图3是根据一示例性实施例示出的根据库存变化中间表，使用秒级JOB异步更新数据库中的商品信息的流程图；

图4是根据一示例性实施例示出的基于缓存化的销售锁定装置的结构示意图。

具体实施方式

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

本发明实施例提供的基于缓存化的销售锁定方法及装置，将库存缓存化操作，并通过秒级JOB将缓存库中的库存变化，通过异步的方式与DB(数据库)的库存数量进行同步，保证缓存库中的数量与DB中的数量保持一致。当开展秒杀、抢购等促销活动时，扣减库存业务不再是直接操作DB，而是只对缓存进行操作，在缓存中进行库存的扣减，操作成功后直接返回用户购买成功。然后再通过异步的方式将缓存库中的数据与DB的数据进行同步，不但提高了处理效率，而且很好的解决了数据库的瓶颈，同时也提升了用户的购物体验。

图1是根据一示例性实施例示出的基于缓存化的销售锁定方法的流程图，参照图1所示，该方法包括如下步骤：

S1：将商品信息按照商品编码取模分成若干份，按照预设规则分别存储于Redis相应编码的缓存库中。

具体的，Redis缓存库默认支持16个缓存库，作为一种示例性举例，本发明实施例中，将商品信息按照商品编码取模(通常商品编码都是数字组成，因为这里是将商品编码平均分成16份，所以可以将数字(即商品编码)％16，获得的数据就是0-15)分成16份，然后按照预设规则(例如，将商品编码％16，结果为0，则放0库，为1则放1库，以此类推，为15则放15库)分别存储于编码为0-15的Redis的缓存库中。这样设置可以将数据数据尽可能的在16个库中都有存储，避免使用单一的Redis缓存库存储大量数据，造成查询速度慢的问题，即减少一个库的压力，提高查询的效率。这里需要说明的是，将Redis缓存库设置为16个缓存库只是一种示例性说明，用户可以根据具体需求，通过配置参数databases来修改Redis支持的缓存库的数量，将商品信息划分成与Redis支持的缓存库的数量相同的份数。

S2：获取并解析所述商品的销售锁定请求，得到请求列表。

具体的，从外围系统(这里指电商销售平台)获取商品的销售锁定请求后，首先销售锁定请求进行解析处理，解析成功得到请求列表后才会进行操作，若是解析失败，则直接返回失败。请求至少包括对商品的库存的扣减等在销售阶段，外围系统可以通过调用实时锁定接口，进行销售锁定记录的新增、Redis缓存库的库存数量的修改、记录库存变化中间表，然后将结果返回外围系统。

S3：根据所述请求列表，在同一事务内，记录库存变化中间表，然后对所述Redis相应编码的缓存库中的所述商品信息进行更新。

具体的，对Redis相应编码的缓存库中的商品信息进行更新包括修改Redis缓存库中相应商品的库存数量等。本发明实施例中，将复杂的数据结构放入缓存，再在缓存中进行库存数量查询运算以及扣减，减少与数据库进行交互，提高处理效率。这里需要说明的是，将DB操作(即记录库存变化中间表)和缓存操作，放在DB的事务中，且优先处理DB操作，然后处理缓存，至少具有以下优点：(1)DB操作失败，直接回滚，不再操作缓存；(2)DB操作成功，缓存失败，DB也会回滚；(3)DB操作和缓存操作都成功，这个操作才算成功，避免了DB操作失败，缓存回滚难的问题。如果这个顺序发生改变(即优先处理缓存，然后处理DB操作)，会存在缓存操作成功，但是DB操作失败的情况，DB能正常回滚，但是Redis已经操作成功了，就需要人为去回滚，而Redis回滚比较复杂，容易导致出错的概率。

S4：根据所述库存变化中间表，使用秒级JOB异步更新数据库中的所述商品信息。

具体的，通过秒级JOB异步根据库存变化中间表的修改记录，更新数据库中相应商品的商品信息(库存数量等)。本发明实施例中，秒级JOB采用重试和手动处理机制，如果同步过程中发生错误，会自动重试，超过一定次数仍失败，则停止同步当前的这条数据，接着执行剩余的数据，处理失败的数据可以人工操作维护到数据库，最终使数据库中数据(如库存数量)与Redis缓存库的数据保持一致。

图2是根据一示例性实施例示出的根据所述请求列表，对Redis相应编码的缓存库中的商品信息进行更新，并在库存变化中间表中记录的流程图，参照图2所示，作为一种较优的实施方式，本发明实施例中，所述步骤S3具体包括：

S3.1：根据所述请求列表的条数，选择开启多线程处理请求或单线程处理请求。

具体的，查询请求列表中查询请求列表中请求的条数，判断是否开启多线程处理，如果请求的条数满足多线程处理的条件，则开启多线程处理请求，否则单线程处理请求。作为一种较优的实施方式，本发明实施例中，可以预先设置一个阈值，将请求的条数与预设的阈值进行比较，若是请求的条数大于该阈值，则则开启多线程处理请求，否则单线程处理请求。这里需要说明的是，该阈值可以根据用户的具体需求进行设置。

S3.2：遍历所述请求列表中的请求，校验所述请求的内容，若校验通过则执行步骤S3.3，否则，将未通过的请求封装，并继续校验所述请求列表中的剩余请求。

具体的，循环处理请求列表中的请求，处理请求之前，需要先校验请求的内容，通过校验则会继续执行(即执行步骤S3.3)，若是校验未通过，则将未通过的请求进行封装，并继续校验请求列表中的剩余请求。

S3.3：查询所述请求是否在销售锁定表中，若不在，则在所述销售锁定表新增所述请求后，执行步骤S3.4，否则直接执行步骤S3.4。

具体的，请求校验成功后，查询当前请求是否已经在销售锁定表中，若是存在，则继续执行下一步(即执行步骤S3.4)，否则需要先在销售锁定表中新增该请求，然后继续执行下一步(即执行步骤S3.4)。在销售锁定表中新增请求可以通过调用销售组件新增处理。调用销售组件新增处理流程包括：在数据库中保存该请求对应的销售记录以及在库存变化中间表上记录该销售记录等。

S3.4：记录库存变化中间表，并对所述Redis相应编码的缓存库中的所述商品信息进行更新。

具体的，根据该请求对应的销售记录，先将其记录在库存变化中间表上，然后再对Redis相应编码的缓存库中相应的商品信息进行更新，商品信息的更新包括库存数量的修改等。保证Redis缓存库与数据库中数据的一致性。

作为一种较优的实施方式，本发明实施例中，所述对所述Redis相应编码的缓存库中的所述商品信息进行更新具体包括：

使用Lua脚本原子操作Redis缓存，计算所述请求对应的商品的库存是否满足所述请求，若满足，则修改所述商品信息中的库存数量，否则返回失败。

具体的，在本发明实施例中，利用LUA脚本的原子性，代替Redis分布式锁，进行库存并发控制。将复杂的数据结构(商品销售记录等数据)放入缓存，再利用LUA脚本进行库存数量查询运算(计算请求对应的商品的库存是否满足请求)，若满足，则修改商品信息中的库存数量后继续处理后面的请求，否则返回失败。使用LUA脚本将选择Redis库和操作Redis库这两次操作合并一起，还可以保证在并发情况下，选择Redis库和操作Redis库的正确性，即确保每次能正确选择Redis库和操作数据。

图3是根据一示例性实施例示出的根据库存变化中间表，使用秒级JOB异步更新数据库中的商品信息的流程图，参照图3所示，作为一种较优的实施方式，本发明实施例中，所述步骤S4具体包括：

S4.1：查询所述库存变化中间表中是否有数据，若有，则开启DB事务，更新数据库中的所述商品信息，否则不作处理。

具体的，首先查询库存变化中间表中是否有数据，若有，则说明Redis相应编码的缓存库中的商品信息有进行过更新，此时开启DB事务，根据库存变化中间表对数据库中的商品信息进行更新，若是没有，则说明Redis相应编码的缓存库中的商品信息没有进行过更新，此时不作处理，直接结束该流程。其中，DB事务包括：修改对应商品库存数量表中的数量、保存流水、保存商品状态、保存下发中间表等操作。

S4.2：判断所述DB事务操作是否成功，若成功，则提交所述DB事务操作，否则回滚后执行步骤S4.3。

具体的，DB事务操作完成后，还需要判断此次DB事务操作是否成功，若成功，则提交所述DB事务操作，否则回滚后执行下一步(执行步骤S4.3)。这样操作，可以防止数据库表面完成更新实际却未完成更新，有效保证缓存库和数据库中的数据一致。

S4.3：重新根据所述库存变化中间表的数据执行所述DB事务操作，直至执行成功。

具体的，本发明实施例中，秒级JOB开启重试机制，如果回滚，则重新执行成功的数据，直至执行成功。这里需要说明的是，本发明实施例中，秒级JOB还采用手动处理机制，预先设置一个重试次数的阈值。如果同步过程中发生错误，会自动重试，超过重试次数的阈值，则停止同步当前的这条数据，接着执行剩余的数据，处理失败的数据通过手动处理(人工操作)维护到数据库，最终使库存数量表与Redis缓存的数据保持一致。

作为一种较优的实施方式，本发明实施例中，所述根据所述请求列表，对所述Redis相应编码的缓存库中的所述商品信息进行更新前还包括：

设置商品的灰度状态包括灰度内、灰度外和切换中；

判断所述请求列表中的请求对应的商品的灰度状态，若是在切换中，则直接返回处理失败。

具体的，将商品的灰度状态设置为灰度内、灰度外和切换中三种状态，使用灰度内、灰度外、切换中三种状态，判断数据的位置，然后进行维护。当有数据请求维护时，需要先判断当前商品的灰度状态，如果在切换中，就直接返回处理失败。维护缓存库存数量后，需再次检查当前数据的灰度状态，如果在切换中，就返回处理失败，并按照操作流水回滚缓存中的数据，避免在数据切换过程中修改数据，导致缓存和数据库数据不一致的问题。

图4是根据一示例性实施例示出的基于缓存化的销售锁定装置的结构示意图，参照图4所述，该装置包括：

划分模块，用于将商品信息按照商品编码取模分成若干份，按照预设规则分别存储于Redis相应编码的缓存库中；

解析模块，用于获取并解析所述商品的销售锁定请求，得到请求列表；

第一更新模块，用于根据所述请求列表，在同一事务内，记录库存变化中间表，然后对所述Redis相应编码的缓存库中的所述商品信息进行更新；

第二更新模块，用于根据所述库存变化中间表，使用秒级JOB异步更新数据库中的所述商品信息。

作为一种较优的实施方式，本发明实施例中，所述第一更新模块包括：

第一判断单元，用于根据所述请求列表的条数，选择开启多线程处理请求或单线程处理请求；

检验单元，用于遍历所述请求列表中的请求，校验所述请求的内容；

具体的，若是校验通过，则执行下一步，即查询所述请求是否在销售锁定表，若是校验未通过，将未通过的请求封装，并继续校验所述请求列表中的剩余请求。

第一查询单元，用于查询所述请求是否在销售锁定表中；

具体的，若是请求不在销售锁定表中，则在销售锁定表新增请求后，执行下一步(对所述Redis相应编码的缓存库中的所述商品信息进行更新，并生成库存变化中间表)，否则直接执行下一步(对所述Redis相应编码的缓存库中的所述商品信息进行更新，并生成库存变化中间表)。

第一更新单元，用于记录库存变化中间表，并对所述Redis相应编码的缓存库中的所述商品信息进行更新。

作为一种较优的实施方式，本发明实施例中，所述第一更新单元具体用于：

使用Lua脚本原子操作Redis缓存，计算所述请求对应的商品的库存是否满足所述请求，若满足，则修改所述商品信息中的库存数量，否则返回失败。

作为一种较优的实施方式，本发明实施例中，所述第二更新模块包括：

第二查询单元，用于查询所述库存变化中间表中是否有数据；

第二判断单元，用于判断所述DB事务操作是否成功，若成功，则提交所述DB事务操作，否则回滚后重新根据所述库存变化中间表的数据执行所述DB事务操作；

第二更新单元，用于开启DB事务，更新数据库中的所述商品信息。

作为一种较优的实施方式，本发明实施例中，所述装置还包括：

设置模块，用于设置商品的灰度状态包括灰度内、灰度外和切换中；

判断模块，用于判断所述请求列表中的请求对应的商品的灰度状态，若是在切换中，则直接返回处理失败。

综上所述，本发明实施例提供的技术方案带来的有益效果是：

1、本发明实施例提供的基于缓存化的销售锁定方法及装置，将商品信息按照商品编码取模分成若干份，按照预设规则分别分别存储于Redis的相应编码的缓存库中，避免使用单一的Redis缓存库存储大量数据，提升查询的效率；

2、本发明实施例提供的基于缓存化的销售锁定方法及装置，通过利用LUA脚本的原子性代替数据库事务保证数据的一致性，利用Redis单线程的特性，进行库存并发控制；

3、本发明实施例提供的基于缓存化的销售锁定方法及装置，通过将复杂的数据结构放入缓存(Redis缓存库)，再利用LUA进行库存数量查询运算以及扣减，提高处理效率，且通过秒级JOB异步更新数据库，并设置秒级JOB采用重试机制，最终保证缓存和数据库中的数据一致；

4、本发明实施例提供的基于缓存化的销售锁定方法及装置，使用灰度内、灰度外、切换中三种状态，判断数据的位置，然后进行维护，使用灰度状态来解决数据切到缓存过程中，有请求过来时，处理数据导致缓存和数据库数据不一致的问题。

需要说明的是：上述实施例提供的基于缓存化的销售锁定装置在触发销售锁定业务时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的基于缓存化的销售锁定装置与基于缓存化的销售锁定方法实施例属于同一构思，即该装置是基于该基于缓存化的销售锁定方法的，其具体实现过程详见方法实施例，这里不再赘述。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于缓存化的销售锁定方法，其特征在于，所述方法包括如下步骤：

S1：将商品信息按照商品编码取模分成若干份，按照预设规则分别存储于Redis相应编码的缓存库中；

S2：获取并解析所述商品的销售锁定请求，得到请求列表；

S3：根据所述请求列表，在同一事务内，记录库存变化中间表，然后对所述Redis相应编码的缓存库中的所述商品信息进行更新；

S4：根据所述库存变化中间表，使用秒级JOB异步更新数据库中的所述商品信息。

2.根据权利要求1所述的基于缓存化的销售锁定方法，其特征在于，所述步骤S3具体包括：

S3.1：根据所述请求列表的条数，选择开启多线程处理请求或单线程处理请求；

S3.2：遍历所述请求列表中的请求，校验所述请求的内容，若校验通过则执行步骤S3.3，否则，将未通过的请求封装，并继续校验所述请求列表中的剩余请求；

S3.3：查询所述请求是否在销售锁定表中，若不在，则在所述销售锁定表新增所述请求后，执行步骤S3.4，否则直接执行步骤S3.4；

S3.4：记录库存变化中间表，并对所述Redis相应编码的缓存库中的所述商品信息进行更新。

3.根据权利要求2所述的基于缓存化的销售锁定方法，其特征在于，所述对所述Redis相应编码的缓存库中的所述商品信息进行更新具体包括：

使用Lua脚本原子操作Redis缓存，计算所述请求对应的商品的库存是否满足所述请求，若满足，则修改所述商品信息中的库存数量，否则返回失败。

4.根据权利要求1或2所述的基于缓存化的销售锁定方法，其特征在于，所述步骤S4具体包括：

S4.1：查询所述库存变化中间表中是否有数据，若有，则开启DB事务，更新数据库中的所述商品信息，否则不作处理；

S4.2：判断所述DB事务操作是否成功，若成功，则提交所述DB事务操作，否则回滚后执行步骤S4.3；

S4.3：重新根据所述库存变化中间表的数据执行所述DB事务操作，直至执行成功。

5.根据权利要求1或2所述的基于缓存化的销售锁定方法，其特征在于，所述根据所述请求列表，对所述Redis相应编码的缓存库中的所述商品信息进行更新前还包括：

设置商品的灰度状态包括灰度内、灰度外和切换中；

判断所述请求列表中的请求对应的商品的灰度状态，若是在切换中，则直接返回处理失败。

6.一种基于缓存化的销售锁定系统，其特征在于，所述系统包括：

划分模块，用于将商品信息按照商品编码取模分成若干份，按照预设规则分别存储于Redis相应编码的缓存库中；

解析模块，用于获取并解析所述商品的销售锁定请求，得到请求列表；

第一更新模块，用于根据所述请求列表，在同一事务内，记录库存变化中间表，然后对所述Redis相应编码的缓存库中的所述商品信息进行更新；

第二更新模块，用于根据所述库存变化中间表，使用秒级JOB异步更新数据库中的所述商品信息。

7.根据权利要求6所述的基于缓存化的销售锁定系统，其特征在于，所述第一更新模块包括：

第一判断单元，用于根据所述请求列表的条数，选择开启多线程处理请求或单线程处理请求；

检验单元，用于遍历所述请求列表中的请求，校验所述请求的内容；

第一查询单元，用于查询所述请求是否在销售锁定表中；

第一更新单元，用于记录库存变化中间表，并对所述Redis相应编码的缓存库中的所述商品信息进行更新。

8.根据权利要求7所述的基于缓存化的销售锁定系统，其特征在于，所述第一更新单元具体用于：

使用Lua脚本原子操作Redis缓存，计算所述请求对应的商品的库存是否满足所述请求，若满足，则修改所述商品信息中的库存数量，否则返回失败。

9.根据权利要求6或7所述的基于缓存化的销售锁定系统，其特征在于，所述第二更新模块包括：

第二查询单元，用于查询所述库存变化中间表中是否有数据；

第二判断单元，用于判断所述DB事务操作是否成功，若成功，则提交所述DB事务操作，否则回滚后重新根据所述库存变化中间表的数据执行所述DB事务操作；

第二更新单元，用于开启DB事务，更新数据库中的所述商品信息。

10.根据权利要求6或7所述的基于缓存化的销售锁定系统，其特征在于，所述系统还包括：

设置模块，用于设置商品的灰度状态包括灰度内、灰度外和切换中；

判断模块，用于判断所述请求列表中的请求对应的商品的灰度状态，若是在切换中，则直接返回处理失败。

Images