An Internet snap-up method and system

Abstract

The present invention discloses an Internet spike purchase method and system, which disassembles problems from two dimensions: whether the product allows over-selling and the quantity of product inventory. In the weakly consistent scenario where over-selling is allowed, a volatile memory database is used for inventory deduction; in the strongly consistent scenario where over-selling is not allowed, a method of inventory splitting is proposed to avoid lock competition and context switching caused by multi-threaded concurrent updates of the same database record, thereby improving the system throughput.

Description

Technical Field

[0001] The present invention belongs to the field of Internet applications, and particularly relates to an Internet spike purchase technology. Background Art

[0002] In currently known spike purchase systems, the media for storing product inventory include in-memory databases and relational databases, each having its own advantages and disadvantages:

[0003] 1. Using an in-memory database (such as Redis) to deduct inventory ensures the high availability of the system, but there is a risk of over-selling products;

[0004] 2. Using a relational database (such as Mysql) to deduct inventory has problems such as a single point of coordinator, synchronous blocking, data inconsistency, and low execution efficiency. Summary of the Invention

[0005] To solve the technical problems mentioned in the above background art, the present invention proposes an Internet spike purchase method and system, and the technical solutions are as follows:

[0006] An Internet spike purchase method includes the following steps:

[0007] Put the user request into the message queue for asynchronous processing;

[0008] Select an in-memory database or a relational database for inventory deduction according to whether the product allows over-selling. If the product allows over-selling, select an in-memory database for inventory deduction; otherwise, select a relational database for inventory deduction;

[0009] When selecting a relational database for inventory deduction, when the total inventory exceeds a threshold, use the method of inventory splitting to avoid lock competition and context switching caused by multi-threaded concurrent updates of the same database record, thereby improving the system throughput.

[0010] Further, the method for estimating the user waiting time is as follows:

[0011]

[0012] In the above formula, t is the user waiting time, c is the total number of users participating in the spike purchase, n is the total inventory, m is the number of inventory splitting parts, and x is the average TPS for each inventory deduction.

[0013] Further, when the user request arrives, select an appropriate load balancing strategy to select one from m parts of inventory for inventory deduction, and the load balancing strategy is selected according to the needs of the business scenario.

[0014] Further, the load balancing strategy includes but is not limited to weighted random, round-robin, and minimum active number.

[0015] Furthermore, the database inventory is monitored through data subscription. When the inventory is 0, the user requests waiting in the queue will directly return a failure of the flash sale.

[0016] An Internet flash sale and rush purchase system comprises a business layer, wherein the business layer is used to implement the Internet flash sale and rush purchase method.

[0017] Furthermore, it also includes the access layer. The client initiates an HTTP request and forwards it directly to the gateway through Nginx, and then converts the HTTP request into a remote procedure call backend project based on a long connection. At the same time, the gateway acts as an entry to generate a TraceId corresponding to the current request, which is used by the full-link log system to track all traces of a request from the beginning to the end.

[0018] Furthermore, in response to sudden traffic and abnormal situations, the interface adopts relevant measures to ensure high availability and stability of the service, and the relevant measures include but are not limited to current limiting, degradation, fuse and staticization.

[0019] Furthermore, it also includes a data layer, which performs object storage for unstructured data and performs CDN caching as needed to distribute data to the location closest to the user to ensure user access speed.

[0020] Furthermore, structured data is stored in the database, using Memcache for distributed caching or using local cache to protect the database.

[0021] After adopting the above scheme, the present invention has the following beneficial effects:

[0022] The present invention systematically solves the problem of flash sales and breaks down the problem from two dimensions: whether the product is allowed to be oversold and the product inventory quantity. In the weak consistency scenario where oversold is allowed, a volatile memory database is used to perform inventory deductions; in the strong consistency scenario where oversold is not allowed, a method for inventory splitting is proposed to avoid lock contention and context switching caused by multiple threads concurrently updating the same database record. Users can configure and automatically select the above mode according to the needs of the scenario. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a flowchart of the flash sale request processing;

