A commodity order payment method, system, device and storage medium

Abstract

The application discloses a commodity order payment method, system, equipment and storage medium. The method comprises the following steps: obtaining a commodity order request of a user through a commodity purchase page; generating a commodity order corresponding to the order request through a distributed lock operation, and storing the commodity order in a database; initiating a payment page based on the commodity order in the database, so that the user pays for the commodity order; and sending the commodity order after payment to a background system. Through the technical scheme of the application, the uniqueness of the inventory deduction process can be controlled based on the distributed lock mode, the occurrence of the overselling phenomenon in the traditional seconds scene is effectively avoided, and the consistency between the actual order quantity and the inventory deduction quantity in the seconds is ensured.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of Internet technology, and in particular to a method, system, device and storage medium for placing and paying for goods. Background Technology

[0002] With the rapid development of the e-commerce industry chain, people's consumption habits are increasingly shifting towards purchasing through online shopping malls. To boost customer purchasing desire, major e-commerce platforms have launched limited-time flash sales.

[0003] However, flash sales often put pressure on existing personal e-commerce systems because traditional order placement and payment operations are usually based on databases, which have poor disk I / O performance and cannot meet the high-concurrency demands of flash sales. Traditional flash sale orders often result in overselling under high concurrency, requiring a cumbersome process of later balancing sales and inventory through a stock leveling program. Summary of the Invention

[0004] This invention provides a product order payment method, system, device, and storage medium to achieve the uniqueness of the inventory deduction process through distributed locks, effectively avoiding overselling in traditional flash sale scenarios and ensuring that the actual order quantity in the flash sale is consistent with the inventory deduction quantity.

[0005] In a first aspect, embodiments of the present invention provide a method for placing and paying for goods orders, the method comprising:

[0006] Obtain user order requests for products through the product purchase page;

[0007] The product order corresponding to the order request is generated through distributed lock operation, and the product order is stored in the database;

[0008] A payment page is initiated based on the product orders in the database, allowing the user to pay for the product orders;

[0009] Send the completed payment for the product order to the back-end system.

[0010] Secondly, embodiments of the present invention also provide a product order payment system, the system comprising:

[0011] The order request module is used to obtain users' order requests for products through the product purchase page;

[0012] The product order module is used to generate the product order corresponding to the order request through distributed lock operation, and store the product order in the database;

[0013] The order payment module is used to initiate a payment page based on the product orders in the database, so that users can pay for the product orders;

[0014] The order push module is used to send completed payment orders to the backend system.

[0015] Thirdly, embodiments of the present invention also provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the product order payment method as described in any of the embodiments of the present invention.

[0016] Fourthly, embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the product order payment method as described in any of the embodiments of the present invention.

[0017] This invention obtains user order requests for products through the product purchase page; generates product orders corresponding to the order requests through distributed lock operations and stores the product orders in the database; initiates a payment page based on the product orders in the database for users to pay for the product orders; and sends the completed product orders to the backend system. This method can control the uniqueness of the inventory deduction process through distributed locks, effectively avoiding overselling in traditional flash sale scenarios and ensuring that the actual order quantity in the flash sale remains consistent with the inventory deduction quantity. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1A This is a flowchart of a product order payment method according to Embodiment 1 of the present invention;

[0020] Figure 1B This is a structural diagram of the order payment system and the back-end system;

[0021] Figure 2A This is a flowchart of a product order payment method according to Embodiment 2 of the present invention;

[0022] Figure 2B This is a schematic diagram of distributed lock operations;

[0023] Figure 2C This is a schematic diagram of the inventory allocation plan;

[0024] Figure 3 This is a schematic diagram of the structure of a commodity order payment system according to Embodiment 3 of the present invention;

[0025] Figure 4 This is a schematic diagram of the structure of a terminal device according to Embodiment 4 of the present invention. Detailed Implementation

[0026] The present invention will now be described in further detail 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 not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0027] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this invention, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0028] Example 1

