Sales promotion panic buying processing method under high concurrency

Abstract

The invention relates to the technical field of e-commerce order transaction processing, in particular to a high-concurrency sales promotion panic buying processing method, which comprises the following steps of: operating a user side and a server side, after the user side selects a commodity and submits an order, sending a request containing commodity data and a monitoring token through an HTTP (Hyper Text Transport Protocol), and polling the monitoring token to obtain a response so as to judge an operation result. After receiving the request, the server performs identity verification, inventory check and price calculation, packages request data into a queue by adopting an asynchronous process, distributes messages to different servers for consumption according to a Hash algorithm, encrypts a storage result to a token in a consumption process, and returns the encrypted storage result to a user side in time. The method further comprises the steps that cache preloading is carried out, the management background writes an active commodity stock into the REDIS cache, and the front end adopts different cache strategies for static resources and dynamic content such as pictures. The system performance and the user experience are effectively improved, the data processing accuracy and safety are guaranteed, and the method is suitable for high-concurrency sales promotion and panic buying scenes.

Description

Technical Field

[0001] The invention relates to the technical field of e-commerce order transaction processing, and in particular to a promotion rush purchase processing method under high concurrency. Background Art

[0002] In the field of e-commerce, promotional activities are becoming more and more frequent, such as limited-time discounts and flash sales, which attract a large number of users to participate. However, this high-concurrency scenario brings many challenges to the system.

[0003] It is common that a large number of users submit orders in a short period of time, which has a huge impact on the system's processing capacity. Traditional order processing methods are often unable to cope with the sudden burst of high-traffic requests, which can easily lead to slow system response or even paralysis. For example, in some promotional activities, the server may be stuck due to too many requests in an instant, and users have to wait for a long time for the page to load or the order processing result feedback, which seriously affects the user experience.

[0004] At the same time, inventory management in a high-concurrency environment also faces challenges. Overselling may occur, that is, the actual inventory is insufficient but the goods are still successfully sold. This not only harms the interests of consumers, but also causes a series of subsequent after-sales problems, which has a negative impact on merchants. In addition, the accuracy and security of data are also at risk in high-concurrency situations, such as order information errors, user data leakage and other problems.

[0005] Therefore, there is an urgent need for an effective promotion and rush buying processing method to solve problems in system performance, inventory management, data processing, etc. in high-concurrency scenarios, ensure the smooth progress of promotion and rush buying activities, and improve user experience and enterprise operation efficiency. Summary of the invention

[0006] The purpose of the present invention is to provide a method for processing promotion rush purchases under high concurrency to solve the problems raised in the above background technology.

[0007] To achieve the above object, the present invention provides the following technical solutions:

[0008] A method for processing promotion rush purchases under high concurrency, including user-side operations and server-side operations;

[0009] User-side operations include:

[0010] After the user selects a product in the promotion section and adds it to the shopping cart, the user submits the order, collects product-related information and generates a listening token, sends a request containing product data and a listening token to the server through the HTTP protocol, and starts polling the listening token to obtain a response at a fixed period T, T=500ms;

[0011] The operation result is determined based on the code in the token returned by the server. If code=200, the order success page and order information are displayed. If code=400 and the message contains "Insufficient stock", it indicates insufficient stock. If code=500, an error message is displayed.

[0012] Server operations include:

[0013] Receive user request, perform user identity authentication, product inventory check, price calculation, start asynchronous process to package user request data into messages and add them to queue, distribute queue messages to different servers for consumption. The algorithm formula for distributing messages to servers is: ,in, For server index, To hash a message, is the total number of servers;

[0014] During the message consumption process, the results including successful order placement, insufficient inventory, and abnormalities are packaged and stored in the listening token. When the token is detected to have updated content, the information in the token is returned to the user end through HTTP response. The encryption algorithm is used when the results are packaged and stored in the token. ,in, For the encrypted data, For the result data that needs to be stored, Is the encryption key.

[0015] As a preferred solution, cache preloading is also included, and the cache preloading steps are as follows:

[0016] The management backend writes the active product inventory into the REDIS cache, reads the cache first, releases the inventory using an asynchronous multi-process approach, and writes and reads the inventory in accordance with the algorithm And the rule of checking the cache first and then the database, when writing, For the inventory in the cache, For the inventory in the database;

[0017] Static caching is used for front-end product images and page layouts, and dynamic caching strategy is used for dynamic content. The calculation formula for cache validity period is: ,in, is the cache validity period, is the basic time constant, To update the frequency according to the data Dynamically adjusted function, when When high, Small value, Short; when When low, the value ambassador long.

[0018] As a preferred solution, it also includes overall system optimization, which includes a fuse mechanism. When the system request is close to the load limit, it will suspend processing new requests and limit the IP and identity of users who frequently initiate requests. The judgment of whether the request is close to the load limit is determined by an algorithm. Conduct, among which, is the number of requests in the most recent period. To set the threshold;

[0019] In nginx request processing, the problem of duplicate request increment is reduced by optimizing configuration parameters, and a multi-load multi-distribution strategy is adopted to evenly distribute user requests to the backend servers. The distribution algorithm formula is: ,in, For server index, To hash a message, is the total number of servers.

