A multi-level inventory management method, device, medium and program product

Abstract

Embodiments of the present application provide a multi-level inventory management method, device, medium and program product, relating to the technical field of inventory management. The method comprises: obtaining an inventory deduction request, including identification information of a target inventory unit, a to-be-deducted quantity and inventory type information; determining a target ordered set corresponding to the target inventory unit from a Redis database according to the inventory type information, the target ordered set storing priority scores corresponding to each inventory sub-unit; selecting inventory sub-units in turn for inventory deduction according to the order from high to low of the priority scores; and generating an inventory change message after the inventory deduction is completed and sending it to a message queue to notify downstream systems of the inventory change message through the message queue. The present application realizes priority management of multi-level inventory through a Redis ordered set, effectively improving the performance of inventory deduction in a high-concurrency scenario, and realizes asynchronous decoupling between systems through a message queue.

Description

Technical Field

[0001] This invention relates to the field of inventory management technology, and in particular to a multi-level inventory management method, apparatus, medium, and program product. Background Technology

[0002] Currently, traditional inventory management systems are typically built on relational databases. Their data models only support single-dimensional total inventory management, failing to meet the flexible differentiation needs of multi-level structures such as public, private, and channel inventory in e-commerce and supply chain scenarios. When business needs to configure the consumption priority of different inventory types differently, traditional systems require independent development of inventory management logic for each business scenario, leading to a significant increase in system complexity.

[0003] Meanwhile, in high-concurrency inventory deduction scenarios, relational databases rely on row-level or table-level locking mechanisms to ensure data consistency. As the number of concurrent requests increases, lock contention rises exponentially, leading to a sharp drop in system throughput and a significant increase in response latency, thus triggering the risk of overselling. During peak traffic scenarios such as flash sales and major promotional events, the database connection pool is easily exhausted, resulting in system-level failures. It is evident that existing technologies suffer from technical problems such as a single dimension of inventory management and insufficient concurrent processing capabilities. Summary of the Invention

[0004] The embodiments of the present invention provide a multi-level inventory management method, apparatus, medium, and program product, which aims to achieve flexible configuration and high-performance deduction of multi-level inventory by introducing a multi-level inventory priority structure based on Redis ordered sets, combined with the high throughput characteristics of in-memory databases and the sorting capabilities of ordered sets, so as to solve the problems of single inventory management dimensions and insufficient processing performance caused by database lock contention in high-concurrency scenarios in the prior art.

[0005] To achieve the above objectives, in a first aspect, the present invention provides a multi-level inventory management method, comprising the following steps: Obtain an inventory deduction request, which includes the identification information of the target inventory unit, the quantity to be deducted, and the inventory type information; Based on the inventory type information, a target ordered set corresponding to the target inventory unit is determined from the Redis database. The target ordered set stores the identification information of multiple inventory sub-units and the priority score corresponding to each inventory sub-unit. The inventory sub-units include inventory from different warehouses and / or different batches. Based on the priority scores from high to low, inventory sub-units are selected from the target ordered set for inventory deduction in turn until all the quantities to be deducted are deducted or all the inventory in the target ordered set is deducted. After the inventory deduction is completed, the inventory data of each inventory sub-unit in the target ordered set is updated, and an inventory change message is generated; The inventory change message is sent to a message queue so that the downstream system is notified of the inventory change message through the message queue.

[0006] Further, the step of selecting inventory sub-units from the target ordered set sequentially according to the priority scores from high to low for inventory deduction includes: Obtain a preset inventory deduction strategy, wherein the inventory deduction strategy includes at least one of a private priority strategy, a public priority strategy, and a hybrid strategy; Inventory sub-units are selected from the target ordered set for inventory deduction according to the priority sorting method indicated by the inventory deduction strategy.

[0007] Furthermore, after obtaining the inventory deduction request, the process also includes: Generate the lock key for the distributed lock based on the identification information of the target inventory unit and the inventory type information; The target inventory unit and the inventory resources corresponding to the inventory type information are locked using a distributed lock; Release the distributed lock after the inventory deduction is completed.

[0008] Further, updating the inventory data of each inventory sub-unit in the target ordered set includes: The inventory deduction operation and the inventory data update operation are executed atomically using Redis Lua scripts.

