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

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

Info

Publication number
WO2020192063A1
WO2020192063A1 PCT/CN2019/109094 CN2019109094W WO2020192063A1 WO 2020192063 A1 WO2020192063 A1 WO 2020192063A1 CN 2019109094 W CN2019109094 W CN 2019109094W WO 2020192063 A1 WO2020192063 A1 WO 2020192063A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
sales
redis
cache
update
Prior art date
Application number
PCT/CN2019/109094
Other languages
English (en)
French (fr)
Inventor
杨庆枫
司孝波
秦刚
王康龙
李磊
Original Assignee
苏宁云计算有限公司
苏宁易购集团股份有限公司
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 苏宁云计算有限公司, 苏宁易购集团股份有限公司 filed Critical 苏宁云计算有限公司
Priority to CA3176449A priority Critical patent/CA3176449A1/en
Publication of WO2020192063A1 publication Critical patent/WO2020192063A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
    • G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2471—Distributed queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders

Definitions

  • the present invention relates to the technical field of computer software, and in particular to a sales locking method and system based on caching.
  • the current inventory deduction method has the following problems:
  • the same product is stored in the same database, and a single DB handles the sales lock TPS of the same product generally not exceeding 200, which requires high performance of the database server.
  • dozens of DBs can only support thousands of TPS, and their performance is severely insufficient. They cannot meet the promotion business of hot commodities such as spikes and panic buying, resulting in a very bad user experience.
  • the embodiments of the present invention provide a caching-based sales locking method and device to overcome the DB performance bottleneck of sales locking in the prior art when processing high concurrency and low TPS processing capacity during promotion.
  • the system inventory structure is single, cannot meet business needs, and requires pre-maintenance activities.
  • the technical solution adopted by the present invention is:
  • step S3 specifically includes:
  • step S3.2 Traverse the requests in the request list, verify the content of the request, if the verification is passed, perform step S3.3, otherwise, encapsulate the failed request, and continue to verify the request list Remaining requests;
  • step S3.3 Query whether the request is in the sales lock table, if not, after the request is added to the sales lock table, perform step S3.4, otherwise directly perform step S3.4;
  • the updating the commodity information in the cache library corresponding to the Redis encoding specifically includes:
  • Lua script Use the Lua script to atomically operate the Redis cache to calculate whether the inventory of the product corresponding to the request meets the request, if so, modify the inventory quantity in the product information, otherwise return a failure.
  • step S4 specifically includes:
  • the method before updating the commodity information in the cache library corresponding to the Redis encoding according to the request list, the method further includes:
  • a device for seamless exposure and collection of information which includes:
  • the division module is used to divide the product information into several parts according to the product code, and store them in the corresponding coded cache library of Redis according to preset rules;
  • the parsing module is used to obtain and analyze the sales lock request of the commodity to obtain the request list;
  • the first update module is configured to record the inventory change intermediate table in the same transaction according to the request list, and then update the commodity information in the cache library corresponding to the Redis encoding;
  • the second update module is used to asynchronously update the commodity information in the database using the second JOB according to the inventory change intermediate table.
  • the first update module includes:
  • the first judging unit is configured to select whether to enable multi-thread processing request or single-thread processing request according to the number of the request list;
  • the checking unit is used to traverse the requests in the request list and check the content of the request
  • the first query unit is used to query whether the request is in the sales lock table
  • the first update unit is used to record the inventory change intermediate table and update the commodity information in the cache library corresponding to the Redis encoding.
  • the first update unit is specifically configured to:
  • Lua script Use the Lua script to atomically operate the Redis cache to calculate whether the inventory of the product corresponding to the request meets the request, if so, modify the inventory quantity in the product information, otherwise return a failure.
  • the second update module includes:
  • the second query unit is used to query whether there is data in the inventory change intermediate table
  • the second judgment unit is configured to judge whether the DB transaction operation is successful, and if it succeeds, submit the DB transaction operation; otherwise, after the rollback, execute the DB transaction operation again according to the data in the inventory change intermediate table;
  • the second update unit is used to start a DB transaction and update the commodity information in the database.
  • the device further includes:
  • the setting module is used to set the gray state of the product, including gray-in, gray-out and switching;
  • the judging module is used to judge the gray state of the commodity corresponding to the request in the request list, and if it is in the switching process, it directly returns to the processing failure.
  • the cache-based sales locking method and device provided in the embodiment of the present invention divide the product information into several parts according to the product code, and store them in the corresponding coded cache library of Redis according to preset rules, avoiding the use of single
  • the Redis cache library stores large amounts of data to improve query efficiency;
  • the caching-based sales locking method and device ensure data consistency by using the atomicity of LUA scripts instead of database transactions, and use the single-threaded feature of Redis to control inventory concurrency;
  • the cache-based sales locking method and device provided by the embodiments of the present invention put complex data structures into the cache (Redis cache library), and then use LUA to perform inventory query calculations and deductions, thereby improving processing efficiency, and Update the database asynchronously through the second-level JOB, and set the second-level JOB to adopt a retry mechanism to ensure that the data in the cache and the database are consistent;
  • the cache-based sales locking method and device provided by the embodiments of the present invention use three states of grayscale, grayscale out, and switching to determine the location of the data, and then perform maintenance, and use the grayscale state to solve the problem of data switching.
  • processing the data causes the problem of inconsistency between the cache and the database data.
  • Fig. 1 is a flow chart showing a method for sales locking based on caching according to an exemplary embodiment
  • Fig. 2 is a flow chart showing that according to the request list, the product information in the cache library corresponding to Redis is updated and recorded in the inventory change intermediate table according to an exemplary embodiment
  • Fig. 3 is a flow chart showing the use of second-level JOB to asynchronously update product information in the database according to an inventory change intermediate table according to an exemplary embodiment
  • Fig. 4 is a schematic structural diagram of a sales locking device based on caching according to an exemplary embodiment.
  • the cache-based sales locking method and device cache the inventory, and use the second-level JOB to change the inventory in the cache library and synchronize with the inventory quantity of the DB (database) in an asynchronous manner. Ensure that the number in the cache library is consistent with the number in the DB.
  • the inventory deduction business is no longer a direct operation of the DB, but only operates on the cache.
  • the inventory is deducted in the cache. After the operation is successful, the user will directly return to the user to purchase successfully.
  • the data in the cache library is synchronized with the data in the DB in an asynchronous manner, which not only improves the processing efficiency, but also solves the bottleneck of the database, and also improves the user's shopping experience.
  • Fig. 1 is a flow chart showing a method for sales locking based on caching according to an exemplary embodiment. Referring to Fig. 1, the method includes the following steps:
  • S1 Divide the product information into several parts according to the product code, and store them in the corresponding coded cache library of Redis according to preset rules.
  • the Redis cache library supports 16 cache libraries by default.
  • the product information is modulated according to the product code (usually the product codes are composed of numbers, because here is the average product code Divide into 16 parts, so you can divide the number (that is, the product code) %16, and the obtained data is 0-15), divide it into 16 parts, and then follow the preset rules (for example, put the product code %16, the result is 0, then put 0 library If it is 1, put 1 library, and so on, if it is 15, put 15 libraries) respectively stored in the Redis cache library coded 0-15.
  • This setting can store data in 16 libraries as much as possible, avoiding the use of a single Redis cache library to store a large amount of data, causing the problem of slow query speed, that is, reducing the pressure of a library and improving query efficiency.
  • setting the Redis cache library to 16 cache libraries is just an example. Users can modify the number of cache libraries supported by Redis by configuring the parameter databases according to specific needs, and divide the product information into Redis. The number of supported cache libraries is the same as the number of copies.
  • S2 Obtain and parse the sales lock request of the commodity to obtain a request list.
  • the sales lock request is first analyzed and processed, and the operation is performed after the request list is successfully analyzed. If the analysis fails, the failure is directly returned.
  • the request includes at least the deduction of product inventory.
  • the peripheral system can add sales lock records by calling the real-time lock interface, modify the inventory quantity of the Redis cache library, record the intermediate table of inventory changes, and then compare the results Return to the peripheral system.
  • updating the product information in the cache library corresponding to Redis includes modifying the inventory quantity of the corresponding product in the Redis cache library.
  • the complex data structure is put into the cache, and then the inventory quantity query calculation and deduction are performed in the cache, so as to reduce the interaction with the database and improve the processing efficiency.
  • the product information (stock quantity, etc.) of the corresponding product in the database is updated according to the modification record of the inventory change intermediate table through the second-level JOB asynchronously.
  • the second-level JOB adopts a retry and manual processing mechanism. If an error occurs during synchronization, it will automatically retry. If it fails after a certain number of times, it will stop synchronizing the current piece of data, and then execute the remaining data. The failed data can be manually operated and maintained to the database, and finally the data in the database (such as the inventory quantity) will be consistent with the data in the Redis cache library.
  • Fig. 2 is a flow chart showing according to an exemplary embodiment the update of the commodity information in the cache library corresponding to the Redis encoding according to the request list, and the recording in the intermediate table of inventory change, as shown in Fig. 2 A preferred implementation manner.
  • the step S3 specifically includes:
  • S3.1 According to the number of the request list, select to start multi-thread processing request or single-thread processing request.
  • a threshold can be preset, and the number of requests is compared with a preset threshold. If the number of requests is greater than the threshold, then multi-threaded processing of requests is enabled. , Otherwise single thread processing request. It should be noted here that the threshold can be set according to the specific needs of the user.
  • step S3.2 Traverse the requests in the request list, verify the content of the request, if the verification is passed, perform step S3.3, otherwise, encapsulate the failed request, and continue to verify the request list The remaining requests.
  • the requests in the request list are processed cyclically. Before processing the request, the content of the request needs to be verified. After the verification is passed, the execution will continue (that is, step S3.3). If the verification fails, the failed The request is encapsulated and continues to check the remaining requests in the request list.
  • step S3.3 Query whether the request is in the sales lock table, if not, after the request is added to the sales lock table, perform step S3.4, otherwise directly perform step S3.4.
  • step S3.4 After the request is successfully verified, query whether the current request is already in the sales lock table, if it exists, continue to the next step (ie, perform step S3.4), otherwise, you need to add the request to the sales lock table first. Then proceed to the next step (ie, step S3.4).
  • Adding a request in the sales lock table can be processed by calling the sales component to add a new request. Invoking the new processing flow of the sales component includes: saving the sales record corresponding to the request in the database and recording the sales record on the inventory change intermediate table.
  • the sales record corresponding to the request it is first recorded on the inventory change intermediate table, and then the corresponding product information in the cache library corresponding to the Redis code is updated.
  • the update of the product information includes the modification of the inventory quantity. Ensure the consistency of the data in the Redis cache library and the database.
  • the updating the commodity information in the cache library corresponding to the Redis encoding specifically includes:
  • Lua script Use the Lua script to atomically operate the Redis cache to calculate whether the inventory of the product corresponding to the request meets the request, if so, modify the inventory quantity in the product information, otherwise return a failure.
  • the atomicity of the LUA script is used instead of the Redis distributed lock to perform inventory concurrency control.
  • Using the LUA script to combine the two operations of selecting the Redis library and operating the Redis library can also ensure the correctness of the selection of the Redis library and the operation of the Redis library in the case of concurrency, that is, to ensure that the Redis library and operating data can be correctly selected every time.
  • Figure 3 is a flow chart showing the use of second-level JOB to asynchronously update product information in the database according to the inventory change intermediate table according to an exemplary embodiment.
  • the present invention is implemented
  • the step S4 specifically includes:
  • the DB transaction includes operations such as modifying the quantity in the corresponding commodity inventory quantity table, saving the flow, saving the commodity status, and saving and issuing the intermediate table.
  • step S4.2 Determine whether the DB transaction operation is successful, if successful, submit the DB transaction operation, otherwise, perform step S4.3 after rollback.
  • step S4.3 This operation can prevent the database surface from completing the update but not completing the update, effectively ensuring that the data in the cache library and the database are consistent.
  • the second-level JOB starts the retry mechanism, and if it is rolled back, the successful data is re-executed until the execution is successful.
  • the second-level JOB also adopts a manual processing mechanism, and presets a threshold for the number of retries. If an error occurs during the synchronization process, it will automatically retry. If the threshold of the number of retries is exceeded, the current data will be stopped, and the remaining data will be executed. The failed data will be maintained to the database through manual processing (manual operation), and finally Keep the inventory quantity table consistent with the data cached by Redis.
  • the method before updating the commodity information in the cache library corresponding to the Redis encoding according to the request list, the method further includes:
  • the grayscale state of the product is set to three states: in-gray, out-of-gray, and in switching, and three states of in-gray, out of gray, and in-switching are used to determine the position of the data and then maintain it.
  • in-gray, out-of-gray, and in switching it is necessary to judge the gray state of the current commodity first. If it is switching, it will directly return to the processing failure. After maintaining the cache inventory, you need to check the gray status of the current data again. If it is switching, it will return to the processing failure, and roll back the data in the cache according to the operation flow to avoid modifying the data during the data switching process, resulting in the cache and the database The problem of inconsistent data.
  • Fig. 4 is a schematic structural diagram of a sales locking device based on caching according to an exemplary embodiment. As described with reference to Fig. 4, the device includes:
  • the division module is used to divide the product information into several parts according to the product code, and store them in the corresponding coded cache library of Redis according to preset rules;
  • the parsing module is used to obtain and analyze the sales lock request of the commodity to obtain the request list;
  • the first update module is configured to record the inventory change intermediate table in the same transaction according to the request list, and then update the commodity information in the cache library corresponding to the Redis encoding;
  • the second update module is used to asynchronously update the commodity information in the database using the second JOB according to the inventory change intermediate table.
  • the first update module includes:
  • the first judging unit is configured to select whether to enable multi-thread processing request or single-thread processing request according to the number of the request list;
  • the checking unit is used to traverse the requests in the request list and check the content of the request
  • the next step is to query whether the request is in the sales lock table, if the verification fails, encapsulate the failed request, and continue to verify the remaining requests in the request list.
  • the first query unit is used to query whether the request is in the sales lock table
  • the sales lock table adds a new request, execute the next step (update the product information in the cache library corresponding to the Redis code, and generate an inventory change intermediate table) Otherwise, proceed directly to the next step (update the commodity information in the cache library corresponding to the Redis code, and generate an intermediate inventory change table).
  • the first update unit is used to record the inventory change intermediate table and update the commodity information in the cache library corresponding to the Redis encoding.
  • the first update unit is specifically configured to:
  • Lua script Use the Lua script to atomically operate the Redis cache to calculate whether the inventory of the product corresponding to the request meets the request, if so, modify the inventory quantity in the product information, otherwise return a failure.
  • the second update module includes:
  • the second query unit is used to query whether there is data in the inventory change intermediate table
  • the second judgment unit is configured to judge whether the DB transaction operation is successful, and if it succeeds, submit the DB transaction operation; otherwise, after the rollback, execute the DB transaction operation again according to the data in the inventory change intermediate table;
  • the second update unit is used to start a DB transaction and update the commodity information in the database.
  • the device further includes:
  • the setting module is used to set the gray state of the product, including gray-in, gray-out and switching;
  • the judging module is used to judge the gray state of the commodity corresponding to the request in the request list, and if it is in the switching process, it directly returns to the processing failure.
  • the cache-based sales locking method and device provided in the embodiment of the present invention divide the product information into several parts according to the product code, and store them in the corresponding coded cache library of Redis according to preset rules, avoiding the use of single
  • the Redis cache library stores large amounts of data to improve query efficiency;
  • the cache-based sales locking method and device ensure data consistency by using the atomicity of LUA scripts instead of database transactions, and use the single-threaded feature of Redis to control inventory concurrency;
  • the cache-based sales locking method and device provided by the embodiments of the present invention put complex data structures into the cache (Redis cache library), and then use LUA to perform inventory query calculations and deductions, thereby improving processing efficiency, and Update the database asynchronously through the second-level JOB, and set the second-level JOB to adopt a retry mechanism to ensure that the data in the cache and the database are consistent;
  • the cache-based sales locking method and device provided by the embodiments of the present invention use three states of grayscale, grayscale out, and switching to determine the location of the data, and then perform maintenance, and use the grayscale state to solve the problem of data switching.
  • processing the data causes the problem of inconsistency between the cache and the database data.
  • the sales locking device based on caching triggers the sales locking service
  • only the division of the above functional modules is used as an example for illustration. In actual applications, the above functional assignments can be divided according to needs.
  • the function module is completed, that is, the internal structure of the device is divided into different function modules to complete all or part of the functions described above.
  • the caching-based sales locking device provided in the above embodiment and the caching-based sales locking method embodiment belong to the same concept, that is, the device is based on the caching-based sales locking method. For the specific implementation process, see Methods The embodiments are not repeated here.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Computational Linguistics (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Software Systems (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Probability & Statistics with Applications (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

一种基于缓存化的销售锁定方法及系统，该方法包括如下步骤：将商品信息按照商品编码取模分成若干份，按照预设规则分别存储于Redis相应编码的缓存库中(S1)；获取并解析商品的销售锁定请求，得到请求列表(S2)；根据请求列表，在同一事务内，记录库存变化中间表，然后对Redis相应编码的缓存库中的商品信息进行更新(S3)；根据库存变化中间表，使用秒级JOB异步更新数据库中的商品信息(S4)。该方法避免使用单一的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所述的基于缓存化的销售锁定系统，其特征在于，所述系统还包括：
    设置模块，用于设置商品的灰度状态包括灰度内、灰度外和切换中；
    判断模块，用于判断所述请求列表中的请求对应的商品的灰度状态，若是在切换中，则直接返回处理失败。
PCT/CN2019/109094 2019-03-28 2019-09-29 一种基于缓存化的销售锁定方法及系统 WO2020192063A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA3176449A CA3176449A1 (en) 2019-03-28 2019-09-29 Sales locking method and system based on a caching

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910247896.6 2019-03-28
CN201910247896.6A CN111752957B (zh) 2019-03-28 2019-03-28 一种基于缓存化的销售锁定方法及系统

Publications (1)

Publication Number Publication Date
WO2020192063A1 true WO2020192063A1 (zh) 2020-10-01

Family

ID=72608730

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/109094 WO2020192063A1 (zh) 2019-03-28 2019-09-29 一种基于缓存化的销售锁定方法及系统

Country Status (3)

Country Link
CN (1) CN111752957B (zh)
CA (1) CA3176449A1 (zh)
WO (1) WO2020192063A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112380026A (zh) * 2021-01-13 2021-02-19 常州微亿智造科技有限公司 任务处理方法、装置和存储介质
CN113807760A (zh) * 2021-01-07 2021-12-17 北京沃东天骏信息技术有限公司 库存信息处理方法、装置及可读存储介质和电子设备
CN113868100A (zh) * 2021-10-27 2021-12-31 北京值得买科技股份有限公司 一种电商领域数据的自动化调度采集系统
CN114331576A (zh) * 2021-12-30 2022-04-12 福建博思软件股份有限公司 基于高并发场景下的电子票号快速取票方法及存储介质
CN116167699A (zh) * 2023-01-16 2023-05-26 广州辰创科技发展有限公司 一种装备保障资源管理方法及系统

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112667600A (zh) * 2020-12-28 2021-04-16 紫光云技术有限公司 一种redis与MySQL结合的库存解决方法
CN112749199A (zh) * 2021-01-25 2021-05-04 上海伯俊软件科技有限公司 一种库存管理方法
CN112765277A (zh) * 2021-01-28 2021-05-07 树根互联股份有限公司 数据同步方法、装置和系统
CN112860746B (zh) * 2021-02-01 2023-04-07 上海万物新生环保科技集团有限公司 一种基于缓存削减的方法、设备及系统
CN113868278B (zh) * 2021-09-29 2023-08-01 北京有竹居网络技术有限公司 一种数据处理方法、装置及设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120017037A1 (en) * 2010-04-12 2012-01-19 Riddle Thomas A Cluster of processing nodes with distributed global flash memory using commodity server technology
CN105468690A (zh) * 2015-11-17 2016-04-06 中国建设银行股份有限公司 一种库存数据处理方法和装置
CN106170016A (zh) * 2016-07-28 2016-11-30 深圳市创梦天地科技有限公司 一种处理高并发数据请求的方法和系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107220878A (zh) * 2017-05-26 2017-09-29 努比亚技术有限公司 业务处理系统、秒杀订单处理方法和设备
CN108897615B (zh) * 2018-05-31 2023-06-13 康键信息技术（深圳）有限公司 秒杀请求处理方法、应用服务器集群及存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120017037A1 (en) * 2010-04-12 2012-01-19 Riddle Thomas A Cluster of processing nodes with distributed global flash memory using commodity server technology
CN105468690A (zh) * 2015-11-17 2016-04-06 中国建设银行股份有限公司 一种库存数据处理方法和装置
CN106170016A (zh) * 2016-07-28 2016-11-30 深圳市创梦天地科技有限公司 一种处理高并发数据请求的方法和系统

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113807760A (zh) * 2021-01-07 2021-12-17 北京沃东天骏信息技术有限公司 库存信息处理方法、装置及可读存储介质和电子设备
CN112380026A (zh) * 2021-01-13 2021-02-19 常州微亿智造科技有限公司 任务处理方法、装置和存储介质
CN113868100A (zh) * 2021-10-27 2021-12-31 北京值得买科技股份有限公司 一种电商领域数据的自动化调度采集系统
CN114331576A (zh) * 2021-12-30 2022-04-12 福建博思软件股份有限公司 基于高并发场景下的电子票号快速取票方法及存储介质
CN116167699A (zh) * 2023-01-16 2023-05-26 广州辰创科技发展有限公司 一种装备保障资源管理方法及系统
CN116167699B (zh) * 2023-01-16 2023-11-14 广州辰创科技发展有限公司 一种装备保障资源管理方法及系统

Also Published As

Publication number Publication date
CN111752957B (zh) 2022-11-11
CN111752957A (zh) 2020-10-09
CA3176449A1 (en) 2020-10-01

Similar Documents

Publication Publication Date Title
WO2020192063A1 (zh) 一种基于缓存化的销售锁定方法及系统
US10503720B2 (en) Providing eventual consistency for multi-shard transactions
US10970306B2 (en) Change management system for data synchronization within an enterprise portal application
US8156137B2 (en) Data processing systems and methods
US10678808B2 (en) Eager replication of uncommitted transactions
EP2600246B1 (en) Batch processing of business objects
US5151987A (en) Recovery objects in an object oriented computing environment
US10942823B2 (en) Transaction processing system, recovery subsystem and method for operating a recovery subsystem
WO2016180164A1 (zh) 一种分布式事务回滚方法及装置
US8276153B2 (en) Method and system for dividing and executing on-line transaction processing in distributed environment
US20090019094A1 (en) Redirected updates on a backup server
US20090222822A1 (en) Nested Queued Transaction Manager
CN105096065A (zh) 一种库存扣减方法和装置
EP3396560B1 (en) Database operating method and device
CN101350022B (zh) 基于数据库逻辑锁的变更处理方法
TW201721471A (zh) 資料庫操作方法及裝置
US10997158B2 (en) Techniques for updating big data tables using snapshot isolation
CN113157411B (zh) 一种基于Celery的可靠可配置任务系统及装置
CN112559496A (zh) 一种分布式数据库事务原子性实现方法及装置
US11334568B2 (en) Deep caching in the data access layer of an enterprise portal application
US20060294006A1 (en) Business transaction process controller for composite transactions
US20080034348A1 (en) Method and System for Bulk-Loading Data Into A Data Storage Model
CN112749156A (zh) 数据处理方法、数据库管理系统和数据处理设备
TWI805544B (zh) 資料庫操作方法及裝置
Alonso Database replication for enterprise applications

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19921500

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19921500

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 22/04/2022)

ENP Entry into the national phase

Ref document number: 3176449

Country of ref document: CA

122 Ep: pct application non-entry in european phase

Ref document number: 19921500

Country of ref document: EP

Kind code of ref document: A1