[0029] Figure 1A This is a flowchart of a product order payment method provided in Embodiment 1 of the present invention. This embodiment is applicable to the situation of ordering and paying for flash sale products. This method can be executed by the product order payment system in this embodiment of the present invention, which can be implemented in software and / or hardware, such as... Figure 1A As shown, the method specifically includes the following steps:

[0030] S110 obtains the user's order request for the product through the product purchase page.

[0031] The product purchase page is displayed in the product order payment system. The product purchase page displays product information, which may include: product description, product inventory quantity, order entry, purchase time or countdown, etc.

[0032] Specifically, users log into their accounts in the product ordering and payment system, select the quantity of products to order on the product purchase page, and send an order request. The order request can include: the quantity of products to order and a user identifier; the user identifier is used to uniquely identify the user, such as a user ID or user nickname.

[0033] S120 generates the product order corresponding to the order request through distributed lock operation and stores the product order in the database.

[0034] Distributed lock operations are a way to control synchronized access to shared resources between distributed systems. Distributed lock operations ensure that in a distributed environment, a transaction can only be executed by one thread at a time.

[0035] Specifically, based on a user's order request, a distributed operation sends a lock request to the product inventory. While locked, the inventory is reduced based on the order quantity, and a product order is generated and stored in the database. Other users can only resend a lock request to the product inventory to reduce their inventory after the product inventory releases the lock. For example, the distributed lock operation can be implemented using a cache, such as Redis, or it can be implemented using a database.

[0036] Traditional order placement and payment methods often result in discrepancies between actual sales and actual inventory deductions under high concurrency due to thread preemption and conflicts. This invention addresses this by using a distributed lock to control the uniqueness of the inventory deduction process, effectively preventing overselling in traditional flash sale scenarios and ensuring consistency between the actual order quantity and the inventory deduction quantity.

[0037] Order generation and order storage are handled asynchronously. After order generation, a Redis cached List queue stores the orders, using a unique user identifier (HashTag) to ensure even distribution of order information. The order storage operation is implemented using multi-threading, with configurable parameters to dynamically adjust the storage rate. This ensures rapid storage completion while maintaining a stable backend system, typically achieving sub-second-level storage.

[0038] S130: Initiate a payment page based on the product orders in the database, allowing users to pay for their product orders.

[0039] Specifically, to ensure a smooth user experience from order placement to payment, while avoiding excessive reliance on database performance that could lead to slow payments and a poor user experience, the generation of product orders and their entry into the database are asynchronously split. Only product orders stored in the database can trigger the payment page, thus smoothing out peak write operations. By transitioning from a cached database to a traditional database, the order placement and payment processes can be seamlessly integrated, enhancing the user experience.

[0040] S140 sends the completed payment for the product order to the back-end system.

[0041] The backend system refers to the e-commerce platform or online store that provides functions such as product listing and delisting approval and order after-sales service. It is used to push product information to the order payment system and receive product orders sent by the order payment system. Traditional backend systems cannot meet the needs of flash sale scenarios. Most existing technologies are based on upgrading and modifying the backend system to implement the flash sale function itself. This implementation model is costly and prone to conflicts with existing functions of the source system, making modification and implementation difficult.

[0042] Specifically, such as Figure 1B As shown, the backend system provides services such as product listing, product review, creation of flash sale activities, viewing product orders, and order after-sales service. The product ordering and payment system receives user profile information pushed by the backend system and provides functions such as product display, product ordering, inventory deduction, and order payment. It sends completed product orders to the backend system, ensuring the data integrity and process integrity of the backend system.

[0043] This product ordering and payment system is presented as an embedded H5 page and can be flexibly configured and integrated into the backend system via a web URL. Furthermore, the system utilizes open-source components, making deployment simple and convenient for integration with various e-commerce platforms. The system also provides backend system integration functionality, ensuring administrators remain familiar with their existing backend systems.