[0009] Furthermore, it also includes: After the inventory deduction is completed, the order processing status identifier corresponding to the inventory deduction request is recorded in the Redis database; When a duplicate inventory deduction request is received, the system determines whether the order corresponding to the duplicate inventory deduction request has been processed based on the order processing status identifier. If so, ignore the repeated inventory deduction request.

[0010] Furthermore, it also includes: During the inventory deduction process, when the total remaining inventory of the target inventory unit is detected to be lower than a preset threshold, a purchase request message is generated. The procurement request message is sent to the message queue to trigger the procurement service to perform the procurement operation; Receive the inventory write-back message returned by the procurement service after the procurement is completed, and update the inventory data in the Redis database according to the inventory write-back message.

[0011] Furthermore, the inventory type information includes public inventory type and private inventory type, and the key name of the target ordered set is generated according to the identification information of the inventory unit and the inventory type information according to preset rules.

[0012] Secondly, the present invention provides a multi-level inventory management device, including a memory and a processor, wherein the memory stores at least one program, which is executed by the processor to implement the multi-level inventory management method as described above.

[0013] Thirdly, the present invention provides a computer-readable storage medium storing at least one program that is executed by a processor to implement the multi-level inventory management method described above.

[0014] Fourthly, the present invention provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the multi-level inventory management method described above.

[0015] The above technical solution has the following technical effects: First, the above solution uses Redis Sorted Sets (ZSets) to construct a multi-level inventory model. By storing inventory data in memory and representing the consumption order of different inventory sub-units with priority scores of the sorted sets, the inventory deduction operation is completed entirely in memory, avoiding the lock contention overhead caused by database row-level or table-level lock mechanisms in traditional solutions. Compared with existing technologies, this solution can significantly improve the concurrent processing capability of inventory deduction operations, increasing system throughput by several times or even tens of times under the same hardware resource configuration.

[0016] Secondly, the above solution achieves unified modeling and flexible configuration of multi-level inventory structures such as public inventory, private inventory, and channel inventory through the priority score mechanism of ordered sets. When different business lines have different inventory consumption priority requirements, there is no need to develop independent inventory management logic for each business scenario. Strategy switching can be achieved simply by adjusting the priority scores corresponding to each inventory sub-unit in the ordered set, effectively reducing system complexity and maintenance costs. The decoupling design of priority scores and business strategies allows this solution to adapt to the dynamic changes of various business scenarios.

[0017] Finally, the above solution asynchronously notifies downstream systems via a message queue after inventory deduction, thus decoupling the inventory service from external systems such as the order system and data warehouse. The deduction operation and message sending are completed within the same transaction process, ensuring real-time consistency of inventory data and avoiding the accumulation of response latency caused by synchronous calls from downstream systems. Simultaneously, the asynchronous messaging mechanism allows downstream systems to flexibly control their consumption rate based on their processing capabilities, effectively ensuring overall system stability during peak traffic periods.

[0018] It should be noted that the above-described technical effects are only those achievable through some embodiments of the present invention. Those skilled in the art, upon reading this specification, will be able to understand other technical effects brought about by the present invention. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a multi-level inventory management method according to an embodiment of the present invention.

[0020] Figure 2 This is a schematic diagram of the structure of a multi-level inventory management device according to an embodiment of the present invention. Detailed Implementation

[0021] To further illustrate the various embodiments, the present invention provides accompanying drawings. These drawings are part of the disclosure of the present invention, primarily used to illustrate the embodiments and to explain the operating principles of the embodiments in conjunction with the relevant descriptions in the specification. With reference to these drawings, those skilled in the art should be able to understand other possible implementations and the advantages of the present invention. Components in the drawings are not drawn to scale, and similar component symbols are generally used to represent similar components.

[0022] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments.

[0023] Example 1: This invention provides a multi-level inventory management method that can be applied to business scenarios requiring high-concurrency inventory management capabilities, such as e-commerce platforms, supply chain management systems, and instant retail platforms. Figure 1 This is a flowchart illustrating a multi-level inventory management method according to an embodiment of the present invention. See [link / reference] Figure 1 The method includes the following steps: Step S101: Obtain the inventory deduction request.