[0024] Figure 2 This is a schematic diagram of the asynchronous consumption task of the message queue;

[0025] Figure 3 It is a schematic diagram of inventory split;

[0026] Figure 4 This is the architecture diagram of the flash sale system;

[0027] Figure 5 It is a schematic diagram of the time-consuming situation of inventory deduction in the inventory splitting scenario;

[0028] Figure 6 It is a schematic diagram of the system throughput in the inventory splitting scenario. Specific implementation manners

[0029] The present invention will be further described below in conjunction with the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and cannot be used to limit the protection scope of the present invention.

[0030] The present invention takes (Consistency Availability Partition Tolerance, CAP) and (Basically Available Soft State Eventually Consistent, BASE) theories as guiding principles, disassembles problems from two dimensions of whether over-selling of goods is allowed and the quantity of goods in stock, and avoids hot-spot updates. In the weakly consistent scenario (AP) where over-selling is allowed, a volatile memory database is used for inventory deduction; in the strongly consistent scenario (CP) where over-selling is not allowed, a method of inventory splitting is proposed to avoid lock competition and context switching caused by multi-threaded concurrent updates of the same database record. A message queue is used to smooth out the peaks and valleys, and the database inventory is monitored by means of data subscription. When the inventory is 0, the requests queued in the queue are directly returned with a failure in the spike purchase. The entire process is as Figure 1 shown.

[0031] 1. The "spike purchase" request is asynchronously processed using a message queue (MQ) to smooth out the peaks and valleys

[0032] As Figure 2 shown, the user request is put into the message queue to queue up for processing and then directly returned. The backend system can set a reasonable number of concurrency for consumers to pull the messages in the queue for consumption (inventory deduction, deduction of virtual currency, distribution of goods, etc.). Only with an appropriate number of concurrency for inventory deduction can the system have the maximum throughput, and this threshold can be obtained through stress testing. The processing result is pushed to the front-end user through a long connection.

[0033] 2. The scenario where over-selling of the purchased goods is allowed

[0034] For virtual goods such as membership, there is no concept of inventory for the platform, and Redis can be used for inventory deduction. Since Redis is completely memory-based and designed with a single-threaded IO model, there is no lock competition and context switching, and the processing speed is extremely fast. However, there are unknown risks such as downtime or master-slave switching, resulting in data loss or inconsistency, that is, the over-selling problem occurs.

[0035] 3. Scenarios where over-selling of rush-buying goods is not allowed

[0036] Due to scarcity or high value, physical goods are strictly not allowed to be over-sold in flash sales considering activity cost control. The storage of product inventory information can only consider using a relational database. On the one hand, its data is persisted on the hard disk, which is safe and reliable for inventory deduction and has strong data consistency. On the other hand, its execution efficiency is poor, and TPS is difficult to exceed 100. Users have to queue, and there are also hot update problems.

[0037] 4. The total inventory is very large and can be split

[0038] Generally speaking, increasing the number of concurrent (thread) tasks processed by the system can improve system throughput. However, in our specific scenario, there are hot update and lock competition problems in inventory deduction. When the number of concurrent operations exceeds a reasonable value, the system throughput will drop sharply. While increasing the number of concurrent operations, we use the method of splitting the inventory into multiple parts to reduce the lock competition in inventory deduction, thereby improving the overall throughput of the system. The following gives a general method for estimating user waiting time: If the inventory is split into m parts, assuming that the average TPS for each inventory deduction is x (which can be obtained through pre-stress testing), the total inventory of the product is n, and the total number of users participating in the rush-buying is c. If the allowable user waiting time is t, then:

[0039]

[0040] All parameters can be predicted in advance. If it is required that t is less than 2 seconds, m can be calculated.

[0041] The total inventory n can be cut into m parts. The m parts of inventory can be stored in the same table to reduce the granularity of row lock competition. Even the inventory can be stored on different physical database nodes. In the most ideal state, the system throughput (TPS) can be linearly increased by m times, where n = p1 + p2... + p m , as Figure 3 shown. Splitting the total quantity of inventory into reasonable parts enables the system to have the ability of horizontal scaling. At the same time, the ability of a single machine (CPU, memory, etc.) can be increased for vertical scaling.