[0044] For example, a Kafka message queue is used to send completed payment orders to the backend system. A subscription-consumption model is employed; after payment, orders are synchronously sent to the message queue for consumption. Consumers periodically pull order information from the message queue and push it to the backend system. To prevent order data loss, two compensation mechanisms are provided: an active compensation mechanism that re-pushes three times after a failed push, and a passive compensation mechanism that provides a query interface to the backend system. Furthermore, push traffic can be controlled by adjusting subscription configuration parameters to ensure that push traffic does not exceed the source system's safety threshold.

[0045] The product ordering and payment system provided in this embodiment of the invention integrates with the backend system. Product listing, delisting, and approval operations remain consistent with the existing backend system's operational habits. The backend system only needs to add a flash sale creation function and a new flash sale activity, pushing the activity information and participating product information to the product ordering and payment system. The product ordering and payment system primarily addresses high-concurrency flash sale ordering. It conducts flash sale activities using product information pushed from the backend system. After completing processes such as product ordering, inventory deduction, and payment order processing, it proactively pushes the completed product order to the backend system. This ensures the data and process integrity of the backend system. Subsequent order after-sales issues can utilize existing backend system functions. Compared to adding a flash sale function to the backend system, integrating the product ordering and payment system to add a flash sale function is much easier to implement.

[0046] The technical solution of this embodiment obtains the user's order request for the product through the product purchase page; generates the product order corresponding to the order request through distributed lock operation, and stores the product order in the database; initiates a payment page based on the product order in the database for the user to pay for the product order; and sends the completed product order to the backend system. This solution can control the uniqueness of the inventory deduction process through distributed lock, effectively avoiding the overselling phenomenon in traditional flash sale scenarios and ensuring that the actual order quantity in the flash sale is consistent with the inventory deduction quantity.

[0047] Optionally, after initiating the payment page based on the product order in the database, the following may also be included:

[0048] The product orders are sent to the delayed queue and stored according to the product order generation time;

[0049] Scan the payment status of product orders in the delayed queue;

[0050] If an expired and unpaid order is detected, the expired and unpaid order will be cancelled.

[0051] Specifically, to prevent users from maliciously grabbing orders, a delayed queue based on Redis zset is set up to implement an automatic cancellation mechanism for unpaid orders that have timed out. Orders are sent to the delayed queue, and the payment status of orders in the queue is scanned based on their creation time. If an expired unpaid order is detected, it is cancelled.

[0052] For example, based on the number of milliseconds when a user places an order, 200 zset queues are created. Every 200 milliseconds, the 200 zset queues are scanned to identify expired orders and call the order cancellation interface to cancel expired and unpaid product orders.

[0053] Example 2

[0054] Figure 2A This is a flowchart of a product order payment method according to Embodiment 2 of the present invention. This embodiment is an optimization based on the above embodiment. In this embodiment, the step of generating the product order corresponding to the order request through distributed lock operation includes: sending a lock request to the product inventory; receiving a lock response sent by the product inventory; under the locked state of the product inventory, performing an operation to deduct inventory based on the order request and generating an order; and sending a lock release request to the product inventory to release the locked state of the product inventory.

[0055] like Figure 2A As shown, the method in this embodiment specifically includes the following steps:

[0056] S210 obtains the user's order request for the product through the product purchase page.

[0057] S220, send a lock request to the product inventory.

[0058] The lock request is used to request that the product inventory be locked. Product inventory represents the available quantity of the product.

[0059] Specifically, multiple users can send lock requests to the product inventory at the same time, but only one user's order request can be locked at any given time.

[0060] S230: Receive the locking response from the product inventory. While the product inventory is locked, perform the operation of deducting inventory based on the order request and generate an order.

[0061] When the product inventory is locked, only order requests that have responded to the lock request can execute the operation of deducting inventory and generating an order based on the order request. Other users need to send a lock request to the product inventory again after the product inventory is released and wait for a response before they can generate a product order and deduct inventory.

[0062] Specifically, the system receives a locking response from the product inventory after receiving a locking request. At this point, the product inventory is in a locked state. Based on the order quantity contained in the responded order request, the product inventory is deducted, and a product order is generated based on the order request. This ensures the uniqueness of the inventory deduction process, effectively avoiding overselling in traditional flash sale scenarios and ensuring that the actual order quantity in the flash sale matches the inventory deduction quantity.