[0024] The inventory service receives inventory deduction requests from upstream business systems such as the order system and fulfillment system. These requests carry the SKU identifier of the target inventory unit, the quantity to be deducted, and inventory type information. The inventory type indicates the inventory dimension targeted by this deduction operation, such as public or private inventory. Different inventory types correspond to different ZSet keys in Redis. By using the inventory type as a request parameter, the same SKU can support independent management and deduction of multiple inventory dimensions simultaneously, providing a data foundation for subsequent multi-level inventory priority deductions. Optionally, the request may also include an order identifier for subsequent idempotency control.

[0025] Step S102: Based on the inventory type information, determine the target ordered set corresponding to the target inventory unit from the Redis database.

[0026] Based on the inventory type information obtained in step S101, the inventory service determines the target ordered set corresponding to the inventory type from the Redis database. The keys of the ordered set are generated according to preset rules, and its structure is stock:{skuId}:{stockType}. For example, for a product with SKU "10001", the key corresponding to its private inventory is stock:10001:private, and the key corresponding to its public inventory is stock:10001:public.

[0027] This ordered set stores identification information for multiple inventory sub-units and their corresponding priority scores. Inventory sub-units can represent inventory sources from different warehouses or batches. The priority score represents the consumption priority of that sub-unit; a higher score indicates higher priority for consumption. For example, in a private inventory scenario, the warehouse closest to the consumer can be set to the highest priority score, thus implementing the business logic of prioritizing regional shipments. Through the design of the Score field, adjusting inventory priorities only requires modifying the Score value in Redis, without changing the business code. This allows the same inventory management logic to flexibly adapt to the differentiated needs of different business scenarios. Furthermore, since all inventory data is stored in Redis memory, inventory queries and deduction operations do not require access to the disk database, providing an architectural foundation for low-latency responses in high-concurrency scenarios.

[0028] Step S103: Based on the priority scores from high to low, select inventory sub-units from the target ordered set for inventory deduction in turn, until all the quantities to be deducted are deducted or all the inventory in the target ordered set is deducted.

[0029] The inventory service uses Redis's ZREVRANGE command to retrieve all inventory sub-units from the target sorted set in descending order of score, and then iterates through each sub-unit to perform deductions. Specifically, it starts by judging the inventory sub-unit with the highest priority: if the available quantity of the current inventory sub-unit is greater than or equal to the remaining quantity to be deducted, the required quantity is directly deducted from that sub-unit, the deduction is completed, and the iteration ends; if the available quantity of the current inventory sub-unit is less than the remaining quantity to be deducted, all available inventory in that sub-unit is deducted, and the iteration continues to the next priority inventory sub-unit until all quantities to be deducted are deducted or all sub-units have been traversed. If there is still a quantity that has not been deducted after traversing all inventory sub-units, an insufficient inventory message is returned.

[0030] This cyclical deduction mechanism allows a single inventory deduction request to be processed across multiple inventory sub-units, avoiding the failure of the entire deduction request due to insufficient inventory in a single warehouse or batch. For example, if a certain SKU has 5 units in warehouse A and 10 units in warehouse B, and 12 units need to be deducted, the mechanism will automatically deduct 5 units from warehouse A first, then 7 units from warehouse B, ultimately completing the deduction of 12 units without returning an insufficient inventory error. This has significant practical implications in multi-warehouse fulfillment scenarios, significantly improving the overall utilization rate of inventory.

[0031] Step S104: After the inventory deduction is completed, update the inventory data of each inventory sub-unit in the target ordered set and generate an inventory change message.

[0032] Specifically, during the cyclic deduction process in step S103, after each successful deduction of inventory from an inventory sub-unit, the inventory quantity of that sub-unit in the ordered set is immediately updated using the Redis ZINCRBY command, or the sub-unit is removed from the ordered set when the inventory reaches zero. All deduction and update operations are executed atomically using Redis Lua scripts, ensuring that only one deduction operation can modify the inventory data at any given time, thus avoiding data race issues in concurrent scenarios.