[0042] 5. The total inventory is very small and cannot be split

[0043] Assume there are only 2 items in stock. If it is split into 10 portions, it is equivalent to an 80% random failure rate for users. Therefore, from the perspective of improving system throughput, users cannot be prevented from waiting using the above method. The user waiting time depends on the number of users participating in the flash sale, the item inventory, and the system throughput. When the item inventory reaches 0, the flash sale ends, and all users queuing in the message queue waiting for processing will directly receive a flash sale failure. Therefore, the user waiting time is the smaller value between the number of participating users and the initial item inventory divided by the system throughput. Specifically, assume the TPS for database inventory deduction is 10, and 100,000 users simultaneously participate in the flash sale of a certain item with an initial inventory of 10. Since users in the queue will directly receive a flash sale failure when the inventory reaches 0 and do not enter the full process for processing, the maximum waiting time for all users is 1 second. Thus, when the inventory quantity is very small, do not split the inventory and use a single-threaded task processing method. Even if the system throughput is low, it can ensure that users do not have to wait.

[0044] 6. Select an appropriate load balancing strategy based on user experience or system throughput considerations

[0045] When a user request arrives, select an appropriate load balancing strategy (weighted random, round-robin, least active count) to select one from m portions of inventory for inventory deduction. Different load balancing strategies have the following characteristics and can be reasonably selected according to business scenario requirements:

[0046] (1) Random: Simple to implement but may cause inventory skew. The user's flash sale request may be routed to a record with an inventory of 0, resulting in a flash sale failure and a poor user experience.

[0047] (2) Round-robin method: Ensures that the inventory is evenly deducted, providing a good user experience.

[0048] (3) Least active count: Prioritizes selecting a node with high execution efficiency for inventory deduction, which can improve the overall system throughput.

[0049] As Figure 4 shown, the system designed in the present invention includes:

[0050] (1) Access layer: The client initiates an HTTP request to Nginx. Although it has the ability of load balancing, for unified entry control and to avoid complex API routing rule configurations, Internet manufacturers generally directly forward the HTTP request through Nginx to the gateway, and then transform the HTTP request into a more efficient remote procedure call backend project based on a long connection. At the same time, as the entry point, the gateway can generate a TraceId corresponding to the current request, which is used by the full-link log system to trace all the trajectories of a request from start to end, facilitating problem analysis and troubleshooting. For sudden traffic and abnormal situations, the interface adopts measures such as flow limiting, degradation, fusing, and staticization to ensure the high availability and stability of the service.

[0051] (2) Business layer: After the user's seckill request passes the legality check, it is directly delivered to the message queue and waits for the seckill processing result. The role of the message queue is to smooth the traffic peaks and valleys. Consumers asynchronously pull the backlogged messages in the queue in multiple threads for processing, and after the processing is completed, the results are pushed to the user through a long connection. Redis or the database (MySQL) is selected for inventory deduction according to whether the product allows overselling. The data transmission service DTS middleware asynchronously listens to the changes in the database Binlog, and pushes the product inventory information to the local memory Caffeine in real time. When consuming seckill messages, first check whether the product inventory is 0. If it is 0, the messages in the message queue can be cleared, and it is returned that the user's seckill purchase fails due to insufficient inventory. A complete system contains many microservices (payment, inventory, message notification, logistics distribution, etc.), and different services communicate with each other through remote procedure calls (such as Dubbo).

[0052] (3) Data layer: Unstructured data such as files and pictures are stored as objects, and CDN caching can be done according to needs to distribute the data to the place closest to the user to ensure the user access speed. Structured data is stored in the database. To protect the database, Memcache can be used for distributed caching or local caching (Caffeine) can be used. Since Redis has rich data structures that are convenient for implementing business logic and its cluster ensures high availability, it is widely used in scenarios where strong data consistency is not required.