[0063] S240, send a lock release request to the inventory to release the locked state of the inventory.

[0064] Specifically, after performing the inventory deduction operation, a lock release request is sent to the product inventory, so that the product inventory releases its locked state based on the lock release request, thereby allowing other users to send lock requests to the product inventory to perform inventory deduction operations and generate product orders.

[0065] S250: Initiate a payment page based on the product orders in the database, allowing users to pay for their product orders.

[0066] S260 sends the completed payment for the product order to the back-end system.

[0067] The technical solution of this embodiment obtains the user's order request for the product through the product purchase page; sends a locking request to the product inventory; receives the locking response from the product inventory; while the product inventory is locked, performs an inventory deduction operation based on the order request and generates an order; sends a lock release request to the product inventory to release the locked state of the product inventory; initiates a payment page based on the product order in the database for the user to pay for the product order; and sends the completed product order to the backend system. This solution can control the uniqueness of the inventory deduction process through a distributed lock, effectively avoiding the overselling phenomenon in traditional flash sale scenarios and ensuring that the actual order quantity in the flash sale is consistent with the inventory deduction quantity.

[0068] Optional, also includes:

[0069] If no lock response is received from the product inventory, wait for the lock status of the product inventory to be released, and then return to execute the operation of sending a lock request to the product inventory until a lock response is received or the duration of not receiving a lock response exceeds a first preset time.

[0070] If the duration of the period without receiving a lock response exceeds the first preset time, an order failure message will be sent to the product purchase page.

[0071] Specifically, if no lock response is received after sending a lock request, it means that the product inventory has already responded to other users' lock requests. It needs to wait for other users to deduct inventory based on their orders and release the locked state of the product inventory, then resend the lock request to the product inventory until a lock response is received, or the duration of no lock response exceeds a first preset time. If a lock response is received from the product inventory, the inventory is deducted based on the order request, and an order is generated. If no lock response is received for more than the first preset time, it means the lock request has not been responded to for an extended period, and the order has failed. An order failure message is sent to the product purchase page, prompting the user that the order has failed or they should reorder.

[0072] For example, Figure 2B This is a diagram illustrating distributed lock operations, such as... Figure 2BAs shown, users A and B simultaneously send lock requests to the product inventory. If a user's lock request is responded to, the inventory is deducted based on user A's order request, a product order is generated, and the locked state of the product inventory is released. Since user A's lock request is responded to, user B's lock request will not be responded to. User B must wait for the locked state of the product inventory to be released before returning to send a lock request to the product inventory. This process continues until user B receives a lock response. Then, the inventory is deducted based on user B's order request, and a product order is generated. Alternatively, if user B does not receive a lock response for more than a first preset time, user B will no longer wait to send a lock request, indicating that user B's order request has failed.

[0073] Traditional database-based ordering and payment methods, due to their low disk I / O performance, cannot adequately meet the needs of high-concurrency flash sale scenarios. This invention employs Redis caching technology to implement order placement and inventory deduction operations, maximizing the performance of flash sale ordering. Furthermore, traditional ordering and payment methods often suffer from discrepancies between actual sales and actual inventory deductions under high concurrency due to thread preemption and conflicts. This invention uses Lua scripts and Redis distributed locks to achieve atomic transactions from inventory verification to inventory deduction. By controlling the uniqueness of the inventory deduction process through distributed locks, it effectively avoids overselling in traditional flash sale scenarios, ensuring consistency between the actual order quantity and the inventory deduction quantity. The use of Redis distributed locks supports distributed deployment and concurrent operations, effectively guaranteeing the fairness and continuity of the flash sale system.

[0074] Optionally, the order request may include: user identification information and the quantity of goods ordered.

[0075] Optionally, based on the order request, perform an operation to deduct inventory and generate an order, including:

[0076] The first target virtual inventory is randomly allocated based on user identification information; the product inventory is grouped into multiple virtual inventories; the first target virtual inventory is one of the multiple virtual inventories.