[0033] After the inventory deduction is completed and the inventory data is updated, the inventory service constructs an inventory change message. This message includes at least the SKU identifier, change type (e.g., deduction), change quantity, and order identifier. Once the message is constructed, the inventory service sends it to the RocketMQ message queue.

[0034] It's worth noting that inventory data updates and message sending occur within the same business transaction, but the order is: update the cache first, then send the message, rather than synchronously calling downstream systems. This design decouples the local inventory deduction operation from downstream system notifications. Even if message sending temporarily fails, a retry mechanism can compensate, ensuring no impact on the main chain's inventory deduction performance.

[0035] Step S105: Send the inventory change message to the message queue so as to notify the downstream system of the inventory change message through the message queue.

[0036] The inventory service sends the inventory change message constructed in step S104 to the designated Topic in RocketMQ. Downstream systems such as the order system, data warehouse, and fulfillment system subscribe to this Topic to consume the inventory change message and then execute subsequent business processes such as order status updates, data synchronization, and fulfillment scheduling.

[0037] The introduction of the aforementioned message queue completely decouples the inventory service from downstream systems. The inventory service no longer needs to concern itself with how downstream systems handle inventory change results; it only needs to ensure reliable message delivery. Downstream systems can flexibly adjust their consumption rates based on their processing capabilities, avoiding being overwhelmed by sudden inventory deduction requests during peak traffic periods. Furthermore, when a new downstream system needs to receive inventory change notifications, it only needs to subscribe to the same Topic, requiring no code modifications to the inventory service, significantly improving system scalability.

[0038] Thus, combining steps S101 to S105 above, this embodiment of the invention completes the multi-level inventory deduction main process based on Redis ordered sets. In a preferred embodiment, the above scheme also includes enhanced mechanisms such as distributed lock control, idempotent control, and automatic procurement triggering, which will be described below.

[0039] Regarding distributed lock control, after obtaining the inventory deduction request in step S101, the inventory service generates a distributed lock key `stock_lock:{skuId}:{stockType}` based on the target SKU identifier and inventory type, and performs a locking operation on this key through the Redisson client. Only after successful locking is subsequent inventory query and deduction operations allowed. After the deduction operation in step S103 is completed and the inventory data is updated, the inventory service releases the distributed lock. This distributed lock mechanism ensures that multiple concurrent deduction requests for the same SKU under the same inventory type are processed serially, effectively preventing overselling in concurrent scenarios. The locking granularity is precise down to the SKU and inventory type level; deduction operations between different SKUs or different inventory types do not affect each other, maximizing system concurrency while ensuring data consistency.

[0040] Regarding atomic operations, the update of inventory data for each inventory sub-unit in the target ordered set in step S104 is executed atomically using a Redis Lua script. Specifically, the inventory service encapsulates the entire cyclic deduction logic into a Lua script. This script completes all operations on the Redis server at once: reading the current inventory of each inventory sub-unit in the ZSet, comparing the available inventory with the quantity to be deducted, performing the deduction and updating the ZSet, and returning the deduction result. Since the Lua script is executed atomically in Redis, it will not be interrupted by operations from other clients. Therefore, even under extremely high concurrency requests, the inventory deduction result is accurate, with no intermediate states. This further strengthens the system's data consistency guarantee. Compared with traditional solutions that execute data reading and writing in two separate network requests, the atomic design of this embodiment ensures accuracy while reducing the number of network round trips and improving overall throughput.

[0041] Regarding idempotency control, to prevent duplicate consumption of the message queue from causing duplicate inventory deductions, this embodiment of the invention records the order processing status in the Redis database. Specifically, after the inventory deduction in step S104 is completed, the inventory service writes a status identifier in Redis with the key `order_status:{orderId}` and the value `processed`. When the inventory service receives an inventory change message from the message queue, it first checks whether a corresponding status identifier already exists for the order identifier: if it exists, it means the order has been processed, the current message is a duplicate message, and it is ignored without further deduction; if it does not exist, the normal deduction process is executed, and the status identifier is written after the deduction is completed. Through the above idempotency control mechanism, even if a retrieval or duplicate delivery occurs in the message queue, the inventory corresponding to each order will only be deducted once, effectively ensuring the eventual consistency between inventory data and order data.

