CA3176449A1 - Sales locking method and system based on a caching - Google Patents
Sales locking method and system based on a cachingInfo
- Publication number
- CA3176449A1 CA3176449A1 CA3176449A CA3176449A CA3176449A1 CA 3176449 A1 CA3176449 A1 CA 3176449A1 CA 3176449 A CA3176449 A CA 3176449A CA 3176449 A CA3176449 A CA 3176449A CA 3176449 A1 CA3176449 A1 CA 3176449A1
- Authority
- CA
- Canada
- Prior art keywords
- request
- sales
- redis
- cache
- updating
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 51
- 238000012545 processing Methods 0.000 claims abstract description 55
- 230000008859 change Effects 0.000 claims abstract description 47
- 238000013515 script Methods 0.000 claims abstract description 12
- 238000012795 verification Methods 0.000 claims description 13
- 238000004806 packaging method and process Methods 0.000 claims description 3
- 230000008569 process Effects 0.000 description 14
- 108010052919 Hydroxyethylthiazole kinase Proteins 0.000 description 5
- 108010027436 Hydroxymethylpyrimidine kinase Proteins 0.000 description 5
- 229920006465 Styrenic thermoplastic elastomer Polymers 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 229920006348 thermoplastic styrenic block copolymer Polymers 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 4
- 230000001737 promoting effect Effects 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 230000002093 peripheral effect Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- MKZGVLPHKXXSSG-UHFFFAOYSA-N ethyl n-[4-[benzyl(2-phenylethyl)amino]-2-[4-(trifluoromethyl)phenyl]-1h-imidazo[4,5-c]pyridin-6-yl]carbamate Chemical compound N=1C(NC(=O)OCC)=CC=2NC(C=3C=CC(=CC=3)C(F)(F)F)=NC=2C=1N(CC=1C=CC=CC=1)CCC1=CC=CC=C1 MKZGVLPHKXXSSG-UHFFFAOYSA-N 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
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
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)
- Computational Linguistics (AREA)
- Economics (AREA)
- Quality & Reliability (AREA)
- Marketing (AREA)
- Probability & Statistics with Applications (AREA)
- General Business, Economics & Management (AREA)
- Tourism & Hospitality (AREA)
- Development Economics (AREA)
- Mathematical Physics (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Software Systems (AREA)
- Operations Research (AREA)
- Fuzzy Systems (AREA)
- Strategic Management (AREA)
- Finance (AREA)
- Accounting & Taxation (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
A caching-based method and system for sales locking. The method comprises the following steps: modulusly dividing merchandise information into several portions according to merchandise codes, respectively storing in a cache database of Redis-corresponding codes according to a preset rule (S1); acquiring and parsing a sales locking request for a merchandise to produce a request list (S2); recording an inventory change intermediate table in a same transaction on the basis of the request list, then updating merchandise information in the cache database of the Redis-corresponding codes (S3); and asynchronously updating merchandise information in a database using a second-level JOB on the basis of the inventory change intermediate table (S4). The method prevents the use of a single Redis cache database to store a large volume of data, increases the efficiency of queries, uses the atomicity of a LUA script in place of a data transaction to ensure the consistency of data, utilizes the characteristic of a Redis single thread for inventory concurrency control, and utilizes a grayscale state to solve the problem of data inconsistency between a cache and a database due to data processing when a request arrives while data is being divided into the cache.
Description
SALES LOCKING METHOD AND SYSTEM BASED ON CACHING
BACKGROUND OF THE INVENTION
Technical Field [0001] The present invention relates to the field of computer software technology, and more particularly to a sales locking method based on caching, and a corresponding system.
Description of Related Art
BACKGROUND OF THE INVENTION
Technical Field [0001] The present invention relates to the field of computer software technology, and more particularly to a sales locking method based on caching, and a corresponding system.
Description of Related Art
[0002] With the development of the internet, traditional stores are gradually being replaced with online shopping platforms. While more and more users choose online shopping, in order to attract users, online shopping platforms stage variegated sales promotional activities, such as "seckill", rush-purchase, and shopping-together, etc. High concurrency is instantaneously generated by such sales promotional activities, and a very high demand is put on the processing efficiency of the entire transaction link, in which maintenance of the stock quantity is a core segment, and highly efficient processing is also of great importance.
[0003] In the currently available stock deducting methods, sales locking (temporary lock +
formal lock) and delivery locking (logistic delivery) are employed to maintain stock quantities based on the scheme of database + application lock technology, and processing of businesses is embodied as the serial processing mode, whereby processing efficiency is so extremely low that current business scenarios cannot be satisfied.
Particularly under the rush-purchase scenario, sales locking requests of the same and single commodity appear highly concurrently, when the same commodity is concurrently requested, the request that obtains the lock first is firstly executed, and the following requests are sequentially executed only after having waited for the processing result to have been Date Regue/Date Received 2022-09-22 returned from the stock management system. Interaction with the database is carried out for several times during the entire process, a great deal of network time delay is consumed;
moreover, the TPS processing capability of DB (database) is also limited, with the increase in quantity of data stored in DB (database), the TPS processing capability also gradually lowers, so that the processing time of the database is also prolonged. The purchasing interface of the user would be always in the waiting status, and this greatly lowers the online shopping experience of the customer.
formal lock) and delivery locking (logistic delivery) are employed to maintain stock quantities based on the scheme of database + application lock technology, and processing of businesses is embodied as the serial processing mode, whereby processing efficiency is so extremely low that current business scenarios cannot be satisfied.
Particularly under the rush-purchase scenario, sales locking requests of the same and single commodity appear highly concurrently, when the same commodity is concurrently requested, the request that obtains the lock first is firstly executed, and the following requests are sequentially executed only after having waited for the processing result to have been Date Regue/Date Received 2022-09-22 returned from the stock management system. Interaction with the database is carried out for several times during the entire process, a great deal of network time delay is consumed;
moreover, the TPS processing capability of DB (database) is also limited, with the increase in quantity of data stored in DB (database), the TPS processing capability also gradually lowers, so that the processing time of the database is also prolonged. The purchasing interface of the user would be always in the waiting status, and this greatly lowers the online shopping experience of the customer.
[0004] In summary, the currently available stock deducting methods are problematic as specified below:
[0005] 1. The use of serial processing mode achieves low processing efficiency in the case of high concurrency;
[0006] 2. The same commodities are stored in a single database, while the sales locking TPS for the single DB to process the same commodities usually does not exceed 200, so a high demand is put on the performance of the database server. Moreover, several tens of DBs can only support over one thousand TPSs, the performance falls far short of satisfying such promotional businesses as seckill and rush-phase of hotspot commodities, whereby user experiences are rendered not good.
SUMMARY OF THE INVENTION
SUMMARY OF THE INVENTION
[0007] In order to solve problems pending in the state of the art, embodiments of the present invention provide a sales locking method based on caching, and a corresponding system, so as to address such prior-art problems in which the DB performance is bottlenecked during high concurrency processing in sales locking, the TPS processing capability is low during sales promotion and system stock is simple in structure, business requirements cannot be satisfied, and activities should be maintained in advance, and so on.
[0008] In order to address one or more of the above technical problem(s), the present invention Date Regue/Date Received 2022-09-22 employs the following technical solutions.
[0009] According to the first aspect, there is provided a sales locking method based on caching, and the method comprises:
[0010] Si ¨modulo dividing commodity information into plural pieces according to commodity codes, and respectively storing the same information in cache libraries correspondingly coded by Redis according to a preset rule;
[0011] S2¨ obtaining and parsing a sales locking request of the commodities, and obtaining a request list;
[0012] S3 ¨ recording an inventory change intermediate sheet within the same business according to the request list, and thereafter updating the commodity information in the cache libraries correspondingly coded by Redis; and
[0013] S4¨ employing second-grade JOB to asynchronously update the commodity information in a database according to the inventory change intermediate sheet.
[0014] Further, step S3 specifically includes:
[0015] S3.1 ¨ choosing to start a multi-threads processing request or a single thread processing request according to number of piece(s) in the request list;
[0016] S3.2¨ traversing requests in the request list, verifying contents of the requests, executing step S3.3 if verification is passed, otherwise packaging any request not passing the verification, and continuously verifying remaining requests in the request list;
[0017] S3.3¨ enquiring whether a given request is in a sales locking sheet, if not, executing step S3.4 after having newly added the request to the sales locking sheet, otherwise directly executing step S3.4; and
[0018] S3.4 ¨ recording the inventory change intermediate sheet, and updating the commodity information in the cache libraries correspondingly coded by Redis.
[0019] Further, the step of updating the commodity information in the cache libraries correspondingly coded by Redis specifically includes:
Date Regue/Date Received 2022-09-22
Date Regue/Date Received 2022-09-22
[0020] employing a Lua script to atomically manipulate a Redis cache, calculating whether a stock of commodities to which the request corresponds satisfies the request, if yes, modifying a stock quantity in the commodity information, otherwise returning failure.
[0021] Further, step S4 specifically includes:
[0022] S4.1 ¨ enquiring whether there is data in the inventory change intermediate sheet, if yes, starting a DB business, and updating the commodity information in the database, otherwise performing no processing;
[0023] S4.2 ¨ judging whether the DB business operation is successful, if yes, submitting the DB business operation, otherwise executing step S4.3 after rollback; and
[0024] S4.3 ¨ executing the DB business operation anew according to the data of the inventory change intermediate sheet until execution succeeds.
[0025] Further, prior to the step of updating the commodity information in the cache libraries correspondingly coded by Redis according to the request list, the method further comprises:
[0026] setting grayscale statuses of commodities as in grayscale, out of grayscale, and in switching; and
[0027] judging the grayscale status of commodities to which a given request in the request list corresponds, and directly returning processing failure in the case that the grayscale status is in switching.
[0028] According to another aspect, there is provided a sales locking system based on caching, and the system comprises:
[0029] a dividing module, for modulo dividing commodity information into plural pieces according to commodity codes, and respectively storing the same information in cache libraries correspondingly coded by Redis according to a preset rule;
[0030] a parsing module, for obtaining and parsing a sales locking request of the commodities, and obtaining a request list;
Date Regue/Date Received 2022-09-22
Date Regue/Date Received 2022-09-22
[0031] a first updating module, for recording an inventory change intermediate sheet within the same business according to the request list, and thereafter updating the commodity information in the cache libraries correspondingly coded by Redis; and
[0032] a second updating module, for employing second-grade JOB to asynchronously update the commodity information in a database according to the inventory change intermediate sheet.
[0033] Further, the first updating module includes:
[0034] a first judging unit, for choosing to start a multi-threads processing request or a single thread processing request according to number of piece(s) in the request list;
[0035] a verifying unit, for traversing requests in the request list, and verifying contents of the requests;
[0036] a first enquiring unit, for enquiring whether a given request is in a sales locking sheet;
and
and
[0037] a first updating unit, for recording the inventory change intermediate sheet, and updating the commodity information in the cache libraries correspondingly coded by Redis.
[0038] Further, the first updating unit is specifically employed for:
[0039] employing a Lua script to atomically manipulate a Redis cache, calculating whether a stock of commodities to which the request corresponds satisfies the request, if yes, modifying a stock quantity in the commodity information, otherwise returning failure.
[0040] Further, the second updating module includes:
[0041] a second enquiring unit, for enquiring whether there is data in the inventory change intermediate sheet;
[0042] a second judging unit, for judging whether a DB business operation is successful, if yes, submitting the DB business operation, otherwise executing the DB business operation anew according to data of the inventory change intermediate sheet after rollback; and
[0043] a second updating unit, for starting a DB business, and updating the commodity Date Regue/Date Received 2022-09-22 information in the database.
[0044] Moreover, the system further comprises:
[0045] a setting module, for setting grayscale statuses of commodities as in grayscale, out of grayscale, and in switching; and
[0046] a judging module, for judging the grayscale status of commodities to which a given request in the request list corresponds, and directly returning processing failure in the case that the grayscale status is in switching.
[0047] The technical solutions provided by the embodiments of the present invention bring about the following advantageous effects.
[0048] The sales locking method and device based on caching provided by the embodiments of the present invention modulo divide commodity information into plural pieces according to commodity codes, and respectively store the same information in cache libraries correspondingly coded by Redis according to a preset rule, whereby is avoided the use of a single Redis cache library to store great quantities of data, and enquiring efficiency is enhanced.
[0049] In the sales locking method and device based on caching provided by the embodiments of the present invention, consistency of data is ensured by employing the atomicity of LUA scripts in replace of database businesses, and single-thread characteristics of Redis are made use of to perform concurrent control of the stock.
[0050] In the sales locking method and device based on caching provided by the embodiments of the present invention, processing efficiency is enhanced by placing the complicated data structure in cache (Redis cache libraries), and then employing LUA to perform enquiring calculation and deduction of stock quantity; moreover, the database is asynchronously updated through second-grade JOB, and the second-grade JOB is set and Date Regue/Date Received 2022-09-22 a retry mechanism is employed to finally ensure consistency between the cache and data in the database.
[0051] In the sales locking method and device based on caching provided by the embodiments of the present invention, three statuses as in grayscale, out of grayscale, and in switching are used to judge the location of data and to thereafter maintain the data, and grayscale statuses are employed to solve the problem concerning inconsistency between cache and database data caused by the processing of data when there is an incoming request during the process in which the data is switched to the cache.
BRIEF DESCRIPTION OF THE DRAWINGS
BRIEF DESCRIPTION OF THE DRAWINGS
[0052] To describe the technical solutions in the embodiments of the present invention more clearly, drawings required to be used in the description of the embodiments will be briefly introduced below. Apparently, the drawings introduced below are merely directed to some embodiments of the present invention, while it is possible for persons ordinarily skilled in the art to acquire other drawings based on these drawings without spending any creative effort in the process.
[0053] Fig. 1 is a flowchart illustrating the sales locking method based on caching according to an exemplary embodiment;
[0054] Fig. 2 is a flowchart illustrating updating commodity information in the cache libraries correspondingly coded by Redis and recording the same information in the inventory change intermediate sheet according to the request list in an exemplary embodiment;
[0055] Fig. 3 is a flowchart illustrating employing second-grade JOB to asynchronously update commodity information in the database according to the inventory change intermediate sheet according to an exemplary embodiment; and Date Regue/Date Received 2022-09-22
[0056] Fig. 4 is a view schematically illustrating the structure of the sales locking device based on caching according to an exemplary embodiment.
DETAILED DESCRIPTION OF THE INVENTION
DETAILED DESCRIPTION OF THE INVENTION
[0057] To make more lucid and clear the objectives, technical solutions and advantages of the present invention, the technical solutions in the embodiments of the present invention will be clearly and comprehensively described below with reference to the drawings in the embodiments of the present invention. Apparently, the embodiments as described are merely partial, rather than the entire, embodiments of the present invention.
All other embodiments obtainable by persons ordinarily skilled in the art on the basis of the embodiments in the present invention and without spending any creative effort shall all be covered by the protection scope of the present invention.
All other embodiments obtainable by persons ordinarily skilled in the art on the basis of the embodiments in the present invention and without spending any creative effort shall all be covered by the protection scope of the present invention.
[0058] In the sales locking method and device based on caching provided by the embodiments of the present invention, the stock is cached, and stock change in the cache libraries are synchronized with stock quantity in the DB (database) in an asynchronizing mode through the second-grade JOB, thus ensuring that the quantity in the cache libraries and the quantity in the DB are maintained consistent. When such a sales promotional activity as seckill or rush-purchase is carried out, the business of deducting stock is no longer a direct operation on the DB, but only an operation on the cache by deducting the stock in the cache, and a successful purchase is directly returned to the user if the operation succeeds. Data in the cache libraries is thereafter synchronized with data in the DB in an asynchronous mode, whereby processing efficiency is not only enhanced, but bottleneck of the database is also excellently dealt with, and purchasing experiences of users are enhanced at the same time.
[0059] Fig. 1 is a flowchart illustrating the sales locking method based on caching according to Date Regue/Date Received 2022-09-22 an exemplary embodiment. With reference to what is shown in Fig. 1, the method comprises the following steps.
[0060] Si ¨modulo dividing commodity information into plural pieces according to commodity codes, and respectively storing the same information in cache libraries correspondingly coded by Redis according to a preset rule.
[0061] Specifically, a Redis cache library supports sixteen cache libraries by default, as an example, in the embodiments of the present invention, the commodity information is modulo (commodity codes usually consist of numerals, because the commodity codes are equally divided into sixteen pieces here, it is possible to multiply the numerals (namely the commodity codes) with %16, and the resultant data are precisely 0-15) divided into sixteen pieces according to commodity codes, and these are then respectively stored in Redis cache libraries coded 0-15 according to a preset rule (for instance, the commodity codes are multiplied with %16, whose result is 0 it is placed in library 0, whose result is 1 it is placed in library 1, so on and so forth, whose result is 15 it is placed in library 15).
Such setting makes it possible that the data are stored in the sixteen libraries as far as practically possible, and it is avoided to use a single Redis cache library to store great quantities of data to thereby render it problematic that the enquiring speed is low, that is to say, the pressure on the single library is reduced, and the enquiring efficiency is enhanced. As should be noted here, the Redis cache library being set as sixteen cache libraries is merely by way of example, as it is possible for the user to modify the number of cache libraries supported by Redis through configuration parameters databases according to specific requirements, and to divide the commodity information into pieces identical with the number of cache libraries supported by Redis.
Such setting makes it possible that the data are stored in the sixteen libraries as far as practically possible, and it is avoided to use a single Redis cache library to store great quantities of data to thereby render it problematic that the enquiring speed is low, that is to say, the pressure on the single library is reduced, and the enquiring efficiency is enhanced. As should be noted here, the Redis cache library being set as sixteen cache libraries is merely by way of example, as it is possible for the user to modify the number of cache libraries supported by Redis through configuration parameters databases according to specific requirements, and to divide the commodity information into pieces identical with the number of cache libraries supported by Redis.
[0062] S2 ¨ obtaining and parsing a sales locking request of the commodities, and obtaining a request list.
Date Regue/Date Received 2022-09-22
Date Regue/Date Received 2022-09-22
[0063] Specifically, after the sales locking request of commodities has been obtained from a peripheral system (an e-commerce sales platform here), the sales locking request is firstly processed by being parsed, and operation is performed after a request list has been obtained by successful parsing, if parsing fails, failure is directly returned. The request at least includes the sales phase such as deduction of the stock of the commodities, the peripheral system can newly add sales locking records, modify stock quantity of the Redis cache libraries, and record the inventory change intermediate table by invoking a real-time locking interface, and the result is thereafter returned to the peripheral system.
[0064] S3 ¨ recording an inventory change intermediate sheet within the same business according to the request list, and thereafter updating the commodity information in the cache libraries correspondingly coded by Redis.
[0065] Specifically, updating the commodity information in the cache libraries correspondingly coded by Redis includes to modify stock quantity of corresponding commodities in the Redis cache libraries. In the embodiments of the present invention, the complicated data structure is placed in cache, enquiring calculation and deduction are then performed on the stock quantity in the cache, whereby interaction with the database is reduced, and processing efficiency is enhanced. As should be noted here, the placements of DB
operation (namely to record the inventory change intermediate sheet) and cache operation in the business of DB, and the preferential processing of the DB operation and the subsequent processing of the cache at least achieve the following advantages:
(1) direct rollback is made in the case DB operation fails, while the cache is not operated; (2) in the case DB operation succeeds and cache fails, DB will also be rolled back; (3) in the case DB operation and cache operation both succeed, the operation can be counted as successful, and the problem is avoided in which it is difficult to roll back cache in the case DB operation fails. If change occurs to this sequence (i.e., cache is preferentially processed, and DB operation is subsequently processed), there will be the circumstance in which cache operation succeeds but DB operation fails, DB can be normally rolled Date Regue/Date Received 2022-09-22 back, but Redis has already been successfully operated, then artificial rollback is required, but rollback of Redis is rather complicated, and tends to cause the probability of error.
operation (namely to record the inventory change intermediate sheet) and cache operation in the business of DB, and the preferential processing of the DB operation and the subsequent processing of the cache at least achieve the following advantages:
(1) direct rollback is made in the case DB operation fails, while the cache is not operated; (2) in the case DB operation succeeds and cache fails, DB will also be rolled back; (3) in the case DB operation and cache operation both succeed, the operation can be counted as successful, and the problem is avoided in which it is difficult to roll back cache in the case DB operation fails. If change occurs to this sequence (i.e., cache is preferentially processed, and DB operation is subsequently processed), there will be the circumstance in which cache operation succeeds but DB operation fails, DB can be normally rolled Date Regue/Date Received 2022-09-22 back, but Redis has already been successfully operated, then artificial rollback is required, but rollback of Redis is rather complicated, and tends to cause the probability of error.
[0066] S4 ¨ employing second-grade JOB to asynchronously update the commodity information in a database according to the inventory change intermediate sheet.
[0067] Specifically, commodity information (stock quantity, etc.) of corresponding commodities in the database is updated through the second-grade JOB asynchronously according to modification records in the inventory change intermediate sheet. In the embodiments of the present invention, the second-grade JOB employs the retry and manually processing mechanisms, should error occur in the synchronizing process, automatic retry will be made, should it still fail after a certain number of retries, the process will stop synchronizing the current piece of data, and the remaining data is subsequently executed;
data failed to be processed can be manually maintained to the database, and data (such as stock quantity) in the database is finally made consistent with data of the Redis cache libraries.
data failed to be processed can be manually maintained to the database, and data (such as stock quantity) in the database is finally made consistent with data of the Redis cache libraries.
[0068] Fig. 2 is a flowchart illustrating updating commodity information in the cache libraries correspondingly coded by Redis and recording the same information in the inventory change intermediate sheet according to the request list in an exemplary embodiment, with reference to what is shown in Fig. 2, as a preferred mode of execution in the embodiments of the present invention, step S3 specifically includes the following.
[0069] S3.1 ¨ choosing to start a multi-threads processing request or a single thread processing request according to number of piece(s) in the request list.
[0070] Specifically, the number of piece(s) of request(s) in the request list is enquired to judge whether to start multi-threads processing, if the number of piece(s) of request(s) satisfies the condition of multi-threads processing, a multi-threads processing request is started, Date Regue/Date Received 2022-09-22 otherwise a single thread processing request is started. As a preferred mode of execution in the embodiments of the present invention, a threshold can be set in advance, and the number of piece(s) of request(s) is compared with the preset threshold, if the number of piece(s) of request(s) is greater than the threshold, the multi-threads processing request is started, otherwise the single thread processing request is started. As should be noted here, the threshold can be set according to practical requirements of the user.
[0071] S3.2 ¨ traversing requests in the request list, verifying contents of the requests, executing step S3.3 if verification is passed, otherwise packaging any request not passing the verification, and continuously verifying remaining requests in the request list.
[0072] Specifically, requests in the request list are cyclically processed, before any request is processed, the content of the request should be verified, execution is continued (namely executing step S3.3) if verification is passed, if verification is not passed, the request not passing the verification is packaged, and remaining requests in the request list are continuously verified.
[0073] S3.3¨ enquiring whether a given request is in a sales locking sheet, if not, executing step S3.4 after having newly added the request to the sales locking sheet, otherwise directly executing step S3.4.
[0074] Specifically, after verification of the request has succeeded, it is enquired whether the current request is already in the sales locking sheet, if yes, the next step is continuously executed (namely executing step S3.4), otherwise it is required to firstly newly add the request to the sales locking sheet, and thereafter to continuously execute the next step (namely executing step S3.4). Newly adding the request to the sales locking sheet can be carried out by invoking a sales component newly adding process. The procedure of invoking a sales component newly adding process includes: storing sales record to which this request corresponds in the database, and recording the sales record in the inventory Date Regue/Date Received 2022-09-22 change intermediate sheet.
[0075] S3.4 ¨ recording the inventory change intermediate sheet, and updating the commodity information in the cache libraries correspondingly coded by Redis.
[0076] Specifically, the sales record to which the request corresponds is firstly recorded in the inventory change intermediate sheet according to the sales record to which the request corresponds, and the corresponding commodity information in the cache libraries correspondingly coded by Redis is then updated, updating of the commodity information includes modifying the stock quantity, etc. Consistency of data in the Redis cache libraries and in the database is ensured.
[0077] As a preferred mode of execution in the embodiments of the present invention, the step of updating the commodity information in the cache libraries correspondingly coded by Redis specifically includes:
[0078] employing a Lua script to atomically manipulate a Redis cache, calculating whether a stock of commodities to which the request corresponds satisfies the request, if yes, modifying a stock quantity in the commodity information, otherwise returning failure.
[0079] Specifically, in the embodiments of the present invention, atomicity of the LUA script is employed in place of the Redis distributed lock to perform stock concurrent control. The complicated data structure (such data as the commodity sales record) is placed in cache, the LUA script is then employed to perform enquiring calculation on the stock quantity (to calculate whether a stock of commodities to which the request corresponds satisfies the request), if yes, the following requests are continuously processed after the stock quantity in the commodity information has been modified, otherwise failure is returned.
The LUA script is used to merge together the two operations of selecting the Redis library and operating the Redis library, and it is further possible to ensure the correctness of selecting the Redis library and operating the Redis library under the concurrent Date Regue/Date Received 2022-09-22 circumstance, that is to say, it is ensured that the Redis library can be correctly selected and the data can be correctly operated each time.
The LUA script is used to merge together the two operations of selecting the Redis library and operating the Redis library, and it is further possible to ensure the correctness of selecting the Redis library and operating the Redis library under the concurrent Date Regue/Date Received 2022-09-22 circumstance, that is to say, it is ensured that the Redis library can be correctly selected and the data can be correctly operated each time.
[0080] Fig. 3 is a flowchart illustrating employing second-grade JOB to asynchronously update commodity information in the database according to the inventory change intermediate sheet according to an exemplary embodiment, with reference to what is shown in Fig. 3, as a preferred mode of execution in the embodiments of the present invention, step S4 specifically includes the following.
[0081] S4.1 ¨ enquiring whether there is data in the inventory change intermediate sheet, if yes, starting a DB business, and updating the commodity information in the database, otherwise performing no processing.
[0082] Specifically, it is firstly enquired whether there is data in the inventory change intermediate sheet, if yes, this indicates that the commodity information in the cache libraries correspondingly coded by Redis has been updated, the DB business is started at this time, and the commodity information in the database is updated according to the inventory change intermediate sheet; if not, this indicates that the commodity information in the cache libraries correspondingly coded by Redis has not been updated, no processing is performed at this time, and the process is directly terminated. The DB
business includes such operations as modifying quantity in a corresponding commodity stock quantity sheet, storing flow, storing commodity status, and storing and dispatching the intermediate sheet, etc.
business includes such operations as modifying quantity in a corresponding commodity stock quantity sheet, storing flow, storing commodity status, and storing and dispatching the intermediate sheet, etc.
[0083] S4.2 ¨ judging whether the DB business operation is successful, if yes, submitting the DB business operation, otherwise executing step S4.3 after rollback.
[0084] Specifically, after the DB business operation has been completed, it is further required to judge whether the DB business operation this time is successful, if yes, the DB business Date Regue/Date Received 2022-09-22 operation is submitted, otherwise the next step is executed (namely executing step S4.3) after rollback. Such operation can prevent the database from being superficially updated but actually not updated, thus effectively ensuring consistency of data in the cache libraries and in the database.
[0085] S4.3 ¨ executing the DB business operation anew according to the data of the inventory change intermediate sheet until execution succeeds.
[0086] Specifically, in the embodiments of the present invention, the second-grade JOB starts the retry mechanism, in the case of rollback, data is executed again until execution succeeds. As should be noted here, in the embodiments of the present invention, the second-grade JOB further employs the manually processing mechanism, and a threshold of number of retries is set in advance. If error occurs in the synchronizing process, retry will be automatically carried out, once the threshold of number of retries is exceeded, the process stops synchronizing the current piece of data, and continues to execute the remaining data, the data failed to be processed is maintained to the database through manual processing (human operation), and the data in the stock quantity sheet and the data of the Redis cache are maintained consistent.
[0087] As a preferred mode of execution in the embodiments of the present invention, prior to the step of updating the commodity information in the cache libraries correspondingly coded by Redis according to the request list, the method further comprises:
[0088] setting grayscale statuses of commodities as in grayscale, out of grayscale, and in switching; and
[0089] judging the grayscale status of commodities to which a given request in the request list corresponds, and directly returning processing failure in the case that the grayscale status is in switching.
[0090] Specifically, the grayscale status of the commodities is set as three statuses of in grayscale, Date Regue/Date Received 2022-09-22 out of grayscale, and in switching, the location of the data is judged by means of the three statuses of in grayscale, out of grayscale, and in switching, and the data is thereafter maintained. When there is data requested to be maintained, it is required to firstly judge the grayscale status of the current commodity, if the grayscale status is in switching, processing failure is directly returned. After the cache stock quantity has been maintained, it is required to check the grayscale status of the current data again, if the grayscale status is in switching, processing failure is returned, and data in the cache is rolled back according to the procedural flow to avoid modifying data in the data switching process to cause the problem of inconsistency between data of the cache and data of the database.
[0091] Fig. 4 is a view schematically illustrating the structure of the sales locking device based on caching according to an exemplary embodiment, with reference to Fig. 4, the device comprises:
[0092] a dividing module, for modulo dividing commodity information into plural pieces according to commodity codes, and respectively storing the same information in cache libraries correspondingly coded by Redis according to a preset rule;
[0093] a parsing module, for obtaining and parsing a sales locking request of the commodities, and obtaining a request list;
[0094] a first updating module, for recording an inventory change intermediate sheet within the same business according to the request list, and thereafter updating the commodity information in the cache libraries correspondingly coded by Redis; and
[0095] a second updating module, for employing second-grade JOB to asynchronously update the commodity information in a database according to the inventory change intermediate sheet.
[0096] As a preferred mode of execution in the embodiments of the present invention, the first updating module includes:
[0097] a first judging unit, for choosing to start a multi-threads processing request or a single thread processing request according to number of piece(s) in the request list;
Date Regue/Date Received 2022-09-22
Date Regue/Date Received 2022-09-22
[0098] a verifying unit, for traversing requests in the request list, and verifying contents of the requests;
[0099] specifically, the next step is executed if verification is passed, namely to enquire whether the request is in the sales locking sheet; if verification is not passed, the request not passing the verification is packaged, and the remaining requests in the request list are continuously verified;
[0100] a first enquiring unit, for enquiring whether a given request is in a sales locking sheet;
[0101] specifically, if the request is not in the sales locking sheet, the next step is executed (updating the commodity information in the cache libraries correspondingly coded by Redis, and generating an inventory change intermediate sheet) after the request has been newly added to the sales locking sheet, otherwise the next step is directly executed (updating the commodity information in the cache libraries correspondingly coded by Redis, and generating an inventory change intermediate sheet);
[0102] a first updating unit, for recording the inventory change intermediate sheet, and updating the commodity information in the cache libraries correspondingly coded by Redis.
[0103] As a preferred mode of execution in the embodiments of the present invention, the first updating unit is specifically employed for:
[0104] employing a Lua script to atomically manipulate a Redis cache, calculating whether a stock of commodities to which the request corresponds satisfies the request, if yes, modifying a stock quantity in the commodity information, otherwise returning failure.
[0105] As a preferred mode of execution in the embodiments of the present invention, the second updating module includes:
[0106] a second enquiring unit, for enquiring whether there is data in the inventory change intermediate sheet;
[0107] a second judging unit, for judging whether a DB business operation is successful, if yes, submitting the DB business operation, otherwise executing the DB business operation anew according to data of the inventory change intermediate sheet after rollback; and Date Regue/Date Received 2022-09-22
[0108] a second updating unit, for starting a DB business, and updating the commodity information in the database.
[0109] As a preferred mode of execution in the embodiments of the present invention, the device further comprises:
[0110] a setting module, for setting grayscale statuses of commodities as in grayscale, out of grayscale, and in switching; and
[0111] a judging module, for judging the grayscale status of commodities to which a given request in the request list corresponds, and directly returning processing failure in the case that the grayscale status is in switching.
[0112] In summary, the technical solutions provided by the embodiments of the present invention bring about the following advantageous effects.
[011311. The sales locking method and device based on caching provided by the embodiments of the present invention modulo divide commodity information into plural pieces according to commodity codes, and respectively store the same information in cache libraries correspondingly coded by Redis according to a preset rule, whereby is avoided the use of a single Redis cache library to store great quantities of data, and enquiring efficiency is enhanced.
[0114] 2. In the sales locking method and device based on caching provided by the embodiments of the present invention, consistency of data is ensured by employing the atomicity of LUA scripts in replace of database businesses, and single-thread characteristics of Redis are made use of to perform concurrent control of the stock.
[0115] 3. In the sales locking method and device based on caching provided by the embodiments of the present invention, processing efficiency is enhanced by placing the complicated data structure in cache (Redis cache libraries), and then employing LUA to perform Date Regue/Date Received 2022-09-22 enquiring calculation and deduction of stock quantity; moreover, the database is asynchronously updated through second-grade JOB, and the second-grade JOB is set and a retry mechanism is employed to finally ensure consistency between the cache and data in the database.
[0116] 4. In the sales locking method and device based on caching provided by the embodiments of the present invention, three statuses as in grayscale, out of grayscale, and in switching are used to judge the location of data and to thereafter maintain the data, and grayscale statuses are employed to solve the problem concerning inconsistency between cache and database data caused by the processing of data when there is an incoming request during the process in which the data is switched to the cache.
[0117] As should be noted, when the sales locking device based on caching provided by the aforementioned embodiment triggers a sales locking business, the division into the aforementioned various functional modules is merely by way of example, while it is possible, in actual application, to assign the functions based on requirements to different functional modules for completion, that is to say, to divide the internal structure of the device into different functional modules to complete the entire or partial functions described above. In addition, the sales locking device based on caching provided by the aforementioned embodiment pertains to the same conception as the sales locking method based on caching provided by the method embodiment, that is to say, the device is based on the sales locking method based on caching ¨ see the corresponding method embodiment for its specific realization process, while no repetition will be made in this context.
[0118] As understandable by persons ordinarily skilled in the art, realization of the entire or partial steps of the aforementioned embodiments can be completed by hardware, or by a program instructing relevant hardware, the program can be stored in a computer-readable storage medium, and the storage medium can be a read-only memory, a magnetic disk, or Date Regue/Date Received 2022-09-22 an optical disk, etc.
[0119] What is described above is merely directed to preferred embodiments of the present invention, and is not meant to restrict the present invention. Any modification, equivalent substitution, and improvement makeable within the spirit and principle of the present invention shall all be covered by the protection scope of the present invention.
Date Regue/Date Received 2022-09-22
[011311. The sales locking method and device based on caching provided by the embodiments of the present invention modulo divide commodity information into plural pieces according to commodity codes, and respectively store the same information in cache libraries correspondingly coded by Redis according to a preset rule, whereby is avoided the use of a single Redis cache library to store great quantities of data, and enquiring efficiency is enhanced.
[0114] 2. In the sales locking method and device based on caching provided by the embodiments of the present invention, consistency of data is ensured by employing the atomicity of LUA scripts in replace of database businesses, and single-thread characteristics of Redis are made use of to perform concurrent control of the stock.
[0115] 3. In the sales locking method and device based on caching provided by the embodiments of the present invention, processing efficiency is enhanced by placing the complicated data structure in cache (Redis cache libraries), and then employing LUA to perform Date Regue/Date Received 2022-09-22 enquiring calculation and deduction of stock quantity; moreover, the database is asynchronously updated through second-grade JOB, and the second-grade JOB is set and a retry mechanism is employed to finally ensure consistency between the cache and data in the database.
[0116] 4. In the sales locking method and device based on caching provided by the embodiments of the present invention, three statuses as in grayscale, out of grayscale, and in switching are used to judge the location of data and to thereafter maintain the data, and grayscale statuses are employed to solve the problem concerning inconsistency between cache and database data caused by the processing of data when there is an incoming request during the process in which the data is switched to the cache.
[0117] As should be noted, when the sales locking device based on caching provided by the aforementioned embodiment triggers a sales locking business, the division into the aforementioned various functional modules is merely by way of example, while it is possible, in actual application, to assign the functions based on requirements to different functional modules for completion, that is to say, to divide the internal structure of the device into different functional modules to complete the entire or partial functions described above. In addition, the sales locking device based on caching provided by the aforementioned embodiment pertains to the same conception as the sales locking method based on caching provided by the method embodiment, that is to say, the device is based on the sales locking method based on caching ¨ see the corresponding method embodiment for its specific realization process, while no repetition will be made in this context.
[0118] As understandable by persons ordinarily skilled in the art, realization of the entire or partial steps of the aforementioned embodiments can be completed by hardware, or by a program instructing relevant hardware, the program can be stored in a computer-readable storage medium, and the storage medium can be a read-only memory, a magnetic disk, or Date Regue/Date Received 2022-09-22 an optical disk, etc.
[0119] What is described above is merely directed to preferred embodiments of the present invention, and is not meant to restrict the present invention. Any modification, equivalent substitution, and improvement makeable within the spirit and principle of the present invention shall all be covered by the protection scope of the present invention.
Date Regue/Date Received 2022-09-22
Claims (10)
1. A sales locking method based on caching, characterized in that the method comprises the following steps:
S1 ¨ modulo dividing commodity information into plural pieces according to commodity codes, and respectively storing the same information in cache libraries correspondingly coded by Redis according to a preset rule;
S2 ¨ obtaining and parsing a sales locking request of the commodities, and obtaining a request list;
S3 ¨ recording an inventory change intermediate sheet within the same business according to the request list, and thereafter updating the commodity information in the cache libraries correspondingly coded by Redis; and S4 ¨ employing second-grade JOB to asynchronously update the commodity information in a database according to the inventory change intermediate sheet.
S1 ¨ modulo dividing commodity information into plural pieces according to commodity codes, and respectively storing the same information in cache libraries correspondingly coded by Redis according to a preset rule;
S2 ¨ obtaining and parsing a sales locking request of the commodities, and obtaining a request list;
S3 ¨ recording an inventory change intermediate sheet within the same business according to the request list, and thereafter updating the commodity information in the cache libraries correspondingly coded by Redis; and S4 ¨ employing second-grade JOB to asynchronously update the commodity information in a database according to the inventory change intermediate sheet.
2. The sales locking method based on caching according to Claim 1, characterized in that step S3 specifically includes:
S3.1 ¨ choosing to start a multi-threads processing request or a single thread processing request according to number of piece(s) in the request list;
S3.2 ¨ traversing requests in the request list, verifying contents of the requests, executing step S3.3 if verification is passed, otherwise packaging any request not passing the verification, and continuously verifying remaining requests in the request list;
S3.3 ¨ enquiring whether a given request is in a sales locking sheet, if not, executing step S3.4 after having newly added the request to the sales locking sheet, otherwise directly executing step S3.4; and S3.4 ¨ recording the inventory change intermediate sheet, and updating the commodity information in the cache libraries correspondingly coded by Redis.
Date Regue/Date Received 2022-09-22
S3.1 ¨ choosing to start a multi-threads processing request or a single thread processing request according to number of piece(s) in the request list;
S3.2 ¨ traversing requests in the request list, verifying contents of the requests, executing step S3.3 if verification is passed, otherwise packaging any request not passing the verification, and continuously verifying remaining requests in the request list;
S3.3 ¨ enquiring whether a given request is in a sales locking sheet, if not, executing step S3.4 after having newly added the request to the sales locking sheet, otherwise directly executing step S3.4; and S3.4 ¨ recording the inventory change intermediate sheet, and updating the commodity information in the cache libraries correspondingly coded by Redis.
Date Regue/Date Received 2022-09-22
3. The sales locking method based on caching according to Claim 2, characterized in that the step of updating the commodity information in the cache libraries correspondingly coded by Redis specifically includes:
employing a Lua script to atomically manipulate a Redis cache, calculating whether a stock of commodities to which the request corresponds satisfies the request, if yes, modifying a stock quantity in the commodity information, otherwise returning failure.
employing a Lua script to atomically manipulate a Redis cache, calculating whether a stock of commodities to which the request corresponds satisfies the request, if yes, modifying a stock quantity in the commodity information, otherwise returning failure.
4. The sales locking method based on caching according to Claim 1 or 2, characterized in that step S4 specifically includes:
S4.1 ¨ enquiring whether there is data in the inventory change intermediate sheet, if yes, starting a DB business, and updating the commodity information in the database, otherwise performing no processing;
S4.2 ¨ judging whether the DB business operation is successful, if yes, submitting the DB
business operation, otherwise executing step S4.3 after rollback; and S4.3 ¨ executing the DB business operation anew according to the data of the inventory change intermediate sheet until execution succeeds.
S4.1 ¨ enquiring whether there is data in the inventory change intermediate sheet, if yes, starting a DB business, and updating the commodity information in the database, otherwise performing no processing;
S4.2 ¨ judging whether the DB business operation is successful, if yes, submitting the DB
business operation, otherwise executing step S4.3 after rollback; and S4.3 ¨ executing the DB business operation anew according to the data of the inventory change intermediate sheet until execution succeeds.
5. The sales locking method based on caching according to Claim 1 or 2, characterized in that, prior to the step of updating the commodity information in the cache libraries correspondingly coded by Redis according to the request list, the method further comprises:
setting grayscale statuses of commodities as in grayscale, out of grayscale, and in switching; and judging the grayscale status of commodities to which a given request in the request list corresponds, and directly returning processing failure in the case that the grayscale status is in swi tching.
setting grayscale statuses of commodities as in grayscale, out of grayscale, and in switching; and judging the grayscale status of commodities to which a given request in the request list corresponds, and directly returning processing failure in the case that the grayscale status is in swi tching.
6. A sales locking system based on caching, characterized in that the system comprises:
a dividing module, for modulo dividing commodity information into plural pieces according to commodity codes, and respectively storing the same information in cache libraries Date Regue/Date Received 2022-09-22 correspondingly coded by Redis according to a preset rule;
a parsing module, for obtaining and parsing a sales locking request of the commodities, and obtaining a request list;
a first updating module, for recording an inventory change intermediate sheet within the same business according to the request list, and thereafter updating the commodity information in the cache libraries correspondingly coded by Redis; and a second updating module, for employing second-grade JOB to asynchronously update the commodity information in a database according to the inventory change intermediate sheet.
a dividing module, for modulo dividing commodity information into plural pieces according to commodity codes, and respectively storing the same information in cache libraries Date Regue/Date Received 2022-09-22 correspondingly coded by Redis according to a preset rule;
a parsing module, for obtaining and parsing a sales locking request of the commodities, and obtaining a request list;
a first updating module, for recording an inventory change intermediate sheet within the same business according to the request list, and thereafter updating the commodity information in the cache libraries correspondingly coded by Redis; and a second updating module, for employing second-grade JOB to asynchronously update the commodity information in a database according to the inventory change intermediate sheet.
7. The sales locking system based on caching according to Claim 6, characterized in that the first updating module includes:
a first judging unit, for choosing to start a multi-threads processing request or a single thread processing request according to number of piece(s) in the request list;
a verifying unit, for traversing requests in the request list, and verifying contents of the requests;
a first enquiring unit, for enquiring whether a given request is in a sales locking sheet; and a first updating unit, for recording the inventory change intermediate sheet, and updating the commodity information in the cache libraries correspondingly coded by Redis.
a first judging unit, for choosing to start a multi-threads processing request or a single thread processing request according to number of piece(s) in the request list;
a verifying unit, for traversing requests in the request list, and verifying contents of the requests;
a first enquiring unit, for enquiring whether a given request is in a sales locking sheet; and a first updating unit, for recording the inventory change intermediate sheet, and updating the commodity information in the cache libraries correspondingly coded by Redis.
8. The sales locking system based on caching according to Claim 7, characterized in that the first updating unit is specifically employed for:
employing a Lua script to atomically manipulate a Redis cache, calculating whether a stock of commodities to which the request corresponds satisfies the request, if yes, modifying a stock quantity in the commodity information, otherwise returning failure.
employing a Lua script to atomically manipulate a Redis cache, calculating whether a stock of commodities to which the request corresponds satisfies the request, if yes, modifying a stock quantity in the commodity information, otherwise returning failure.
9. The sales locking system based on caching according to Claim 6 or 7, characterized in that the second updating module includes:
a second enquiring unit, for enquiring whether there is data in the inventory change intermediate sheet;
a second judging unit, for judging whether a DB business operation is successful, if yes, Date Regue/Date Received 2022-09-22 submitting the DB business operation, otherwise executing the DB business operation anew according to data of the inventory change intermediate sheet after rollback;
and a second updating unit, for starting a DB business, and updating the commodity information in the database.
a second enquiring unit, for enquiring whether there is data in the inventory change intermediate sheet;
a second judging unit, for judging whether a DB business operation is successful, if yes, Date Regue/Date Received 2022-09-22 submitting the DB business operation, otherwise executing the DB business operation anew according to data of the inventory change intermediate sheet after rollback;
and a second updating unit, for starting a DB business, and updating the commodity information in the database.
10. The sales locking system based on caching according to Claim 6 or 7, characterized in that the system further comprises:
a setting module, for setting grayscale statuses of commodities as in grayscale, out of grayscale, and in switching; and a judging module, for judging the grayscale status of commodities to which a given request in the request list corresponds, and directly returning processing failure in the case that the grayscale status is in switching.
Date Regue/Date Received 2022-09-22
a setting module, for setting grayscale statuses of commodities as in grayscale, out of grayscale, and in switching; and a judging module, for judging the grayscale status of commodities to which a given request in the request list corresponds, and directly returning processing failure in the case that the grayscale status is in switching.
Date Regue/Date Received 2022-09-22
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910247896.6A CN111752957B (en) | 2019-03-28 | 2019-03-28 | Sale locking method and system based on caching |
| CN201910247896.6 | 2019-03-28 | ||
| PCT/CN2019/109094 WO2020192063A1 (en) | 2019-03-28 | 2019-09-29 | Caching-based method and system for sales locking |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA3176449A1 true CA3176449A1 (en) | 2020-10-01 |
Family
ID=72608730
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA3176449A Pending CA3176449A1 (en) | 2019-03-28 | 2019-09-29 | Sales locking method and system based on a caching |
Country Status (3)
| Country | Link |
|---|---|
| CN (1) | CN111752957B (en) |
| CA (1) | CA3176449A1 (en) |
| WO (1) | WO2020192063A1 (en) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112667600A (en) * | 2020-12-28 | 2021-04-16 | 紫光云技术有限公司 | Inventory solution method combining redis and MySQL |
| CN113807760A (en) * | 2021-01-07 | 2021-12-17 | 北京沃东天骏信息技术有限公司 | Inventory information processing method and device, readable storage medium and electronic equipment |
| CN112380026A (en) * | 2021-01-13 | 2021-02-19 | 常州微亿智造科技有限公司 | Task processing method and device and storage medium |
| CN112749199A (en) * | 2021-01-25 | 2021-05-04 | 上海伯俊软件科技有限公司 | Inventory management method |
| CN112765277A (en) * | 2021-01-28 | 2021-05-07 | 树根互联股份有限公司 | Data synchronization method, device and system |
| CN112860746B (en) * | 2021-02-01 | 2023-04-07 | 上海万物新生环保科技集团有限公司 | Cache reduction-based method, equipment and system |
| CN113377770A (en) * | 2021-06-07 | 2021-09-10 | 北京沃东天骏信息技术有限公司 | Data processing method and device |
| CN113868278B (en) * | 2021-09-29 | 2023-08-01 | 北京有竹居网络技术有限公司 | Data processing method, device and equipment |
| CN113868100B (en) * | 2021-10-27 | 2024-08-13 | 北京值得买科技股份有限公司 | Automatic dispatching acquisition system for data in electronic commerce field |
| CN114331576A (en) * | 2021-12-30 | 2022-04-12 | 福建博思软件股份有限公司 | Electronic ticket number rapid ticket taking method based on high concurrency scene and storage medium |
| CN114386904A (en) * | 2022-01-05 | 2022-04-22 | 北京京东振世信息技术有限公司 | Stock preemption method, device, server and storage medium |
| CN114969067A (en) * | 2022-04-29 | 2022-08-30 | 广州欢聚时代信息科技有限公司 | Commodity redundant data updating method and device, equipment and medium thereof |
| CN114971472A (en) * | 2022-05-30 | 2022-08-30 | 北京京东振世信息技术有限公司 | Method and device for managing inventory data |
| CN116167699B (en) * | 2023-01-16 | 2023-11-14 | 广州辰创科技发展有限公司 | Equipment guarantee resource management method and system |
| CN117611183B (en) * | 2023-09-26 | 2024-08-30 | 重庆赛力斯新能源汽车设计院有限公司 | Commodity pre-sale operation method and device, electronic equipment and readable storage medium |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9047351B2 (en) * | 2010-04-12 | 2015-06-02 | Sandisk Enterprise Ip Llc | Cluster of processing nodes with distributed global flash memory using commodity server technology |
| CN105468690B (en) * | 2015-11-17 | 2018-11-30 | 中国建设银行股份有限公司 | A kind of inventory data treating method and apparatus |
| CN106170016A (en) * | 2016-07-28 | 2016-11-30 | 深圳市创梦天地科技有限公司 | A kind of method and system processing high concurrent data requests |
| CN107220878A (en) * | 2017-05-26 | 2017-09-29 | 努比亚技术有限公司 | Transaction processing system, second kill order processing method and apparatus |
| CN108897615B (en) * | 2018-05-31 | 2023-06-13 | 康键信息技术（深圳）有限公司 | Second killing request processing method, application server cluster and storage medium |
-
2019
- 2019-03-28 CN CN201910247896.6A patent/CN111752957B/en active Active
- 2019-09-29 WO PCT/CN2019/109094 patent/WO2020192063A1/en active Application Filing
- 2019-09-29 CA CA3176449A patent/CA3176449A1/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| CN111752957B (en) | 2022-11-11 |
| CN111752957A (en) | 2020-10-09 |
| WO2020192063A1 (en) | 2020-10-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA3176449A1 (en) | Sales locking method and system based on a caching | |
| US10824981B2 (en) | Transaction orchestration for microservice | |
| EP2600246B1 (en) | Batch processing of business objects | |
| US11061884B2 (en) | Method and system to accelerate transaction commit using non-volatile memory | |
| US8341629B2 (en) | Method and system for provisioning a virtual computer and scheduling resources of the provisioned virtual computer | |
| US8494888B2 (en) | Offline modification of business data | |
| CN105096065A (en) | Inventory deduction method and inventory deduction device | |
| CN112817995B (en) | Data processing method and device, electronic equipment and storage medium | |
| US11080146B2 (en) | System and method for storage unavailability tolerant backup | |
| WO2014077918A1 (en) | Robustness in a scalable block storage system | |
| US20130198467A1 (en) | Managing remote data replication | |
| CN113157411B (en) | Celery-based reliable configurable task system and device | |
| US10620854B1 (en) | Validating data for deployment | |
| CN109885382A (en) | The system of cross-system distributed transaction processing method and distributing real time system | |
| US11243979B1 (en) | Asynchronous propagation of database events | |
| CN115220876A (en) | Virtual resource creating method, device, program product, medium and electronic equipment | |
| US8060885B2 (en) | Creating task queries for concrete resources using alias selection fields specifying formal resources and formal relationships | |
| US10726047B2 (en) | Early thread return with secondary event writes | |
| CN114371939A (en) | Task processing method, device, electronic equipment, storage medium and program product | |
| CN114119129A (en) | High-concurrency second killing system | |
| US11281542B2 (en) | System and method for backup generation for deployments | |
| US11425245B2 (en) | Method and system for capturing data of actions | |
| CN106293980A (en) | Data recovery method and system for distributed storage cluster | |
| CN115374098A (en) | High concurrent payment order anti-duplication method, apparatus, system, device, medium, and program product | |
| US12093139B2 (en) | Rolling back a database transaction |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request |
Effective date: 20220922 |
|
| EEER | Examination request |
Effective date: 20220922 |
|
| EEER | Examination request |
Effective date: 20220922 |
|
| EEER | Examination request |
Effective date: 20220922 |
|
| EEER | Examination request |
Effective date: 20220922 |
|
| EEER | Examination request |
Effective date: 20220922 |
|
| EEER | Examination request |
Effective date: 20220922 |
|
| EEER | Examination request |
Effective date: 20220922 |