[0077] If the quantity of the first target virtual inventory is greater than or equal to the quantity of the product ordered, a product order is generated, and the quantity of the first target virtual inventory is deducted based on the quantity of the product ordered.

[0078] If the quantity of the first target virtual inventory is less than the quantity of the product ordered, then at least one second target virtual inventory is allocated to the user, and the sum of the quantities of the first target virtual inventory and the second target virtual inventory is determined as the quantity of the target virtual inventory.

[0079] If the quantity of the target virtual inventory is greater than or equal to the quantity of the product order, a product order is generated, and the quantity of the first target virtual inventory and the quantity of the second target inventory are deducted based on the quantity of the product order.

[0080] The initial product inventory can be grouped into multiple virtual inventories through parameter configuration. The quantity of virtual inventories obtained from the grouping can be set according to needs, and this embodiment of the invention does not impose any limitation.

[0081] Specifically, when grouping multiple virtual inventories, Redis's HashTag feature is used to distribute product inventory information evenly across the nodes of the Redis cluster. This ensures that virtual inventory information is evenly stored in the cache cluster, guaranteeing overall server performance and avoiding Redis hot key issues in high-concurrency order scenarios. When a user sends an order request, an inventory deduction algorithm randomly assigns the request to a specific target virtual inventory node, ensuring the randomness of user order placement and inventory deduction, and guaranteeing fairness in the user's flash sale behavior. If the target virtual inventory is less than the product order quantity, a dynamic database allocation algorithm is used to reallocate the virtual inventory and generate a product order.

[0082] For example, Figure 2C This is a schematic diagram of the inventory allocation plan, such as... Figure 2C As shown, the inventory deduction algorithm randomly allocates a first target virtual inventory from multiple virtual inventories based on the user's identification information. It then determines whether the quantity of the first inventory is greater than or equal to the order quantity. If so, the quantity of the first target virtual inventory is deducted based on the order quantity, and an order is generated based on the order request. If not, a second target virtual inventory is allocated to the user, and the sum of the quantities of the first and second target virtual inventories is determined as the target virtual inventory quantity. If the target virtual inventory quantity is greater than or equal to the order quantity, an order is generated, and the target virtual inventory quantity is deducted based on the order quantity. If the target virtual inventory quantity is still less than the order quantity, new second target virtual inventory is allocated to the user, and the sum of the first and second target virtual inventories allocated to the user is updated as the target virtual inventory quantity. The process continues to determine whether the target virtual inventory quantity is greater than or equal to the order quantity until the target virtual inventory quantity is greater than or equal to the order quantity, or until the second target virtual inventory is the last available virtual inventory.

[0083] Optional, also includes:

[0084] If the quantity of the target virtual inventory is less than the quantity of the product ordered, and the second target virtual inventory is the last available virtual inventory, then an insufficient inventory prompt is sent to the product purchase page.

[0085] Specifically, if the quantity of the target virtual inventory is less than the quantity of the product to be ordered, and the second target virtual inventory is the last available virtual inventory, meaning that the total remaining quantity of the product inventory does not meet the order quantity, then an insufficient inventory prompt will be sent to the product purchase page, and the order will fail.

[0086] Example 3

[0087] Figure 3 This is a schematic diagram of a product order payment system provided in Embodiment 3 of the present invention. This embodiment is applicable to situations involving order payment for flash sale items. The system can be implemented using software and / or hardware, and can be integrated into any device that provides product order payment functionality, such as… Figure 3 As shown, the product order payment system specifically includes: an order request module 310, a product order module 320, an order payment module 330, and an order push module 340.

[0088] Among them, the order request module 310 is used to obtain the user's order request for the product through the product purchase page;

[0089] The product order module 320 is used to generate the product order corresponding to the order request through distributed lock operation, and store the product order in the database;

[0090] The order payment module 330 is used to initiate a payment page based on the product orders in the database, so that the user can pay for the product orders;

[0091] The order push module 340 is used to send completed payment orders to the backend system.

[0092] Optional, the product order module 320 includes:

[0093] The lock request unit is used to send a lock request to the product inventory.

[0094] The inventory deduction unit is used to receive the locking response sent by the product inventory, and under the locked state of the product inventory, to perform the inventory deduction operation based on the order request and generate an order;

[0095] The lock release unit is used to send a lock release request to the product inventory so that the product inventory is released from the locked state.

[0096] Optionally, the product order module 320 further includes:

[0097] The waiting unit is configured to wait for the locked state of the product inventory to be released if no locking response is received, and then return to the operation of sending a locking request to the product inventory until the locking response is received or the duration of not receiving the locking response exceeds a first preset time.

[0098] The notification unit is used to send an order failure notification message to the product purchase page if the duration of not receiving the locking response exceeds a first preset time.

[0099] Optionally, the order request includes: user identification information and the quantity of goods ordered; correspondingly, the inventory deduction unit is specifically used for:

[0100] A first target virtual inventory is randomly allocated based on the user identification information; the product inventory is grouped into multiple virtual inventories; the first target virtual inventory is one of the multiple virtual inventories.

[0101] If the quantity of the first target virtual inventory is greater than or equal to the quantity of the product ordered, a product order is generated, and the quantity of the first target virtual inventory is deducted based on the quantity of the product ordered.

[0102] If the quantity of the first target virtual inventory is less than the quantity of the product ordered, then at least one second target virtual inventory is allocated to the user, and the sum of the quantities of the first target virtual inventory and the second target virtual inventory is determined as the quantity of the target virtual inventory.

[0103] If the quantity of the target virtual inventory is greater than or equal to the quantity of the product order, then the quantity of the first target virtual inventory and the quantity of the second target inventory are deducted from the quantity of the product order, and a product order is generated.

[0104] Optionally, the inventory deduction unit is further configured to:

[0105] If the quantity of the target virtual inventory is less than the quantity of the product ordered, and the second target virtual inventory is the last available virtual inventory, then an insufficient inventory prompt is sent to the product purchase page.

[0106] Optionally, the product order payment system is accessed through a web page URL to the backend system.

[0107] The above-described products can perform the methods provided in any embodiment of the present invention, and have the corresponding functional modules and beneficial effects for performing the methods.

[0108] Example 4

[0109] Figure 4 This is a structural block diagram of a terminal device provided in Embodiment 4 of the present invention, as shown below. Figure 4 As shown, the terminal device includes a processor 410, a memory 420, an input device 430, and an output device 440; the number of processors 410 in the terminal device can be one or more. Figure 4Taking a processor 410 as an example; the processor 410, memory 420, input device 430, and output device 440 in the terminal device can be connected via a bus or other means. Figure 4 Taking the example of a connection between China and Israel via a bus.

[0110] The memory 420, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the product order payment method in this embodiment of the invention (e.g., the order request module 310, product order module 320, order payment module 330, and order push module 340 in the product order payment system). The processor 410 executes various functional applications and data processing of the terminal device by running the software programs, instructions, and modules stored in the memory 420, thereby implementing the aforementioned product order payment method.

[0111] The memory 420 may primarily 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 given function; the data storage area may store data created based on terminal usage. Furthermore, the memory 420 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory, or other non-volatile solid-state storage device. In some instances, the memory 420 may further include memory remotely located relative to the processor 410, which can be connected to the terminal device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0112] Input device 430 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the terminal device. Output device 440 may include display devices such as a display screen.

[0113] Example 5

[0114] Embodiment 5 of the present invention provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the program implements the product order payment method provided in all embodiments of the present application: obtaining a user's order request for a product through a product purchase page; sending a lock request to the product inventory; receiving a lock response from the product inventory; while the product inventory is locked, performing an inventory deduction operation based on the order request and generating an order; sending a lock release request to the product inventory to release the locked state of the product inventory; initiating a payment page based on the product orders in the database for the user to pay for the product order; and sending the completed product order to the backend system.