[0042] Regarding automatic procurement triggering, this embodiment of the invention monitors the total remaining inventory of the target SKU in real time during the inventory deduction process. Specifically, during the cyclic deduction process in step S103, the inventory service simultaneously calculates the total remaining inventory of the SKU under the current inventory type each time it updates the inventory data of the inventory sub-unit. When the total remaining inventory is detected to be lower than a preset threshold, the inventory service automatically constructs a procurement request message, which includes information such as the SKU identifier, current inventory level, preset replenishment threshold, and suggested replenishment quantity, and sends the message to the procurement Topic in RocketMQ. The procurement service receives the procurement request message by subscribing to the Topic and asynchronously executes procurement logic such as generating purchase orders and notifying suppliers. After completing the procurement operation, the procurement service generates an inventory write-back message and sends it to the Topic subscribed to by the inventory service. Upon receiving the write-back message, the inventory service updates the inventory data of the corresponding ordered set in Redis according to the SKU identifier, the quantity procured, and the target inventory type in the message. The above-mentioned automatic procurement triggering mechanism realizes a closed-loop automation of the entire chain from inventory shortage detection to procurement and warehousing, avoiding stockout losses caused by relying on manual monitoring and manual replenishment in traditional solutions.

[0043] Based on the core methods described above, the embodiments of the present invention can be further extended according to actual business needs without departing from the core ideas of the present invention. Several preferred extended implementation methods will be described below.

[0044] Regarding the expansion of hot and cold inventory tiers, considering that not all inventory data requires extremely high read / write performance, this embodiment of the invention can store inventory data in tiers according to access frequency. Specifically, hot inventory data with frequent deduction operations, such as best-selling products and products currently on promotion, is stored in Redis, enjoying the high throughput performance of an in-memory database; cold inventory data with low access frequency, such as long-tail products and seasonal products, is stored in a relational database. When the inventory service receives a deduction request, it first determines whether the SKU is a hot inventory identifier. If so, it reads directly from Redis and deducts; otherwise, it reads from the database and deducts. Optionally, the division of hot and cold inventory can be dynamic. The system can count the deduction frequency of each SKU over a period of time. When the access frequency of a cold inventory SKU suddenly increases, it is automatically loaded from the database to Redis and marked as hot inventory; when the access frequency of a hot inventory SKU drops below a threshold, it is removed from Redis and persisted to the database. Through the above hot and cold tier scheme, high-performance deduction of popular products can be guaranteed while reducing the memory resource consumption of Redis, achieving a balance between performance and cost.

[0045] Regarding the expansion of the inventory pre-holding mechanism, this embodiment of the invention supports the ability to pre-hold inventory upon order placement. Specifically, when a user submits an order, the inventory service does not immediately perform a permanent deduction, but first performs an inventory pre-holding operation. In Redis, the quantity of pre-held inventory and the pre-holding timestamp are recorded through a separate pre-holding ZSet or by adding a pre-holding flag to an existing ZSet. The pre-holding operation temporarily deducts inventory from the available-for-sale inventory to prevent it from being consumed by other orders. Simultaneously, the system sets a validity period, such as 15 minutes, for each pre-holding operation. If the user completes payment within the validity period, the inventory service converts the pre-held inventory to a permanent deduction and sends an inventory change message to notify downstream systems; if the pre-holding validity period expires before the user completes payment, the inventory service automatically releases the pre-held inventory and restores it to the available-for-sale inventory. This pre-holding mechanism, by setting a validity period, achieves automatic inventory recovery, avoiding the problem of long-term inventory lock-up caused by users not paying after placing an order, and improving inventory turnover efficiency.

[0046] Regarding multi-dimensional inventory splitting and expansion, this invention supports more granular inventory management by channel and region. For channel-based splitting, independent inventory ZSets can be maintained for the same SKU on both the app and physical store platforms, with corresponding key names `stock:{skuId}:app` and `stock:{skuId}:store`, respectively. Inventory deductions for different channels are independent and do not affect each other. For region-based splitting, independent inventory ZSets can be maintained for the same SKU in different cities or warehouses, with key names `stock:{skuId}:{city}` and `stock:{skuId}:{warehouse}`, respectively. Through this multi-dimensional inventory splitting, businesses can develop differentiated inventory strategies for different channels and regions. For example, when inventory is tight, inventory can be prioritized for channels with higher conversion rates, or delivery can be made based on proximity to the region to reduce logistics costs. It should be noted that channels and regions are merely exemplary dimensions; those skilled in the art can expand to more dimensions based on actual business needs, all of which fall within the scope of this invention.