[0020] As a preferred solution, the message distribution of the queue adopts a load balancing algorithm to ensure the load balancing of the server. If a server fails, the tasks on the server are automatically dispatched according to the algorithm. Redistribute to other normal servers, where is the server index after reallocation. The original server index, is the total number of servers.

[0021] As a preferred solution, the server uses the token bucket algorithm to limit the flow when processing concurrent requests. The formula is: ,in, is the number of requests allowed to pass, is the number of tokens in the token bucket, The maximum number of requests allowed per second. The thread pool technology is used at the same time. Its size is determined by the system configuration and actual load according to the algorithm. Dynamic adjustment, where is the thread pool size, is the maximum thread pool size, is the current number of requests, is the average request processing time, is the safety factor.

[0022] As a preferred solution, the server uses a message compression algorithm when packaging user request data into messages. ,in, is the compressed message, It is the original message data, and uses technologies including long connection and data caching to optimize network transmission in data interaction.

[0023] As a preferred solution, the server uses an optimistic locking algorithm when checking product inventory. The algorithm formula is: ,in, For the inventory after inspection, To check the inventory before, When checking the inventory for the user's purchase quantity, first obtain the current inventory value and calculate the inventory value after purchase. If the calculated inventory value is greater than or equal to 0, the order is allowed, otherwise it is determined that the inventory is insufficient.

[0024] As a preferred solution, the server uses the corresponding algorithm according to the promotion rules when calculating the price. If it is a full discount rule, the calculation method is ,in, For the final price, For the original price, The discount rate is determined according to the full-discount rule.

[0025] It can be seen from the technical solution provided by the present invention that the method for processing promotion rush purchases under high concurrency provided by the present invention has the following beneficial effects:

[0026] Asynchronous processing and load balancing:

[0027] The server uses an asynchronous process to package user request data into messages and add them to the queue, and distributes the queue messages to different servers for consumption through a specific algorithm. This asynchronous processing method avoids users from waiting for responses for a long time under high concurrency conditions, thereby improving the system throughput. At the same time, message distribution uses a load balancing algorithm to reasonably allocate tasks according to the server load, ensuring that the resources of each server are effectively utilized and avoiding single-point overload, greatly improving the overall stability and processing capacity of the system, and being able to better cope with the situation where a large number of users place orders at the same time during promotional purchases.

[0028] Cache preloading and optimization:

[0029] The management backend writes the active product inventory into the REDIS cache and reads the cache first. The asynchronous multi-process method is used to release the inventory, and a specific algorithm is followed to ensure that the cache is consistent with the database inventory. The front end uses static caching for product images and page layouts, and a dynamic caching strategy for dynamic content, dynamically adjusting the cache validity period according to the frequency of data updates. The effective use of the cache reduces frequent data queries and repeated calculations, significantly improves the data reading speed, reduces the load pressure on the database and server, enables the system to respond quickly in high-concurrency scenarios, and improves the overall performance of the system.

[0030] Timely feedback on order status:

[0031] After the user submits an order, a polling listening token is started at a fixed period to obtain a response. During the message consumption process, the server will promptly package and store the results including order success, insufficient inventory, and abnormalities in the listening token, and return them to the user through HTTP response when an update is detected. Users can know the order processing results in a timely manner. Whether it is peace of mind after a successful order, or quick knowledge when encountering insufficient inventory or system abnormalities, users can avoid long-term uncertainty waiting and greatly improve the user experience.

[0032] Friendly reminder information:

[0033] According to the code in the token returned by the server, the user can accurately judge the operation result and give corresponding friendly prompts; for example, when code=200, the order success page and detailed order information are displayed; when code=400 and the words "Insufficient Stock" are included, it indicates insufficient stock; when code=500, an error message is displayed; clear and unambiguous prompts help users quickly understand the order status and make reasonable decisions, further optimizing the user experience during the promotion and rush purchase process;

[0034] Optimistic locking algorithm ensures inventory accuracy:

[0035] The server uses an optimistic locking algorithm when checking product inventory. It first obtains the current inventory value and calculates the inventory value after purchase. Orders are allowed only when the calculated inventory value is greater than or equal to 0. Otherwise, it is considered that the inventory is insufficient. This method effectively avoids inventory problems such as overselling in a high-concurrency environment, ensures the accuracy of inventory data, and enables promotional activities to be carried out in an orderly manner based on accurate inventory data.

[0036] Encryption algorithm ensures data security:

[0037] When packaging the order processing results and storing them in the listening token, an encryption algorithm is used to encrypt the result data. Only the authorized party with the encryption key can decrypt and view it. During the data interaction process, the encryption algorithm ensures the security of sensitive data such as user order information during transmission and storage, prevents data from being stolen or tampered with, and effectively protects user privacy and enterprise data security. DETAILED DESCRIPTION

[0038] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0039] In order to better understand the above technical solution, the above technical solution will be described in detail below in conjunction with specific implementation methods.

[0040] The embodiment of the present invention provides a promotion rush purchase processing method under high concurrency, including user-side operation and server-side operation.

[0041] In this embodiment, the user terminal operation includes:

[0042] After the user selects a product in the promotion section and adds it to the shopping cart, the user submits the order, collects product-related information and generates a listening token, sends a request containing product data and a listening token to the server through the HTTP protocol, and starts polling the listening token to obtain a response at a fixed period T, T=500ms. The specific operations are as follows:

[0043] Product selection and information collection:

[0044] Users enter the promotion section of the e-commerce platform and browse the various promotional products on display; products are usually presented in the form of pictures, names, prices, brief descriptions, etc.; users click to select the products they want to buy based on their own needs and preferences and add them to the shopping cart; in this process, the system automatically collects key information related to the selected products, including but not limited to the product's unique identifier (such as product ID), name, specifications (such as size, color, configuration, etc.), quantity, unit price, and applicable discount information for the product under the current promotion activity rules; at the same time, the system will generate a listening token for subsequent tracking of the order processing progress; this token is a unique string or number combination, which plays a role in identification and association during the entire order processing process;

[0045] Request sending and polling preparation:

[0046] The client encapsulates the collected product data and the generated listening token in the format specified by the HTTP protocol to form a complete request. The HTTP request includes a request header (such as metadata including client information and request format) and a request body (actual product data and token). Then, the client sends the request to the interface address specified by the server through network communication. After sending the request, the client immediately starts a polling listening mechanism and sets a fixed polling cycle T of 500ms. This means that every 500ms, the client will actively initiate a query to the server to obtain the latest progress of order processing.

[0047] Polling monitoring and result acquisition:

[0048] When each 500ms polling cycle arrives, the client will send a query request containing the previously generated listening token to the server again; after receiving this request, the server will search for the corresponding order processing status record according to the token; if the order processing has been completed, the server will package the information containing the processing result (such as success, insufficient inventory, error, etc.) into the token and return it to the client through HTTP response; after receiving the response, the client will parse the content in the token and extract the processing result code to determine the final result of the order operation; for example, if code=200, the client will know that the order is successfully placed, and then can display detailed order information to the user; if it is other code values, the user will be prompted to insufficient inventory or error information will be displayed according to the corresponding rules; during the whole process, polling will continue until a clear processing result is obtained to ensure that the user can know the order status in time;

[0049] The operation result is determined based on the code in the token returned by the server. If code=200, the order success page and order information are displayed. If code=400 and the message contains "Insufficient stock", it indicates insufficient stock. If code=500, an error message is displayed. The specific operations are as follows:

[0050] Receive server response and parse token:

[0051] After the client sends a request to the server and starts polling listening, it will continue to wait for the server's response. When the server completes the order processing and returns the result to the client through HTTP response, the client first receives the response data containing the token. Then, the client uses the corresponding parsing technology (such as JSON parsing, if the token is stored in JSON format) to extract the token from the response.

[0052] Determine the code value and perform corresponding operations:

[0053] Order successful (code=200):

[0054] When the code value parsed from the token is 200, it indicates that the order has been successfully processed. At this point, the user end will immediately perform a series of operations to display the order success page. It will obtain order information from the token or previously stored related data, including the order number (used to uniquely identify the order), detailed list of products (such as product name, specifications, quantity, unit price, etc.), total purchase price (the final price after considering promotional discounts), delivery address (delivery address information filled in by the user when placing an order), order time (accurately record the time when the order was submitted), etc. Then, this information is displayed on the order success page in a clear and friendly manner, so that users can fully understand their purchase details. For example, the order number may be displayed at the top of the page in a larger font, the product list displays the specific information of each product in a table, the total price is displayed in a prominent manner, the delivery address and order time are presented in an appropriate position, and some warm reminders or next operation guidance may also be displayed, such as order tracking method, estimated delivery time, etc.

[0055] Out of stock (code=400 and message contains "Out of stock"):

[0056] If the parsed code value is 400, the user end will further check the message content; when it is found that the message contains the words "out of stock", it is determined that the operation failed because the product inventory is insufficient to meet the user's order requirements; at this time, the user end will remind the user of the insufficient inventory in a striking way on the page, such as popping up a pop-up window with a clear text prompt "The product you purchased is out of stock, please adjust the purchase quantity or choose another product"; at the same time, some relevant operation suggestions may be provided, such as guiding the user to return to the shopping cart to modify the product quantity, recommending similar products in stock, etc., to help users solve the problem of insufficient inventory and improve user experience;

[0057] System error (code=500):

[0058] When the code value is 500, it means that the system encountered an internal error while processing the order; the user end will display the corresponding error message on the page, such as "The system is busy, please try again later" or "Order processing error, please contact customer service", etc.; the specific error message display method may vary according to the design style of the platform, but the purpose is to let users know clearly that the order processing failed and is caused by system reasons; at the same time, in order to facilitate users to solve problems, an entry for contacting customer service (such as a button or link) may be provided. Users can click to enter the customer service communication channel and describe the problem in detail to the customer service staff to seek help and solutions; in some cases, the user end may also record error logs to facilitate developers to analyze and troubleshoot problems later and improve the stability and reliability of the system.

[0059] In this embodiment, the server operation includes:

[0060] Receive user request, perform user identity authentication, product inventory check, price calculation, start asynchronous process to package user request data into messages and add them to queue, distribute queue messages to different servers for consumption. The algorithm formula for distributing messages to servers is: ,in, For server index, To hash a message, is the total number of servers. The specific operations are as follows:

[0061] Receiving client requests and extracting data:

[0062] The server listens to the request sent by the client through the network. Once the request is received, the server will first parse the request and extract the product data and listening token submitted by the user from the request. The product data contains the relevant information of the product selected by the user, such as product ID, quantity, specifications, etc., and the listening token is used for subsequent tracking and associated order processing.

[0063] User Authentication:

[0064] The server compares the extracted user information (such as user ID, login credentials, etc.) with the user data stored in the system for verification; the verification method may include checking whether the username and password match (if the user is logged in), verifying the validity of the user token (if token authentication is used), etc.; if the user identity authentication fails, the server will package the corresponding error information into the listening token (such as setting the code to a specific error code), and return it to the user through the HTTP response, terminating the subsequent processing flow;

[0065] Product inventory check:

[0066] The server queries the product inventory system based on the product ID and quantity purchased by the user; uses an optimistic locking algorithm to check inventory, with the formula: where is the inventory after the check, is the inventory before the check, and is the number of purchases by the user; first obtains the current inventory value, calculates the inventory value after the purchase, and if the calculated inventory value is greater than or equal to 0, allows the order to continue the subsequent process; otherwise, determines that the inventory is insufficient, packages the information about the insufficient inventory into the listening token (such as setting the code to 400 and indicating "Insufficient Inventory" in the message), and returns it to the user through the HTTP response, terminating the processing;

[0067] Price calculation:

[0068] Based on the product ID and promotion rules, the server calculates the final price of the product purchased by the user; if it is a full-discount rule, the calculation method is: where is the final price, is the original price, and is the discount rate determined according to the full-discount rule; the server obtains the original price of the product from the product database, and then calculates the discount rate according to the full-discount rule of the current promotion activity, and then obtains the final price, and temporarily stores the price information for subsequent use in order processing;

[0069] Start asynchronous process and message packaging:

[0070] After the previous verification and calculation, if the order meets the processing conditions, the server starts an asynchronous process to process the order; the user request data (including user identity information, product information, order amount, listening token, etc.) is packaged into a message in a certain format; the message format will be determined according to the system design to ensure that all necessary order processing information is included so that the subsequent server can accurately understand and process it;

[0071] The message is added to the queue:

[0072] Add the packaged messages to the queue; the queue plays a role in buffering and asynchronous processing, allowing the system to cope with high-concurrency requests and avoid system crashes or processing delays caused by a large number of requests at once; messages in the queue wait to be distributed and processed in the order of first-in-first-out;

[0073] Messages are distributed to the server for consumption:

[0074] The message distribution algorithm is used to distribute the messages in the queue to different servers for consumption. The algorithm formula is, where is the server index, is the hash calculation of the message, and is the total number of servers. By hashing the message, a hash value is obtained, and then the hash value is modulo the total number of servers to get the result of the server index to which the message should be distributed. This ensures that the messages can be evenly distributed to each server, achieves load balancing, and improves the overall processing capacity and efficiency of the system. After each server obtains the message from the queue, it will perform actual order processing operations according to the content of the message, such as generating orders, updating inventory, recording order logs, etc. After the processing is completed, the result will be updated to the listening token so that the server can return the result to the user in a timely manner.

[0075] During the message consumption process, the results including successful order placement, insufficient inventory, and abnormalities are packaged and stored in the listening token. When the token is detected to have updated content, the information in the token is returned to the user end through HTTP response. The encryption algorithm is used when the results are packaged and stored in the token. ,in, For the encrypted data, For the result data that needs to be stored, is the encryption key; the specific operations are as follows:

[0076] Message consumption processing:

[0077] After the server obtains the message from the queue, it starts to consume the message. First, it re-performs a series of verifications and operations based on the user request data contained in the message. It checks the user identity information again to ensure that it is consistent with the user data stored in the system to prevent illegal requests. Then, it re-checks the product inventory based on the product ID and quantity to confirm whether the inventory status meets the order requirements. In terms of price calculation, it recalculates the final price based on the product original price and promotion rules to ensure the accuracy of price calculation.

[0078] During the entire processing process, the order processing result is determined according to different situations; if all verifications and operations are completed smoothly without any problems, such as sufficient inventory, legal user identity, correct price calculation, etc., the result will be marked as a successful order; if it is found in the inventory check link that the inventory quantity is less than the user's purchase quantity and cannot meet the order requirements, the result will be marked as insufficient inventory; if an internal system error is encountered during the processing process, such as database query failure, processing interruption caused by insufficient server resources, network communication abnormalities, etc., resulting in the order being unable to be processed normally, the result will be marked as abnormal and detailed error information will be recorded for subsequent troubleshooting and analysis of the problem;

[0079] The results are packaged and encrypted and stored in the listening token:

[0080] The server packages the relevant information for different order processing results. For successful orders, the packaged data includes the order number (to ensure the uniqueness of the order for subsequent query and tracking), processing time (to accurately record the time when the order processing is completed), a detailed list of purchased goods (goods name, specifications, quantity, unit price, etc.), the final price (the actual payment price after considering promotional activities), and a status indicator indicating that the order is successfully placed. If the result is insufficient inventory, the packaged data includes a prompt message of insufficient inventory, the ID and quantity of the goods involved, the current inventory quantity, etc., so that the user can clearly understand the inventory situation. In abnormal situations, in addition to the abnormal status indicator, the packaged data will also record in detail the error code, error description (such as database connection timeout, server memory overflow, and other specific error causes) and possible solution suggestions (if any).

[0081] Next, the packaged data is encrypted using an encryption algorithm. The encryption algorithm is as follows: the server obtains the preset encryption key from a secure storage location, takes the result data to be stored (i.e. the previously packaged data structure containing the order processing results and related information) and the encryption key as input, calculates the encrypted data using the encryption algorithm, and then stores the encrypted data in the listening token. This can effectively prevent the result data from being stolen or tampered with during transmission and storage, and ensure the security and integrity of the user's order information.

[0082] Detect token update and response return:

[0083] The server sets up a special mechanism to continuously monitor the status of the listening token. When the order processing is completed and the result is encrypted and stored in the token, the content of the token changes. The server can detect this update in time through specific detection methods (such as listening to token change events or regularly checking the status of the token).

[0084] Once the token is detected to have updated content, the server immediately builds an HTTP response. In the response, the updated listening token is included as part of the response body, and the appropriate HTTP status code (such as 200 for success) and response header information (such as metadata such as content type and cache policy) are set. Then, the HTTP response is sent back to the client through network communication. After receiving the response, the client extracts the listening token from the response according to the preset communication protocol. Then, the decryption algorithm corresponding to the server encryption algorithm and the decryption key pre-acquired or stored on the client (matching the server encryption key) are used to decrypt the content in the token and extract the order processing result information. Finally, the client performs corresponding processing based on the decrypted result, such as displaying an order success page on the interface (displaying order details), popping up a prompt box for insufficient inventory (informing users of inventory status and possibly providing relevant operation suggestions) or displaying system abnormality information (guiding users to contact customer service or take other measures), etc., so as to achieve safe, accurate and timely transmission of order processing results between the server and the client, ensuring that users can understand the order status in a timely manner and make corresponding decisions.

[0085] In this embodiment, cache preloading is also included, and the cache preloading steps are as follows:

[0086] The management backend writes the active product inventory into the REDIS cache, reads the cache first, releases the inventory using an asynchronous multi-process approach, and writes and reads the inventory in accordance with the algorithm And the rule of checking the cache first and then the database, when writing, For the inventory in the cache, For the inventory in the database;

[0087] Static caching is used for front-end product images and page layouts, and dynamic caching strategy is used for dynamic content. The calculation formula for cache validity period is: ,in, is the cache validity period, is the basic time constant, To update the frequency according to the data Dynamically adjusted function, when When high, Small value, Short; when When low, the value ambassador long;

[0088] Furthermore, cache preloading at runtime includes:

[0089] Management background operations:

[0090] Inventory data is written to cache:

[0091] The management backend uses database query statements to accurately obtain the inventory data of active products from the database, including key information such as the detailed inventory quantity of each product and the preset inventory warning threshold (used for subsequent real-time monitoring of inventory status); then, these inventory data are carefully organized according to the specific data structure format required by the REDIS cache to ensure that the data can be stored efficiently and read quickly; for example, the product ID may be used as the key, and the inventory quantity and warning threshold may be used as the value to construct a hash table structure and store it in REDIS;

[0092] Next, use the efficient cache write interface or command (such as SET or HMSET, etc.) provided by REDIS to write the sorted inventory data into the REDIS cache; when writing, strictly follow the algorithm ,in, Represents the inventory in the cache. When the inventory data obtained from the database is written into the cache, it is ensured that it is completely consistent with the inventory data in the database, that is, the inventory data written into the cache must accurately reflect the actual inventory situation in the database. After writing, the relevant attributes of the cache data are set according to business needs, such as setting a reasonable expiration time (if applicable). Assume that it is set to 60 seconds, which means that the inventory data is valid in the cache within 60 seconds. If it is not updated for more than 60 seconds, it is considered expired. At the same time, the data storage format is determined to be a hash table format, etc., to optimize the storage and access efficiency of the cache, so as to facilitate subsequent rapid reading and updating.

[0093] Front-end cache operation:

[0094] Static content caching:

[0095] For static resources such as front-end product images and page layouts, front-end developers configure front-end building tools (such as Webpack, etc.) or server settings (such as Nginx configuration) during project building or deployment to specify that these static resources be cached to the user's browser or a dedicated front-end cache server (such as CDN); for images that are frequently accessed and not frequently updated (such as product display images) and page layout files (such as HTML, CSS files), a relatively long cache validity period will be set; for example, based on experience or performance test results, the cache validity period is set to 7 days (the specific time can be adjusted according to actual conditions); during the caching process, The URL or file path of the resource generates a unique cache key. For example, for image resources, an MD5 hash value may be generated based on its full URL as the cache key. The resource content is then stored in the browser's local cache or cache storage areas such as CDN nodes, and relevant cache metadata is recorded, such as the cache time (accurate to seconds or milliseconds, recording the time when the resource was first cached), validity period (7 days), etc. When a user visits the same product page or image again, the browser first checks whether the resource exists in the local cache. If it exists and has not expired, it is directly read from the cache and displayed without requesting the server again, thereby greatly improving page loading speed and user experience;

