CN112990823A - Method, system and storage medium for realizing inventory management - Google Patents
Method, system and storage medium for realizing inventory management Download PDFInfo
- Publication number
- CN112990823A CN112990823A CN202110334791.1A CN202110334791A CN112990823A CN 112990823 A CN112990823 A CN 112990823A CN 202110334791 A CN202110334791 A CN 202110334791A CN 112990823 A CN112990823 A CN 112990823A
- Authority
- CN
- China
- Prior art keywords
- stock
- version number
- order
- request
- data
- 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 33
- 230000007246 mechanism Effects 0.000 claims abstract description 37
- 238000012545 processing Methods 0.000 claims description 18
- 238000004590 computer program Methods 0.000 claims description 4
- 230000003993 interaction Effects 0.000 abstract description 3
- 238000007726 management method Methods 0.000 description 24
- 235000012054 meals Nutrition 0.000 description 10
- 230000008569 process Effects 0.000 description 4
- 230000009467 reduction Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 235000013305 food Nutrition 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000006872 improvement 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
- 230000009471 action Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- 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
-
- 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/21—Design, administration or maintenance of databases
- G06F16/219—Managing data history or versioning
-
- 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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
-
- 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
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/12—Hotels or restaurants
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Economics (AREA)
- Tourism & Hospitality (AREA)
- Databases & Information Systems (AREA)
- Finance (AREA)
- Marketing (AREA)
- Accounting & Taxation (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Human Resources & Organizations (AREA)
- Development Economics (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Quality & Reliability (AREA)
- Entrepreneurship & Innovation (AREA)
- Operations Research (AREA)
- Fuzzy Systems (AREA)
- Mathematical Physics (AREA)
- Probability & Statistics with Applications (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The invention discloses a method, a system and a storage medium for realizing inventory management. The method comprises the following steps: s1, receiving order request from user, reading stock data and version number; s2, receiving an order submitting request; s3, performing redis distributed lock operation on all order submission requests, wherein each order submission request is stored in a transaction queue as a transaction, and the step S4 is sequentially performed on each order submission request according to the sequence stored in the transaction queue; and S4, judging whether the order submitting request can be processed successfully, and updating the stock data and the stock version number by using an optimistic lock mechanism after the order submitting request is processed successfully. The inventory management of the invention does not need to frequently access the inventory quantity of the commodities in the database, does not block other users, realizes safe deduction of inventory quantity and the quantity of the memory access inventory, and reduces database interaction.
Description
Technical Field
The present invention belongs to the field of internet technology, and more particularly, to a method, a system and a storage medium for implementing inventory management.
Background
In recent years, meal ordering and takeout systems are rapidly developed in the field of internet, and users select dishes through mobile phones or websites to order personal meal ordering services. With the increase of the number of users, the requirement of multiple concurrent food ordering on inventory control of dishes is higher and higher, and when the same user or a plurality of users order and order the same dish at the same time, how to achieve concurrent safety inventory reduction becomes a problem which needs to be considered. Aiming at the inventory control of dishes ordered by multiple times, the common method is that some manufacturers adopt an exclusive lock and a shared lock, and some manufacturers adopt a pessimistic lock or a synchronous lock.
Exclusive Locks (Exclusive Locks), also known as write Locks, Exclusive Locks, are one of the basic types of Locks at database management. If transaction T places an X lock on data object A, then T is only allowed to read and modify A, and any other transaction can not place any type of lock on A until T releases the lock on A. This ensures that other transactions can no longer read and modify A before T releases the lock on A.
If transaction T adds S lock to data object A, then transaction T can only read A; other transactions can only place S-locks on A and not X-locks until T releases the S-lock on A. This ensures that other transactions can read A, but cannot make any modifications to A until T releases the S lock on A.
Pessimistic Lock (Pessimistic Lock) means that each time data is taken, someone else is considered to modify the Lock, so that the Lock is taken each time data is taken, and thus the Lock will be taken until someone else wants to take the data. Many of these locking mechanisms are used in conventional relational databases, such as row locks, table locks, etc., read locks, write locks, etc., which are locked prior to operation. It refers to keeping the data conservative of being modified by the outside world (including other transactions of the system currently and transactions from external systems), so that the data is in a locked state in the whole data processing process. Pessimistic lock implementation usually depends on a lock mechanism provided by a database, and only the lock mechanism provided by a database layer can really ensure exclusivity of data access, otherwise, even if a locking mechanism is implemented in a system, it cannot ensure that an external system cannot modify data).
An Optimistic Lock (Optimistic Lock) means that it is considered that someone else will not modify the data every time the data is taken, so that the data will not be locked. Optimistic locks are suitable for multiple-read application types, which may improve throughput if the database provides an optimistic lock similar to the write condition (write _ condition) mechanism that it provides in all.
However, these solutions all have a certain impact on system performance, and in severe cases, deadlock may be caused, so that the relevant processes can never allocate necessary resources without assistance of external force and cannot continue to run
Disclosure of Invention
Aiming at least one defect or improvement requirement in the prior art, the invention provides a method, a system and a storage medium for realizing inventory management, which do not need to frequently access the inventory quantity of commodities in a database, do not block other users, realize safety reduction of inventory quantity and memory access of inventory quantity, and reduce database interaction.
To achieve the above object, according to a first aspect of the present invention, there is provided a method for achieving inventory management, including the steps of:
s1, receiving order request from user, reading stock data and version number;
s2, receiving an order submission request and adding the stock version number read in the step S1 to the order submission request, wherein the order submission request also comprises the order placing quantity;
s3, performing redis distributed lock operation on all order submission requests, wherein each order submission request is stored in a transaction queue as a transaction, and the step S4 is sequentially performed on each order submission request according to the sequence stored in the transaction queue;
and S4, judging whether the order submitting request can be processed successfully, and updating the stock data and the stock version number by using an optimistic lock mechanism after the order submitting request is processed successfully.
Preferably, the S4 includes the sub-steps of:
s41, reading the current stock version number again, comparing whether the stock version number in the order submitting request is consistent with the current stock version number, if so, executing the step S42, and if not, executing the step S43;
s42, returning order submission success information to the front-end ordering interface and updating the stock data and the stock version number by using an optimistic lock mechanism;
s43, covering the last read version number with the stock version number in the order submission request, reading the stock data and the stock version number again, judging whether the stock is enough according to the stock data, if so, comparing whether the stock version number in the order submission request is consistent with the stock version number, if so, executing the step S42, and if not, executing the step S43 again until the preset end condition is met.
Preferably, the S42 further includes: if an item removal request is received, a trigger mechanism is used to trigger an item sales volume.
Preferably, the S42 further includes: and if an order cancellation request is received or no article removal request is received within preset time, triggering the stock data to be restored to the stock data corresponding to the previous stock version number by using a trigger mechanism, and updating the stock version number.
Preferably, the method is performed on a server.
According to a second aspect of the present invention, there is provided a system for implementing inventory management, comprising:
the reading module is used for receiving a user order placing request and reading the inventory data and the inventory version number at the moment;
the receiving module is used for receiving the order submitting request and adding the inventory version number read by the reading module to the order submitting request, and the order submitting request also comprises the order placing quantity;
the distributed lock operation module is used for performing redis distributed lock operation on all order submission requests, wherein each order submission request is stored in a transaction queue as a transaction, and the step S4 is sequentially performed on each order submission request according to the sequence stored in the transaction queue;
and the order processing module is used for judging whether the order submitting request can be processed successfully or not and updating the stock data and the stock version number by using an optimistic lock mechanism after the order submitting request is processed successfully.
Preferably, the order processing module is configured to implement the following sub-steps:
s41, reading the current stock version number again, comparing whether the stock version number in the order submitting request is consistent with the current stock version number, if so, executing the step S42, and if not, executing the step S43;
s42, returning order submission success information to the front-end ordering interface and updating the stock data and the stock version number by using an optimistic lock mechanism;
s43, covering the last read version number with the stock version number in the order submission request, reading the stock data and the stock version number again, judging whether the stock is enough according to the stock data, if so, comparing whether the stock version number in the order submission request is consistent with the stock version number, if so, executing the step S42, and if not, executing the step S43 again until the preset end condition is met.
Preferably, the S42 further includes the steps of: if an article removal request is received, a trigger mechanism is used to trigger the sales volume of the newly added article.
Preferably, the S42 further includes: and if an order cancellation request is received or no article removal request is received within preset time, triggering the stock data to be restored to the stock data corresponding to the previous stock version number by using a trigger mechanism, and updating the stock version number.
According to a third aspect of the invention, there is provided a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of any of the above.
In general, compared with the prior art, the invention has the following beneficial effects:
(1) according to the method for realizing the canteen dish inventory management based on the trigger, provided by the invention, a database trigger, redis atomic operation and sql optimistic locking mechanism is adopted, so that the number of commodity inventories in the database does not need to be frequently accessed, other users are not blocked, the safe reduction of the inventory quantity and the memory access inventory quantity are realized, and the database interaction is reduced;
(2) the method for realizing the canteen dish inventory management based on the trigger can realize the functions of dish management, dish shelf loading and unloading, dish statistics and the like, can be accessed to a system for ordering, user payment and the like, and has expandability;
(3) the method for realizing the canteen dish inventory management based on the trigger can be additionally optimized for high-concurrency meal ordering, reduces the system operation burden and effectively improves the user experience.
Drawings
FIG. 1 is a system architecture diagram of an embodiment of the present invention;
FIG. 2 is a flow chart of administrator operation of an embodiment of the present invention;
FIG. 3 is a flow chart of user operation of an embodiment of the present invention;
FIG. 4 is a flow chart of a business logic implementation of an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. In addition, the technical features involved in the embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.
Terms related to the embodiments of the present invention are explained as follows.
Redis (remote Dictionary Server), a remote Dictionary service, is an open-source log-type and Key-Value (Key-Value) database written in ANSIC language, supporting network, based on memory and persistent, and provides API of multiple languages. Redis is a memory-based data structure store that can be used as database, cache, and message middleware. Redis also exists in the form of message queues, and exists as an embedded List, so that the real-time high concurrency requirement is met.
A trigger is a database object associated with a table that triggers when a defined condition is satisfied and executes a set of statements defined in the trigger. This characteristic of the trigger may assist the application in ensuring data integrity on the database side. It differs from the stored procedure, mainly performed by event triggering, i.e. not actively invoked; the stored procedure needs to actively call the name to execute. Data can be forcibly checked or converted (data protection is ensured) before data is written, and when the trigger has an error, the operation which is successfully executed by the previous user can be cancelled.
As shown in fig. 1, a system architecture of an application of a method for implementing inventory management according to an embodiment of the present invention includes a user layer, a presentation layer, a business logic layer, and a data layer.
The users of the user layer are divided into managers and users; the presentation layer is used for providing the user to input the dish inventory and reserve and order the meal operation.
The data layer classifies the data collected by the facility layer, and the data is mainly classified into user data, basic data and business data for classified storage, so that various data processing and interface service management are realized, a data exchange mechanism is provided for different data access, and a data unified access interface is provided for the outside.
The business processing layer is used for monitoring an order placing request (an instruction of adding commodities to the shopping cart) and an order submitting request of a user and sending out a commodity inventory request; and the stock management module is used for transmitting the stock management module to a background processing stock operation logic function, processing multiple concurrent ordering requests by using a redis atomic operation + sql optimistic lock mechanism, and processing stock changes caused by sales volume and order state changes by using a trigger. The business process layer may be implemented on a server.
As shown in fig. 2, the method for implementing inventory management according to the embodiment of the present invention may be applied to inventory management of canteen dishes, but may also be applied to other inventory management, and the principle of the inventory management method in different scenarios is the same. The following takes the management of the inventory of dishes as an example.
An operational flow diagram at the administrator side comprising the steps of:
s1: adding dish information at the rear end of management;
s2: and setting the shelf date and the number of meals of the dishes, and meanwhile, setting the stock of the dishes on the shelf.
As shown in fig. 3, a flowchart of a method for implementing inventory management based on a trigger according to an embodiment of the present invention on a user operation side includes the following steps:
s1: selecting the meal ordering date and the meal times;
s2: selecting food ordering dishes to be added into the shopping cart, and editing the quantity of the dishes in the shopping cart;
s3: judging whether the quantity of the shopping cart dishes exceeds the current inventory, if so, entering a step S2, otherwise, entering a step S4;
s4: submitting a meal ordering order;
s5: judging whether the quantity of the ordered dishes exceeds the current inventory, if so, entering a step S2, otherwise, entering a step S6;
s6: the system generates an order that the user can cancel before the order is confirmed or pay to complete the meal.
As shown in fig. 4, a business logic implementation flow of the method for implementing inventory management based on triggers according to the embodiment of the present invention includes the following steps:
and S1, receiving order placing request of the user, and reading the inventory data and the inventory version number at the moment.
The order placing request of the user can be, for example, an instruction for adding commodities to a shopping cart, and after the order placing request of the user is monitored by the business layer, the inventory data and the inventory version number at the moment are read from the background database. And returning the stock data to a front-end interface to be displayed to a user, wherein the user can only click to submit the order if the added order placing quantity is less than the stock data.
S2, receiving an order submission request and adding the stock version number read in the step S1 to the order submission request, wherein the order submission request also includes the order placing quantity.
The service layer receives an order submission request from the user, where the order submission request includes the order quantity and the inventory version number read in step S1.
S3, performing redis distributed lock operation on all order submission requests, wherein each order submission request is stored in a transaction queue as a transaction, and the step S4 is sequentially performed on each order submission request according to the sequence stored in the transaction queue.
Specifically, the method comprises the following steps: distributed locks are one way to control the synchronous access to shared resources between distributed systems. In a distributed system, it is often necessary to coordinate the actions of the systems. If one or a group of resources are shared between different systems or different hosts of the same system, then access to these resources often requires mutual exclusion to prevent interference with each other to ensure consistency, in which case a distributed lock is used. The contention of the distributed lock control thread for resources can ensure high-efficiency concurrency and correct operation.
Implementation of a redis distributed lock: the mainly used redis setnx (), firstly, a certain task identification name is stored into the redis as a key, and an expiration time is set for the task identification name; for the request again, see whether the insertion into the redis can be done through setnx () first, if so, return true, and if not, return false.
And S4, judging whether the order submitting request can be processed successfully, and updating the stock data and the stock version number by using an optimistic lock mechanism after the order submitting request is processed successfully.
And performing an optimistic locking mechanism on all the order submission requests which are processed successfully, namely updating the stock data in the dish stock data table after each order request is processed successfully, modifying a data version number version field to indicate the number of times the data is modified, and adding one to the version value when the stock data is modified.
Preferably, the step S4 includes the sub-steps of:
s41, reading the current stock version number again, comparing whether the stock version number in the order submission request is consistent with the current stock version number, if so, executing step S42, otherwise, executing step S43.
Since there is a delay between receiving the order request and processing the order submission request, for the same user, the inventory data and the inventory version number read when receiving the order request may be different from the inventory data and the inventory version number when processing the order submission request, and thus it is necessary to compare the inventory version numbers to determine whether there is a change in the inventory.
And S42, returning order submission success information to the front-end ordering interface and updating the stock data and the stock version number by using an optimistic lock mechanism.
If the comparison in step S41 shows that the inventory version number in the order submission request is consistent with the inventory version number at that time, which indicates that the inventory data has not been modified since the order was placed, the inventory must satisfy the order requirement, and the inventory data and the inventory version number are updated using the optimistic lock mechanism.
By adopting an optimistic locking mechanism, the inventory data can be modified and the version number is increased by 1 when each order submission request is successfully processed, and whether the inventory data are consistent or not can be known through comparison of the version numbers.
S43, covering the last read version number with the stock version number in the order submission request, reading the stock data and the stock version number again, judging whether the stock is enough according to the stock data, if so, comparing whether the stock version number in the order submission request is consistent with the stock version number, if so, executing the step S42, and if not, executing the step S43 again until the preset end condition is met.
If the comparison in step S41 shows that the stock version number in the order submission request is not consistent with the stock version number at that time, it means that the stock data is modified since the order is placed, and the stock does not necessarily meet the order requirement, the last read version number is used to cover the stock version number in the order submission request, then the stock data and the stock version number at that time are read again, it is determined whether the stock is sufficient according to the stock data at that time, if so, it is compared whether the stock version number in the order submission request is consistent with the stock version number at that time, and if so, the stock data and the stock version number are updated by using an optimistic lock mechanism.
The preset end condition may be set as the number of failed retries, for example, the processing of step S43 is executed again for 3 times, and if the processing still fails after 3 times, the user is prompted that the order processing fails, and the user is requested to submit again.
For example, assuming that user a adds 10 shopping carts and the read inventory of goods is 100, user a may submit an order, assuming that after user a adds a shopping cart and before it submits an order, user B also places 20 orders and submits an order first, and the order submission request of user B is located before the order submission request of user B in the transaction queue, user B will process the order submission request first, step S41 is executed, the inventory version number at this time is read, if it is determined that the inventory version number in the order submission request of user B is consistent with the inventory version number at this time, step S42 is executed if it is consistent, and step S43 is executed if it is not consistent. And then, the order submission requests of the user A are processed again according to the sequence stored in the transaction queue, the current inventory version number is read again, and the inventory version number in the order submission requests of the user A is compared with the current inventory version number to judge whether the inventory version number is consistent. If the order submission request of the user B is successfully processed before that, the inventory version number in the order submission request of the user a and the inventory version number at that time are definitely not consistent, and step S43 is executed.
Step S42 further includes: if an item removal request (e.g., a meal fetch request) is received, a trigger mechanism is used to trigger the item sales.
Step S42 further includes: if an order cancellation request is received or no article removal request is received within a preset time, a trigger mechanism is used for executing rollback processing, namely, the stock data is triggered to be restored to the stock data corresponding to the previous stock version number, and the stock version number is added with 1.
The system for realizing inventory management in the embodiment of the invention comprises:
the reading module is used for receiving a user order placing request and reading the inventory data and the inventory version number at the moment;
the receiving module is used for receiving the order submitting request and adding the inventory version number read by the reading module into the order submitting request, and the order submitting request also comprises the order placing quantity;
the distributed lock operation module is used for performing redis distributed lock operation on all order submission requests, wherein each order submission request is stored in a transaction queue as a transaction, and the step S4 is sequentially performed on each order submission request according to the sequence stored in the transaction queue;
and the order processing module is used for judging whether the order submitting request can be processed successfully or not and updating the stock data and the stock version number by using an optimistic lock mechanism after the order submitting request is processed successfully.
Preferably, the order processing module is configured to implement the following sub-steps:
s41, reading the current stock version number again, comparing whether the stock version number in the order submitting request is consistent with the current stock version number, if so, executing the step S42, and if not, executing the step S43;
s42, returning order submission success information to the front-end ordering interface and updating the stock data and the stock version number by using an optimistic lock mechanism;
s43, covering the last read version number with the stock version number in the order submission request, reading the stock data and the stock version number again, judging whether the stock is enough according to the stock data, if so, comparing whether the stock version number in the order submission request is consistent with the stock version number, if so, executing the step S42, and if not, executing the step S43 again until the preset end condition is met.
Preferably, the step S42 further includes the steps of: if an article removal request is received, a trigger mechanism is used to trigger the sales volume of the newly added article.
Preferably, the S42 further includes: and if an order cancellation request is received or no article removal request is received within preset time, triggering the stock data to be restored to the stock data corresponding to the previous stock version number by using a trigger mechanism, and updating the stock version number.
The embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, where the computer program is executed by a processor to implement any of the above-mentioned technical solutions of the embodiments of the inventory management method. The implementation principle and technical effect are similar to those of the above method, and are not described herein again.
It must be noted that in any of the above embodiments, the methods are not necessarily executed in order of sequence number, and as long as it cannot be assumed from the execution logic that they are necessarily executed in a certain order, it means that they can be executed in any other possible order.
It will be understood by those skilled in the art that the foregoing is only a preferred embodiment of the present invention, and is not intended to limit the invention, and that any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (10)
1. A method of implementing inventory management, comprising the steps of:
s1, receiving order request from user, reading stock data and version number;
s2, receiving an order submission request and adding the stock version number read in the step S1 to the order submission request, wherein the order submission request also comprises the order placing quantity;
s3, performing redis distributed lock operation on all order submission requests, wherein each order submission request is stored in a transaction queue as a transaction, and the step S4 is sequentially performed on each order submission request according to the sequence stored in the transaction queue;
and S4, judging whether the order submitting request can be processed successfully, and updating the stock data and the stock version number by using an optimistic lock mechanism after the order submitting request is processed successfully.
2. The method for implementing inventory management as claimed in claim 1, wherein said S4 includes the sub-steps of:
s41, reading the current stock version number again, comparing whether the stock version number in the order submitting request is consistent with the current stock version number, if so, executing the step S42, and if not, executing the step S43;
s42, returning order submission success information to the front-end ordering interface and updating the stock data and the stock version number by using an optimistic lock mechanism;
s43, covering the last read version number with the stock version number in the order submission request, reading the stock data and the stock version number again, judging whether the stock is enough according to the stock data, if so, comparing whether the stock version number in the order submission request is consistent with the stock version number, if so, executing the step S42, and if not, executing the step S43 again until the preset end condition is met.
3. The method for implementing inventory management as recited in claim 2, wherein said S42 further comprises: if an item removal request is received, a trigger mechanism is used to trigger an item sales volume.
4. The method of implementing inventory management as recited in claim 1 wherein said S42 further comprises: and if an order cancellation request is received or no article removal request is received within preset time, triggering the stock data to be restored to the stock data corresponding to the previous stock version number by using a trigger mechanism, and updating the stock version number.
5. The method of claim 1, wherein the method is performed on a server.
6. A system for implementing inventory management, comprising:
the reading module is used for receiving a user order placing request and reading the inventory data and the inventory version number at the moment;
the receiving module is used for receiving the order submitting request and adding the inventory version number read by the reading module to the order submitting request, and the order submitting request also comprises the order placing quantity;
the distributed lock operation module is used for performing redis distributed lock operation on all order submission requests, wherein each order submission request is stored in a transaction queue as a transaction, and the step S4 is sequentially performed on each order submission request according to the sequence stored in the transaction queue;
and the order processing module is used for judging whether the order submitting request can be processed successfully or not and updating the stock data and the stock version number by using an optimistic lock mechanism after the order submitting request is processed successfully.
7. The system for implementing inventory management as recited in claim 6 wherein said order processing module is configured to implement the substeps of:
s41, reading the current stock version number again, comparing whether the stock version number in the order submitting request is consistent with the current stock version number, if so, executing the step S42, and if not, executing the step S43;
s42, returning order submission success information to the front-end ordering interface and updating the stock data and the stock version number by using an optimistic lock mechanism;
s43, covering the last read version number with the stock version number in the order submission request, reading the stock data and the stock version number again, judging whether the stock is enough according to the stock data, if so, comparing whether the stock version number in the order submission request is consistent with the stock version number, if so, executing the step S42, and if not, executing the step S43 again until the preset end condition is met.
8. The system for implementing inventory management as claimed in claim 7, wherein said step S42 further includes the steps of: if an article removal request is received, a trigger mechanism is used to trigger the sales volume of the newly added article.
9. The system for implementing inventory management as claimed in claim 7, wherein said S42 further includes: and if an order cancellation request is received or no article removal request is received within preset time, triggering the stock data to be restored to the stock data corresponding to the previous stock version number by using a trigger mechanism, and updating the stock version number.
10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110334791.1A CN112990823A (en) | 2021-03-29 | 2021-03-29 | Method, system and storage medium for realizing inventory management |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110334791.1A CN112990823A (en) | 2021-03-29 | 2021-03-29 | Method, system and storage medium for realizing inventory management |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112990823A true CN112990823A (en) | 2021-06-18 |
Family
ID=76337884
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110334791.1A Pending CN112990823A (en) | 2021-03-29 | 2021-03-29 | Method, system and storage medium for realizing inventory management |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112990823A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112749199A (en) * | 2021-01-25 | 2021-05-04 | 上海伯俊软件科技有限公司 | Inventory management method |
| CN113919916A (en) * | 2021-10-20 | 2022-01-11 | 广州品唯软件有限公司 | Order splitting method and device and electronic equipment |
| CN114598559A (en) * | 2021-07-22 | 2022-06-07 | 湖南亚信软件有限公司 | Data processing method and device, electronic equipment and computer readable storage medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104636933A (en) * | 2015-02-11 | 2015-05-20 | 广州唯品会信息科技有限公司 | Method and device for positioning oversell reasons of e-commerce website |
| CN108418821A (en) * | 2018-03-06 | 2018-08-17 | 北京焦点新干线信息技术有限公司 | Redis and Kafka-based high-concurrency scene processing method and device for online shopping system |
| CN110135965A (en) * | 2019-05-22 | 2019-08-16 | 上海证大爱特金融信息服务有限公司 | A kind of assets and the fast automatic match method of fund and system |
| CN111400283A (en) * | 2020-03-19 | 2020-07-10 | 中国建设银行股份有限公司 | Data processing method, system, electronic equipment and storage medium |
| CN111507729A (en) * | 2020-04-29 | 2020-08-07 | 广东所能网络有限公司 | Electronic commerce risk control system and method based on mobile internet |
| CN112347111A (en) * | 2019-12-05 | 2021-02-09 | 北京沃东天骏信息技术有限公司 | Data updating method and device |
-
2021
- 2021-03-29 CN CN202110334791.1A patent/CN112990823A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104636933A (en) * | 2015-02-11 | 2015-05-20 | 广州唯品会信息科技有限公司 | Method and device for positioning oversell reasons of e-commerce website |
| CN108418821A (en) * | 2018-03-06 | 2018-08-17 | 北京焦点新干线信息技术有限公司 | Redis and Kafka-based high-concurrency scene processing method and device for online shopping system |
| CN110135965A (en) * | 2019-05-22 | 2019-08-16 | 上海证大爱特金融信息服务有限公司 | A kind of assets and the fast automatic match method of fund and system |
| CN112347111A (en) * | 2019-12-05 | 2021-02-09 | 北京沃东天骏信息技术有限公司 | Data updating method and device |
| CN111400283A (en) * | 2020-03-19 | 2020-07-10 | 中国建设银行股份有限公司 | Data processing method, system, electronic equipment and storage medium |
| CN111507729A (en) * | 2020-04-29 | 2020-08-07 | 广东所能网络有限公司 | Electronic commerce risk control system and method based on mobile internet |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112749199A (en) * | 2021-01-25 | 2021-05-04 | 上海伯俊软件科技有限公司 | Inventory management method |
| CN114598559A (en) * | 2021-07-22 | 2022-06-07 | 湖南亚信软件有限公司 | Data processing method and device, electronic equipment and computer readable storage medium |
| CN114598559B (en) * | 2021-07-22 | 2024-06-07 | 湖南亚信软件有限公司 | Data processing method, device, electronic equipment and computer readable storage medium |
| CN113919916A (en) * | 2021-10-20 | 2022-01-11 | 广州品唯软件有限公司 | Order splitting method and device and electronic equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11243920B2 (en) | Distributed database system, transaction processing method, lock server and storage medium | |
| CN112990823A (en) | Method, system and storage medium for realizing inventory management | |
| CN101495976B (en) | Direct-update software transactional memory | |
| US7149736B2 (en) | Maintaining time-sorted aggregation records representing aggregations of values from multiple database records using multiple partitions | |
| EP2550632B1 (en) | System with multiple conditional commit databases | |
| US8473950B2 (en) | Parallel nested transactions | |
| US9767135B2 (en) | Data processing system and method of handling requests | |
| US9928265B2 (en) | Utilizing shared numeric locks | |
| CN110019112B (en) | Data transaction processing method and device and electronic equipment | |
| US6944615B2 (en) | System and method for avoiding deadlock situations due to pseudo-deleted entries | |
| US20090240742A1 (en) | Transaction Log Management | |
| US20190205221A1 (en) | Error handling for services requiring guaranteed ordering of asynchronous operations in a distributed environment | |
| US8666959B2 (en) | Data access device, data access method and data access program | |
| US20090100434A1 (en) | Transaction management | |
| EP3824397A1 (en) | Version-based table locking | |
| US7146385B1 (en) | System and method for application-transparent synchronization with a persistent data store | |
| CN112559496A (en) | Distributed database transaction atomicity realization method and device | |
| CN110866757A (en) | Overdraft prevention method and device for electronic account | |
| US6556994B1 (en) | Method and system for improving concurrency through early release of unnecessary locks | |
| US20080082533A1 (en) | Persistent locks/resources for concurrency control | |
| CN111881149A (en) | Large-scale concurrency solution method and system based on Java | |
| CN113836548B (en) | Data consistency guarantee method, system and equipment of intelligent contract and storage medium | |
| US20240126741A1 (en) | System and method for increased transaction throughput and improved response time under high contention | |
| Kim et al. | Scheduling Nested Transactions on In-Memory Data Grids | |
| CN117291741A (en) | Account data processing method, device, equipment, storage medium and program product |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210618 |
|
| RJ01 | Rejection of invention patent application after publication |