[0047] Regarding inventory forecasting and intelligent replenishment, this invention further introduces predictive capabilities based on the aforementioned automatic procurement triggering mechanism. Specifically, the system collects and stores historical consumption data for each SKU, such as daily sales volume and hourly order volume, and uses time series analysis algorithms, such as moving average and exponential smoothing, to predict inventory consumption trends over a future period. Based on the prediction results, the system triggers the procurement process in advance before inventory reaches a preset threshold, rather than waiting until inventory is insufficient. For example, if the system predicts that 100 units of a certain SKU will be consumed in the next 3 days, and the current remaining inventory is only 120 units, the system automatically generates a procurement request message, triggering the procurement service to prepare inventory in advance, avoiding stockouts during promotional activities. This intelligent replenishment mechanism upgrades procurement triggering from passive response to proactive prediction, further reducing the risk of stockouts.

[0048] Regarding the extension of gray-scale strategy switching, this embodiment of the invention supports different inventory deduction strategies for different business lines. Specifically, the inventory deduction request carries a business line identifier (bizLine), and the inventory service routes to the corresponding strategy configuration based on this identifier. Strategy configuration items include, but are not limited to: prioritizing the use of private or public inventory, allowing cross-inventory borrowing when deduction fails, and automatically triggering procurement when inventory is insufficient. The strategy configuration of each business line can be adjusted independently, and the adjustment takes effect in real time without restarting the service or redeploying the code. Through the above-mentioned gray-scale strategy switching mechanism, different business lines, such as self-operated business and platform business, and regular sales and flash sale activities, can independently configure differentiated inventory management strategies on the same inventory system, which not only meets the diversified needs of the business but also avoids the need to repeatedly develop inventory management logic for each business line.

[0049] Regarding multi-replica inventory disaster recovery and expansion, this embodiment of the invention supports Redis master-slave replication and cluster deployment modes. Specifically, the Redis database adopts a master-slave architecture. The master node is responsible for handling write requests, such as inventory deduction and inventory write-back, while one or more slave nodes synchronize data with the master node in real time and are responsible for handling read requests. When the master node fails, the system automatically promotes a slave node to the new master node through a sentinel mechanism or cluster election mechanism to continue providing services, achieving automatic failover and avoiding inventory service unavailability caused by a single point of failure. For cluster deployment, a Redis Cluster mode can be used, where inventory data for different SKUs is sharded and stored across multiple master nodes, with each master node corresponding to multiple slave nodes, further improving system availability and disaster recovery capabilities.

[0050] In the above embodiments, the inventory type information includes public inventory type and private inventory type. The key name of the target ordered set is generated according to the identification information of the inventory unit and the inventory type information according to preset rules. Those skilled in the art will understand that public inventory and private inventory are merely exemplary ways of classifying inventory types. In other embodiments, inventory types may also include channel inventory, promotional inventory, pre-sale inventory, and other dimensions, all of which fall within the protection scope of this invention.

[0051] In summary, the embodiments of the present invention, through the inventory deduction method described in steps S101 to S105 above, and the enhancement mechanisms such as distributed lock control, idempotent control, and automatic procurement triggering, combined with various extended implementation methods, achieve high-performance, highly reliable, and scalable multi-level inventory management.

[0052] Example 2: Figure 2 This is a schematic diagram of the structure of a multi-level inventory management device according to an embodiment of the present invention, as shown below. Figure 2 As shown, the device includes a processor 201, a memory 202, a bus 203, and a computer program stored in the memory 202 and executable on the processor 201. The processor 201 includes one or more processing cores. The memory 202 is connected to the processor 201 via the bus 203. The memory 202 is used to store program instructions. When the processor executes the computer program, it implements the steps in the above-described method embodiment of Embodiment 1 of the present invention.