[0096] Dynamic content cache policy settings:

[0097] For dynamic content on the front end (such as product prices, inventory quantity display, promotional information, etc.), the system adopts a dynamic cache strategy to dynamically adjust the cache validity period according to the frequency of data updates. The calculation formula is, where is the cache validity period, is the basic time constant (assuming that it is set to 30 seconds based on business characteristics and performance testing, as the basis for calculating the cache validity period), and is a function that is dynamically adjusted according to the data update frequency; when the data update frequency is high, the value is small, for example, when the data is updated once a minute (the update frequency is high), the value calculated by the function may be 0.5, making the cache validity period (seconds). A shorter validity period ensures that users can obtain the latest dynamic information in a timely manner; when the data update frequency is low, the value is large, for example, when the data is updated once an hour (the update frequency is low), the value calculated by the function may be 2, and the cache validity period is (seconds). A longer validity period reduces unnecessary cache update operations and improves system performance;

[0098] The system will monitor the changes of dynamic data in real time through mechanisms such as event monitoring, scheduled tasks or data change notifications; when the data is updated, the cache validity period is recalculated according to the new update frequency; assuming that after the price data of a certain product is updated, the new update frequency becomes once every 30 minutes, and the new cache validity period is recalculated to be (seconds); then, according to the cache update strategy (such as updating the cache first and then updating the database, or using the cache invalidation strategy, such as setting the cache expiration time or actively notifying the cache server of invalidation), the data in the cache is updated; when reading dynamic content, the front-end code first obtains the data from the cache. If the data does not exist in the cache (it may be the first access or the cache has expired) or the data has expired, the latest data is obtained from the back-end server through HTTP requests, and the new data is stored in the cache again according to the dynamic cache strategy. At the same time, the relevant metadata (such as cache time, validity period, etc.) is updated to ensure the consistency and accuracy of the cached data, providing users with real-time and efficient dynamic content display.

[0099] In this embodiment, the overall system optimization is also included. The overall system optimization includes a fuse mechanism. When the system request is close to the load limit, the processing of new requests is suspended, and the user IP and user identity that frequently initiates requests are restricted. The judgment that the request is close to the load limit is determined by an algorithm. Conduct, among which, is the number of requests in the most recent period. To set the threshold;

[0100] In nginx request processing, the problem of duplicate request increment is reduced by optimizing configuration parameters, and a multi-load multi-distribution strategy is adopted to evenly distribute user requests to the backend servers. The distribution algorithm formula is: ,in, For server index, To hash a message, is the total number of servers;

[0101] Furthermore, the overall optimization of the system includes:

[0102] Circuit breaker operation:

[0103] Request quantity monitoring and load limit judgment:

[0104] A request monitoring module is deployed on the server side. This module is responsible for recording and counting the number of requests received by the system. It will count requests according to the set time window (such as the last minute). Every time a new request comes in, the counter will increase by 1. At the same time, the system administrator sets a threshold in advance based on the system performance test and actual operation. This threshold represents the maximum number of requests that the system can withstand. For example, after testing, it is found that the system performance begins to decline when processing 1,000 requests per minute, so the threshold is set to 1,000. The monitoring module will periodically (such as every 10 seconds) check whether the number of requests in the current time window exceeds a certain proportion of the threshold (such as 80%, that is, 800 requests). If it exceeds, it is considered that the system request is close to the load limit.

[0105] To suspend new request processing and user throttling:

[0106] When the system determines that the request is close to the load limit, the request processing entrance of the server will immediately start the restriction mechanism and stop accepting new requests. For newly arrived requests, the server directly returns a friendly prompt page to the user, informing the system that the system is busy and please try again later. At the same time, the system will start the user behavior analysis module, which will record the request history of each user IP and user identity (if the user is logged in). It will calculate the request frequency of each user in a short period of time (such as the past 10 seconds). If the request frequency of a user exceeds the set limit (such as 5 times per second), the user will be marked as a frequent request user. For these frequent request users, the system will take restrictive measures, such as adding their IP addresses to a temporary blacklist and rejecting all requests from the IP in the next period of time (such as 5 minutes); or if the user is logged in, limit the operation permissions of their account within a certain period of time and prohibit them from continuing to make requests to protect system resources from being over-occupied and ensure that the system can provide stable services to other normal users.

[0107] Nginx request processing optimization operations:

[0108] Optimize configuration parameters to reduce repeated request increments:

[0109] Cache configuration adjustment:

[0110] Edit the nginx configuration file, enable and optimize the cache function; determine the types of resources that need to be cached, such as static files (HTML, CSS, JS, images, etc.) and some dynamic data that is not frequently updated (such as some configuration information); set appropriate cache validity periods for different types of resources. For example, for static image resources, set the cache validity period to 1 day according to their update frequency; for CSS and JS files that are not updated frequently, set the cache validity period to 1 hour; configure the cache storage area, you can choose memory cache (such as using nginx's memory area module) or disk cache (specify the cache directory), and reasonably allocate cache space according to the server memory size and disk I / O performance; in this way, when the user requests the cached resource again, nginx can respond quickly directly from the cache, reducing the number of requests to the backend server, thereby reducing the increment of repeated requests;

[0111] Connection timeout and buffer optimization:

[0112] In the nginx configuration file, carefully adjust the connection-related parameters; set the connection establishment timeout to a reasonable value, such as 3 seconds. If a connection cannot be established with the backend server within 3 seconds, nginx will abandon the request to avoid wasting resources due to long waiting times; at the same time, optimize the read timeout and write timeout. According to the average processing time of requests and responses in the business, set the read timeout to 10 seconds and the write timeout to 20 seconds to ensure that during the data transmission process, if there is a network delay or slow processing by the backend server, nginx can release resources in time instead of waiting all the time; in addition, adjust the buffer size parameters, such as setting the client request header buffer size to 4k and the client request body buffer size to 8k. Make reasonable configurations based on the actual request data volume and server memory conditions to avoid memory waste or data transmission problems caused by excessive or too small buffers, improve request processing efficiency, and reduce repeated requests caused by buffer problems;

[0113] The multi-load multi-distribution strategy achieves uniform distribution of requests:

[0114] Request parsing and message construction:

[0115] When a user request reaches the nginx server, nginx first parses the request comprehensively, including the request method (GET, POST, etc.), request URL, request header information (such as User-Agent, Referer, etc.) and request parameters (if any); the parsed information is combined into a message body according to certain rules. For example, the request URL, request method and some key request header information can be concatenated into a string as the message body.

[0116] Hash calculation and server selection:

[0117] Use a pre-selected hash algorithm (such as SHA-256) to hash the constructed message body to obtain a hash value of fixed length; then, perform a modulo operation on this hash value and the total number of backend servers, and calculate the server index according to the distribution algorithm formula; assuming that there are 5 servers in the backend, the calculated hash value is a very large number, and after modulo 5, an index value between 0 and 4 is obtained, which corresponds to the backend server to which the request is to be distributed; in this way, no matter how the specific content of the request changes, the same request (according to the rules for constructing the message body) will always be distributed to the same backend server, and different types of requests can be evenly distributed to each backend server, achieving load balancing, improving the overall processing power and response speed of the system, ensuring that each backend server can reasonably share the workload, and avoiding single-point overload.

[0118] In this embodiment, the message distribution of the queue uses a load balancing algorithm to ensure server load balancing. If a server fails, the tasks on the server are automatically dispatched according to the algorithm. Redistribute to other normal servers, where is the server index after reallocation. The original server index, is the total number of servers. The specific operations are as follows:

[0119] Load balancing message distribution operation:

[0120] Message hash calculation:

[0121] When there is a message in the queue that needs to be distributed to the server for processing, the message is first hashed. A suitable hash algorithm can be selected, such as MD5 or SHA-1. The content of the message (including user request data, order information, etc.) is used as the input of the hash algorithm to calculate a hash value. This hash value is unique and random, and can represent the characteristics of the message to a certain extent.

[0122] Server index determination:

[0123] According to the calculated hash value and the total number of servers, the server index to which the message should be distributed is determined by the message distribution algorithm formula; assuming the total number of servers is, the calculated hash value is, and the modulus is the server index; for example, if there are 3 servers and the hash value is 10, then (modulus operation), the message will be distributed to the server with index 1; this ensures that different messages can be evenly distributed to each server, achieving load balancing, avoiding the situation where some servers are overloaded while other servers are idle, and improving the overall processing efficiency and performance of the system;

[0124] Server troubleshooting operations:

[0125] Fault detection:

[0126] The system will monitor the running status of the server in real time, which can be achieved by regularly sending heartbeat detection signals, monitoring the usage of server resources (such as CPU usage, memory usage, network connection status, etc.) or receiving status reports actively sent by the server. If the heartbeat signal of the server is not received within a certain period of time (such as 5 seconds), or if a key resource of the server is detected to be out of the normal range (such as CPU usage of 100% for more than 1 minute), the system will determine that the server is faulty.

[0127] Task reassignment:

[0128] When a server failure is detected, the system will immediately start the task reallocation mechanism; for tasks that have not been processed on the failed server, they will be reallocated to other normal servers according to the algorithm; assuming that the index of the failed server is and the total number of servers is, the new server index is calculated according to the formula; for example, the original failed server index is 2 and the total number of servers is 4, then the new server index is (modulo operation), that is, these tasks will be assigned to the server with an index of 0; the system will automatically remove the tasks on the failed server from the original queue and add them to the task queue corresponding to the newly assigned server to ensure that the tasks can continue to be processed without affecting the overall operation of the system, thereby improving the reliability and fault tolerance of the system.

[0129] In this embodiment, when the server processes concurrent requests, it uses the token bucket algorithm to limit the flow, and the formula is: ,in, is the number of requests allowed to pass, is the number of tokens in the token bucket, The maximum number of requests allowed per second. The thread pool technology is used at the same time. Its size is determined by the system configuration and actual load according to the algorithm. Dynamic adjustment, where is the thread pool size, is the maximum thread pool size, is the current number of requests, is the average request processing time, is the safety factor.

[0130] In this embodiment, the server uses a message compression algorithm when packaging user request data into messages. ,in, is the compressed message, It is the original message data, and uses technologies including long connection and data caching to optimize network transmission in data interaction.

[0131] In this embodiment, the server uses an optimistic locking algorithm when checking the inventory of goods. The algorithm formula is: ,in, For the inventory after inspection, To check the inventory before, When checking the inventory for the user's purchase quantity, first obtain the current inventory value and calculate the inventory value after purchase. If the calculated inventory value is greater than or equal to 0, the order is allowed, otherwise it is determined that the inventory is insufficient.

[0132] As a preferred solution, the server uses the corresponding algorithm according to the promotion rules when calculating the price. If it is a full discount rule, the calculation method is ,in, For the final price, For the original price, The discount rate is determined according to the full-discount rule.

[0133] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for processing promotion rush purchases under high concurrency, characterized by: Including user-side operations and server-side operations; User-side operations include: After the user selects a product in the promotion section and adds it to the shopping cart, the user submits the order, collects product-related information and generates a listening token, sends a request containing product data and a listening token to the server through the HTTP protocol, and starts polling the listening token to obtain a response at a fixed period T, T=500ms; The operation result is determined based on the code in the token returned by the server. If code=200, the order success page and order information are displayed. If code=400 and the message contains "Insufficient stock", it indicates insufficient stock. If code=500, an error message is displayed. Server operations include: Receive user request, perform user identity authentication, product inventory check, price calculation, start asynchronous process to package user request data into messages and add them to queue, distribute queue messages to different servers for consumption. The algorithm formula for distributing messages to servers is: ,in, For server index, To hash a message, is the total number of servers; During the message consumption process, the results including successful order placement, insufficient inventory, and abnormalities are packaged and stored in the listening token. When the token is detected to have updated content, the information in the token is returned to the user end through HTTP response. The encryption algorithm is used when the results are packaged and stored in the token. ,in, For the encrypted data, For the result data that needs to be stored, Is the encryption key.

2. The method for processing promotion rush purchases under high concurrency according to claim 1, characterized in that: It also includes cache preloading. The cache preloading steps are as follows: The management backend writes the active product inventory into the REDIS cache, reads the cache first, releases the inventory using an asynchronous multi-process approach, and writes and reads the inventory in accordance with the algorithm And the rule of checking the cache first and then the database, when writing, For the inventory in the cache, For the inventory in the database; Static caching is used for front-end product images and page layouts, and dynamic caching strategy is used for dynamic content. The calculation formula for cache validity period is: ,in, is the cache validity period, is the basic time constant, To update the frequency according to the data Dynamically adjusted function, when When high, Small value, Short; when When low, the value ambassador long.

3. The method for processing promotion rush purchases under high concurrency according to claim 2, characterized in that: It also includes overall system optimization, which includes a fuse mechanism. When the system request is close to the load limit, it will suspend processing new requests, limit the IP and identity of users who frequently initiate requests, and judge that the request is close to the load limit through an algorithm. Conduct, among which, is the number of requests in the most recent period. To set the threshold; In nginx request processing, the problem of duplicate request increment is reduced by optimizing configuration parameters, and a multi-load multi-distribution strategy is adopted to evenly distribute user requests to the backend servers. The distribution algorithm formula is: ,in, For server index, To hash a message, is the total number of servers.

4. The method for processing promotion rush purchases under high concurrency according to claim 1, characterized in that: The message distribution of the queue uses a load balancing algorithm to ensure server load balancing. If a server fails, the tasks on the server will be automatically dispatched according to the algorithm. Redistribute to other normal servers, where is the server index after reallocation. The original server index, is the total number of servers.

5. The method for processing promotion rush purchases under high concurrency according to claim 1, characterized in that: When the server processes concurrent requests, it uses the token bucket algorithm to limit the flow. The formula is: ,in, is the number of requests allowed to pass, is the number of tokens in the token bucket, The maximum number of requests allowed per second. The thread pool technology is used at the same time. Its size is determined by the system configuration and actual load according to the algorithm. Dynamic adjustment, where is the thread pool size, is the maximum thread pool size, is the current number of requests, is the average request processing time, is the safety factor.

6. The method for processing promotion rush purchases under high concurrency according to claim 1, characterized in that: The server uses a message compression algorithm when packaging user request data into messages. ,in, is the compressed message, It is the original message data, and uses technologies including long connection and data caching to optimize network transmission in data interaction.

7. The method for processing promotion rush purchases under high concurrency according to claim 1, characterized in that: When checking the inventory of goods, the server uses an optimistic locking algorithm, and the algorithm formula is: ,in, For the inventory after inspection, To check the inventory before, When checking the inventory for the user's purchase quantity, first obtain the current inventory value and calculate the inventory value after purchase. If the calculated inventory value is greater than or equal to 0, the order is allowed, otherwise it is determined that the inventory is insufficient.

8. The method for processing promotion rush purchases under high concurrency according to claim 1, characterized in that: When calculating the price, the server uses the corresponding algorithm according to the promotion rules. If it is a full discount rule, the calculation method is ,in, For the final price, For the original price, The discount rate is determined according to the full-discount rule.

Images