[0115] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0116] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0117] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0118] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0119] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for placing and paying for goods, characterized in that, The method, applied to a product order payment system, includes: The system obtains the user's order request for the product through the product purchase page. The order request includes: user identification information and the quantity of the product ordered. The product order corresponding to the order request is generated through distributed lock operation, and the product order is stored in the database; A payment page is initiated based on the product orders in the database, allowing the user to pay for the product orders; Send the completed payment for the product order to the backend system; The step of generating the product order corresponding to the order request through distributed lock operations includes: Send a lock request to the product inventory; the product inventory represents the available quantity of the product. Upon receiving a locking response from the product inventory, and while the product inventory is locked, a first target virtual inventory is randomly allocated based on the user identifier information; the product inventory is grouped into multiple virtual inventories; the first target virtual inventory is one of the multiple virtual inventories; and the virtual inventories in the product inventory are evenly distributed across the nodes of the Redis cluster. If the quantity of the first target virtual inventory is greater than or equal to the quantity of the product ordered, then the quantity of the first target virtual inventory is deducted based on the quantity of the product ordered, and a product order is generated. If the quantity of the first target virtual inventory is less than the quantity of the product ordered, then at least one second target virtual inventory is allocated to the user, and the sum of the quantities of the first target virtual inventory and the second target virtual inventory is determined as the quantity of the target virtual inventory. If the quantity of the target virtual inventory is greater than or equal to the quantity of the product order, then the quantity of the first target virtual inventory and the quantity of the second target virtual inventory are deducted from the quantity of the product order, and a product order is generated. Send a lock release request to the product inventory to release the locked state of the product inventory.

2. The method according to claim 1, characterized in that, Also includes: If no lock response is received from the product inventory, wait for the lock status of the product inventory to be released, and then return to the operation of sending a lock request to the product inventory until the lock response is received or the duration of not receiving the lock response exceeds a first preset time. If the duration of the period during which the locking response is not received exceeds a first preset time, an order failure message is sent to the product purchase page.

3. The method according to claim 1, characterized in that, Also includes: If the quantity of the target virtual inventory is less than the quantity of the product ordered, and the second target virtual inventory is the last available virtual inventory, then an insufficient inventory prompt is sent to the product purchase page.

4. The method according to claim 1, characterized in that, After initiating the payment page based on the product orders in the database, the process also includes: The product order is sent to a delayed queue and stored according to the product order's generation time; Scan the payment status of the product orders in the delayed queue; If an expired and unpaid order is identified, the expired and unpaid order will be cancelled.

5. A product order payment system, characterized in that, include: The order request module is used to obtain users' order requests for products through the product purchase page; The order request includes: user identification information and the quantity of goods ordered; The product order module is used to generate the product order corresponding to the order request through distributed lock operation, and store the product order in the database; The order payment module is used to initiate a payment page based on the product orders in the database, so that users can pay for the product orders; The order push module is used to send completed payment orders to the backend system; The product ordering module includes: A locking request unit is used to send a locking request to the product inventory, which represents the available quantity of the product. An inventory deduction unit is used to receive a locking response from the product inventory, and, under the locked state of the product inventory, randomly allocates a first target virtual inventory based on the user identifier information. The product inventory is grouped into multiple virtual inventories, and each virtual inventory is evenly distributed across nodes in the Redis cluster. The first target virtual inventory is one of the multiple virtual inventories. If the quantity of the first target virtual inventory is greater than or equal to the product order quantity, a product order is generated, and the quantity of the first target virtual inventory is deducted based on the product order quantity. If the quantity of the first target virtual inventory is less than the product order quantity, at least one second target virtual inventory is allocated to the user, and the sum of the quantities of the first and second target virtual inventories is determined as the quantity of the target virtual inventory. If the quantity of the target virtual inventory is greater than or equal to the product order quantity, the quantities of the first and second target virtual inventories are deducted based on the product order quantity, and a product order is generated. The lock release unit is used to send a lock release request to the product inventory so that the product inventory is released from the locked state.

6. The system according to claim 5, characterized in that, The product order payment system is accessed through a web page URL.

7. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1-4.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-4.

Images