[0053] Furthermore, as an executable solution, the multi-level inventory management device can be a computer unit, which can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer unit may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the above-described structure of the computer unit is merely an example and does not constitute a limitation on the computer unit. It may include more or fewer components, or combine certain components, or use different components. For example, the computer unit may also include input / output devices, network access devices, buses, etc., and this embodiment of the invention does not limit this.

[0054] Furthermore, as an executable solution, the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. The processor is the control center of the computer unit, connecting various parts of the entire computer unit via various interfaces and lines.

[0055] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the computer unit by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory may include high-speed random access memory and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, SmartMediaCard (SMC), Secure Digital (SD) card, FlashCard, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0056] Example 3: The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described in the embodiments of the present invention.

[0057] If the modules / units integrated in the computer unit are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), and software distribution media, etc. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction.

[0058] Example 4: The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the multi-level inventory management method described above.

[0059] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A multi-level inventory management method, characterized in that, Includes the following steps: Obtain an inventory deduction request, which includes the identification information of the target inventory unit, the quantity to be deducted, and the inventory type information; Based on the inventory type information, a target ordered set corresponding to the target inventory unit is determined from the Redis database. The target ordered set stores the identification information of multiple inventory sub-units and the priority score corresponding to each inventory sub-unit. The inventory sub-units include inventory from different warehouses and / or different batches. Based on the priority scores from high to low, inventory sub-units are selected from the target ordered set for inventory deduction in turn until all the quantities to be deducted are deducted or all the inventory in the target ordered set is deducted. After the inventory deduction is completed, the inventory data of each inventory sub-unit in the target ordered set is updated, and an inventory change message is generated; The inventory change message is sent to a message queue so that the downstream system is notified of the inventory change message through the message queue.

2. The multi-level inventory management method according to claim 1, characterized in that, The step of selecting inventory sub-units from the target ordered set sequentially according to the priority scores from high to low for inventory deduction includes: Obtain a preset inventory deduction strategy, wherein the inventory deduction strategy includes at least one of a private priority strategy, a public priority strategy, and a hybrid strategy; Inventory sub-units are selected from the target ordered set for inventory deduction according to the priority sorting method indicated by the inventory deduction strategy.

3. The multi-level inventory management method according to claim 1, characterized in that, Following the receipt of the inventory deduction request, the following is also included: Generate the lock key for the distributed lock based on the identification information of the target inventory unit and the inventory type information; The target inventory unit and the inventory resources corresponding to the inventory type information are locked using a distributed lock; Release the distributed lock after the inventory deduction is completed.

4. The multi-level inventory management method according to claim 1, characterized in that, Updating the inventory data of each inventory sub-unit in the target ordered set includes: The inventory deduction operation and the inventory data update operation are executed atomically using Redis Lua scripts.

5. The multi-level inventory management method according to claim 1, characterized in that, Also includes: After the inventory deduction is completed, the order processing status identifier corresponding to the inventory deduction request is recorded in the Redis database; When a duplicate inventory deduction request is received, the system determines whether the order corresponding to the duplicate inventory deduction request has been processed based on the order processing status identifier. If so, ignore the repeated inventory deduction request.

6. The multi-level inventory management method according to claim 1, characterized in that, Also includes: During the inventory deduction process, when the total remaining inventory of the target inventory unit is detected to be lower than a preset threshold, a purchase request message is generated. The procurement request message is sent to the message queue to trigger the procurement service to perform the procurement operation; Receive the inventory write-back message returned by the procurement service after the procurement is completed, and update the inventory data in the Redis database according to the inventory write-back message.

7. The multi-level inventory management method according to claim 1, characterized in that, The inventory type information includes public inventory type and private inventory type, and the key name of the target ordered set is generated according to the identification information of the inventory unit and the inventory type information according to preset rules.

8. A multi-level inventory management device, characterized in that, The system includes a memory and a processor, the memory storing at least one program, which is executed by the processor to implement the multi-level inventory management method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The storage medium stores at least one program, which is executed by a processor to implement the multi-level inventory management method as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the multi-level inventory management method as described in any one of claims 1-7.

Images