[0053] As Figure 5 shown, the time-consuming situation of using the database to deduct inventory under 1, 2, 4, 8, and 16 concurrencies when the inventory is split into 1, 2, 4, and 8. In the scenario of using one inventory, the average execution time of a single-concurrency inventory deduction SQL is 4.34 ms. As the number of concurrencies increases, the performance of inventory deduction deteriorates sharply due to the problem of hot updates. The average execution time of the 16-concurrency inventory deduction SQL is as high as 636.99 ms, which is 146 times that of single concurrency. Therefore, in the scenario of one inventory, the system throughput will not increase with the increase in the number of concurrencies, and it may even cause the database to become unavailable due to intense lock competition and frequent context switches. If there are other services sharing the database resources with this seckill service, it will also be affected. Under the same concurrency, the more the inventory is split, the faster the database responds to inventory deduction. Under high concurrency, splitting the inventory can effectively reduce the execution time of the database. When consuming tasks with sixteen concurrencies, the operation time-consuming in the scenario of one inventory (636.99 ms) is 7.5 times that of eight inventories (84.77 ms).

[0054] As Figure 6As shown in the figure, with the increase in the number of concurrent requests and the number of inventory splits, the throughput of the system gradually increases. When there are eight inventories and sixteen concurrent requests, the system throughput is 138. When there is one inventory and sixteen concurrent requests, the system throughput is 24. When splitting one inventory into eight under sixteen concurrent requests, the system TPS is increased to 5.75 times.

[0055] The above embodiments are only used to illustrate the technical idea of the present invention, and the protection scope of the present invention cannot be limited thereby. Any changes made on the basis of the technical solution according to the technical idea proposed by the present invention fall within the protection scope of the present invention.

Claims

1. An Internet flash sale and purchase method, characterized in that, The following steps are involved: Put user requests into the message queue for asynchronous processing; Select an in-memory database or a relational database for inventory deduction based on whether the product is allowed to be oversold. If the product is allowed to be oversold, select an in-memory database for inventory deduction; otherwise, select a relational database for inventory deduction. When a relational database is selected for inventory deduction, when the total inventory exceeds a threshold, the inventory split method is used to avoid lock contention and context switching caused by multiple threads concurrently updating the same database record, thereby improving system throughput; The method for estimating user waiting time is as follows: In the above formula, t is the user waiting time, c is the total number of users participating in the rush purchase, n is the total inventory, m is the number of parts of the inventory, and x is the average TPS deducted from each inventory; When a user request comes, a suitable load balancing strategy is selected, and one is selected from the m stocks to deduct the stock. The load balancing strategy is selected according to the needs of the business scenario.

2. The Internet flash sale and rush purchase method according to claim 1, wherein The load balancing strategies include but are not limited to weighted random, polling and minimum active number.

3. The Internet flash purchase method according to claim 1, wherein, The database inventory is monitored by data subscription. When the inventory is 0, the user requests waiting in the queue will be directly returned as failed.

4. An Internet second-kill and rush purchase system, characterized in that, It includes a business layer, and the business layer is used to implement the Internet flash sale method as described in any one of claims 1 to 3.

5. The Internet flash purchase system according to claim 4, characterized in that, It also includes the access layer. The client initiates an HTTP request and forwards it directly to the gateway through Nginx. The HTTP request is then converted into a remote procedure call backend project based on a long connection. At the same time, the gateway acts as an entry point to generate a TraceId corresponding to the current request, which is used by the full-link log system to track all traces of a request from start to end.

6. The Internet flash sale and rush purchase system according to claim 5, characterized in that, In response to sudden traffic and abnormal situations, the interface adopts relevant measures to ensure high availability and stability of the service, including but not limited to current limiting, degradation, fuse and staticization.

7. The Internet snap-up system according to claim 4, wherein It also includes a data layer, which performs object storage for unstructured data and performs CDN caching as needed to distribute data to the location closest to the user to ensure user access speed.

8. The Internet instant kill and rush purchase system according to claim 7, characterized in that, Structured data is stored in the database, using Memcache for distributed caching or using local cache to protect the database.

Images