Method, system and equipment for processing seckilling request and storage medium

Abstract

The invention discloses a seckilling request processing method and system, equipment and a storage medium. The method comprises the following steps: when a plurality of seckilling requests sent by a plurality of clients in parallel are received, firstly performing peak clipping processing on the plurality of seckilling requests based on preset concurrent parameters to obtain a plurality of candidate requests, and performing current limiting and multi-dimensional filtering processing on the plurality of candidate requests based on a bucket algorithm and a request filtering strategy to obtain a plurality of effective requests. And then, based on the number of the plurality of effective requests, performing inventory deduction on an inventory list in the Redis through an LPOP instruction, generating reserved orders corresponding to the plurality of effective requests, and binding the reserved orders with corresponding user accounts. And finally, when the user account bound with the reserved order initiates a payment request, processing the payment request. According to the method, the overload risk caused by the fact that flow impact exceeds expectation of the system can be reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a method, system, device, and storage medium for processing flash sale requests. Background Technology

[0002] Flash sales, a widely used promotional strategy in e-commerce, place specific demands on application system architecture due to their extremely short time window and limited product inventory. Therefore, once the event starts, the e-commerce platform's backend system must be capable of handling the sudden surge in concurrent traffic to ensure stable service operation when a massive number of users simultaneously launch their purchase requests.

[0003] For these types of instantaneous high-concurrency scenarios, most rely on message queue middleware such as RocketMQ to process requests. However, this approach only plays a passive buffering role and cannot perform fine-grained control and rate limiting of concurrent requests at the traffic entry point. As a result, the system still faces the risk of service overload once it encounters an unexpected traffic surge.

[0004] Therefore, how to implement more refined traffic control and rate limiting strategies in flash sale activities to cope with traffic surges in ultra-high concurrency scenarios is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method, system, device, and storage medium for processing flash sale requests. This allows for more refined traffic control and rate limiting strategies during flash sale activities, enabling responses to traffic surges in high-concurrency scenarios and reducing the risk of system overload.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] A method for processing flash sale requests, the method comprising:

[0008] In response to multiple flash sale requests sent in parallel by multiple clients, the multiple flash sale requests are processed based on preset concurrency parameters to obtain multiple candidate requests; the flash sale requests are obtained by encapsulating user request parameters; the user request parameters include user ID, target product ID and request timestamp;

[0009] Based on the bucket algorithm and request filtering strategy, the multiple candidate requests are rate-limited and multi-dimensionally filtered to obtain multiple valid requests.

[0010] Based on the number of valid requests, the LPOP command is used to deduct inventory from the inventory list in the remote dictionary server Redis and generate a reserved order corresponding to each of the valid requests. The reserved order is then bound to the corresponding user account. The inventory list records the target product ID and the inventory quantity of the target product.

[0011] In response to a payment request initiated by a user account linked to a reserved order, the payment request is processed.

[0012] In one possible implementation, the bucket algorithm and request filtering strategy are used to perform rate limiting and multi-dimensional filtering on the multiple candidate requests to obtain multiple valid requests, including:

[0013] Based on the pre-set token bucket capacity, the multiple candidate requests are filtered and tokens are allocated to obtain multiple initial screening requests; the initial screening requests are candidate requests carrying identity tokens.

[0014] Key fields are extracted from the multiple initial screening requests to obtain multiple key fields corresponding to each initial screening request.

[0015] Each candidate request is validated in multiple dimensions based on the multiple key fields corresponding to each initial screening request.

[0016] Requests that pass the initial screening through the multi-dimensional verification will be determined as valid requests.

[0017] In one possible implementation, the multiple key fields include the client's real Internet Protocol IP address, identity token, the request timestamp, and the user ID;

[0018] The process of performing multi-dimensional verification on each candidate request based on multiple key fields corresponding to each initial screening request includes:

[0019] For each of the initial screening requests, the following multi-dimensional verifications are performed:

[0020] The identity validity of the initial screening request is verified based on the identity token of the initial screening request.

[0021] If the identity validity verification passes, the initial screening request is then time-validated based on the request timestamp of the initial screening request; wherein, the time validity verification passes when the difference between the request timestamp and the current time is less than a time difference threshold.

[0022] If the time validity verification passes, the request frequency of the initial screening request is calculated based on the user ID and the client's real IP of the initial screening request.

[0023] If the request frequency is less than the frequency threshold, then query the activity status key in Redis;

[0024] If the value of the activity status key is the first flag bit, then the multi-dimensional verification of the initial screening request is confirmed to have passed; otherwise, the multi-dimensional verification of the initial screening request is confirmed to have failed.

[0025] In one possible implementation, processing the payment request includes:

[0026] Obtain the request time interval; the request time interval includes the time from the start of the reserved order generation to the generation of the payment request;

[0027] If the requested time interval does not exceed the order expiration time, the payment request is confirmed as valid and payment is processed, and the order status of the reserved order is updated to paid.

[0028] In one possible implementation, after processing the payment request, the method further includes:

[0029] Convert successfully paid reserved orders into target orders;

[0030] Generate structured voucher data for the target order; the structured voucher data includes fields such as qualification ID, user ID, target product ID, and expiration time;

[0031] The actual inventory is allocated to the target order based on the structured voucher data.

[0032] In one possible implementation, the method further includes:

[0033] Based on a pre-set inventory allocation and sorting strategy, actual inventory is allocated sequentially to each of the target orders.

[0034] The inventory allocation sorting strategy includes sorting by the time the request arrives at the gateway; or sorting by membership level; or sorting using a completely random fair allocation mode.

[0035] In one possible implementation, when the flash sale is in progress, the value of the activity status key in Redis is the first flag bit; otherwise, it is another flag bit.

[0036] A system for processing flash sale requests, the system comprising: a web server and a microservice gateway; the web server being connected to the microservice gateway; the web server being configured with concurrency parameters; and the microservice gateway being configured with a bucket algorithm.

[0037] The web server is used to: respond to multiple flash sale requests sent in parallel by multiple clients, perform peak shaping on the multiple flash sale requests based on the concurrency parameters to obtain multiple candidate requests; the flash sale requests are obtained by encapsulating user request parameters; the user request parameters include user ID, target product ID and request timestamp;

[0038] The microservice gateway is used to: perform rate limiting and multi-dimensional filtering on the multiple candidate requests based on the bucket algorithm and request filtering strategy to obtain multiple valid requests; deduct inventory from the inventory list in Redis using the LPOP command based on the number of valid requests and generate reserved orders corresponding to each of the multiple valid requests, and bind the reserved orders to the corresponding user accounts; the inventory list records the target product ID and the inventory quantity of the target product; in response to a payment request initiated by the user account bound to the reserved order, obtain the request time interval; the request time interval includes the time from the start of the reserved order generation to the generation of the payment request; if the request time interval does not exceed the order expiration time, the payment request is confirmed as valid and payment is processed, and the order status of the reserved order is updated to paid.

[0039] A device for processing flash sale requests includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the flash sale request processing method described above.

[0040] A computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to perform the processing method for the flash sale request as described above.

[0041] Compared with the prior art, this application has the following advantages:

[0042] This application provides a method, system, device, and storage medium for processing flash sale requests. Specifically, when executing the flash sale request processing method provided in this application embodiment, firstly, when the system receives flash sale requests sent simultaneously by multiple clients, it performs peak smoothing processing on these initial requests based on pre-configured concurrency parameters (such as the single batch request processing limit, server concurrency carrying threshold, etc.), that is, filtering out excessive requests that exceed the system's short-term carrying capacity, and retaining only requests that meet the basic flow control standards as candidate requests. Each flash sale request is generated by encapsulating core request parameters submitted by the user. These parameters include a user identifier (ID) (used to locate the user initiating the request), a target product ID (identifying the product to be purchased), and a request timestamp (used for subsequent time validity verification), ensuring that the request carries complete business identification information. Next, for the selected candidate requests, the system combines a bucket algorithm and a request filtering strategy to carry out dual control: on the one hand, the bucket algorithm achieves fine-grained rate limiting to avoid request overload within a unit of time; on the other hand, multi-dimensional filtering eliminates invalid and abnormal requests, ultimately selecting valid requests that meet all business rules from the candidate requests. Subsequently, based on the number of valid requests, the system invokes the atomic LPOP (Left Pop) command in the remote dictionary server (Redis) to deduct inventory from the inventory list. This atomic operation completely avoids the overselling problem caused by multiple concurrent requests. Simultaneously, a dedicated reserved order is generated for each valid request and bound to the user account that initiated the request, ensuring traceability of subsequent transactions. Finally, when the user account bound to the reserved order initiates a payment request, the system responds immediately and executes the corresponding payment processing flow, completing the closed loop of the flash sale transaction.

[0043] This application employs peak-shaving based on preset concurrency parameters, combined with bucket algorithms and request filtering strategies, to perform fine-grained rate limiting and multi-dimensional filtering of flash sale requests, effectively reducing the risk of system overload caused by request surges. By managing the number of concurrent requests in advance, system load can be better balanced, ensuring the stable operation of the flash sale under high concurrency. Simultaneously, through a Redis-based inventory deduction mechanism, inventory can be quickly deducted from the inventory list, generating corresponding reserved orders. This process is efficient and atomic, avoiding overselling of inventory or inconsistent order statuses, thus improving system response speed and user experience. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in this embodiment or the prior art, the drawings used in the description of the embodiment or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 A flowchart illustrating a method for processing a flash sale request, provided in an embodiment of this application;

[0046] Figure 2 A flowchart illustrating a request rate limiting and multi-dimensional filtering method provided in this application embodiment;

[0047] Figure 3 A flowchart illustrating a multi-dimensional verification method for a request, provided in an embodiment of this application;

[0048] Figure 4 This is a schematic diagram of the structure of a system for processing flash sale requests provided in an embodiment of this application. Detailed Implementation

[0049] To facilitate understanding of the technical solutions provided in the embodiments of this application, the background technology involved in the embodiments of this application will be described below.

[0050] Flash sales, a common promotional method, place stringent demands on e-commerce platform architecture due to the characteristic of a large number of users vying for limited goods within a very short period. The time window for flash sales is extremely narrow, and inventory is limited. Therefore, when a flash sale begins, the platform's backend system must be able to handle the sudden surge in concurrent request traffic to ensure stable service even when a large number of users are simultaneously participating in the purchase.

[0051] To cope with this high concurrency pressure, the industry generally adopts a strategy of decoupling and asynchronously processing the confirmation of purchase eligibility and the subsequent order placement and payment process. This architectural design allows the system to buffer peak request traffic, effectively distributing the load and improving overall availability. However, most existing solutions rely on message queue middleware (such as RocketMQ) to handle asynchronous processing, but this approach has two significant bottlenecks. First, the operation and maintenance of message queue clusters is complex and incurs additional resource consumption, resulting in high costs. More importantly, message queue solutions are typically just a passive buffering mechanism, lacking the ability to fine-tune and rate-limit concurrent requests at the traffic entry point. This means that when faced with unexpectedly high concurrency requests, the system may still crash due to overload, failing to effectively guarantee the smooth operation of the flash sale.

[0052] To address this issue, this application provides a method, system, device, and storage medium for processing flash sale requests. When multiple clients send flash sale requests in parallel, the system first smooths out the requests using preset concurrency parameters, filtering out multiple candidate requests. Each flash sale request is encapsulated based on the user's request parameters (including user ID, target product ID, and request timestamp). Based on this, a bucket algorithm and request filtering strategy are used to rate limit and filter candidate requests from multiple dimensions, obtaining valid requests. Then, based on the number of valid requests, the system deducts inventory from the Redis inventory list using the LPOP command, generates a corresponding reserved order for each valid request, and binds these reserved orders to the user account. Finally, when the user account initiates a payment request, the system processes the payment request and ensures the successful completion of the order. This application achieves refined traffic control and request management through steps such as peak shaving based on concurrency parameters, rate limiting using bucket algorithms and request filtering strategies, multi-dimensional filtering, and Redis inventory deduction. This effectively avoids the overload risk caused by extremely high concurrency, improves system stability and processing efficiency, and reduces the operational complexity and resource costs associated with message queues. Furthermore, the Redis-based inventory deduction mechanism avoids overselling of inventory or inconsistent order statuses, thereby improving system response speed and user experience. In addition, this application does not rely on complex message queue clusters. By using Redis for inventory management and reserved order binding, the system architecture is simplified, dependence on message queue middleware is reduced, operational costs and system complexity are lowered, and the system becomes more maintainable.

[0053] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0054] See Figure 1 The figure is a flowchart of a method for processing flash sale requests provided in an embodiment of this application, as shown below. Figure 1 As shown, the processing method for this flash sale request may include steps S101-S104:

[0055] S101: In response to multiple flash sale requests sent in parallel by multiple clients, the multiple flash sale requests are processed by peak shaving based on preset concurrency parameters to obtain multiple candidate requests.

[0056] During a flash sale, when multiple clients send a large number of requests in parallel, the system first needs to perform peak smoothing based on preset concurrency parameters to prevent the system from crashing or responding too slowly due to excessive concurrent requests. The purpose of peak smoothing is to control the request traffic within the system's capacity. Each flash sale request is encapsulated with user request parameters, mainly including the user ID, the target product ID, and the request timestamp, ensuring that the source, product information, and initiation time of each request can be accurately identified and managed.

[0057] It's important to note that a flash sale request structure includes a request header and a request body. The request header typically contains common metadata, such as the request content type, authorization information (e.g., token), the client's real Internet Protocol (IP), client type, and request ID. The request body, on the other hand, contains specific business data, such as the user ID, target product ID, and request timestamp. The data in the request body helps the system identify the user initiating the request, the target product, and the time the request was initiated.

[0058] In one possible implementation, concurrency parameters include the number of processes and the maximum number of connections per process. The number of processes controls the number of requests the system can handle simultaneously, and is typically set based on the server's hardware resources (such as the number of CPU cores). Each process is responsible for handling a certain number of requests, while the maximum number of connections per process limits the number of connections each process can maintain simultaneously, preventing any single process from becoming overloaded. By properly configuring the number of processes and the maximum number of connections, the system can ensure resource utilization while avoiding performance bottlenecks or service unavailability caused by excessive concurrent requests. The settings for the number of processes and the maximum number of connections need to be dynamically adjusted based on actual business needs, system load, and network bandwidth to ensure the system can still operate smoothly under high concurrency.

[0059] S102: Based on the bucket algorithm and request filtering strategy, rate limiting and multi-dimensional filtering are performed on the multiple candidate requests to obtain multiple valid requests.

[0060] In high-concurrency scenarios, to ensure system stability and responsiveness, the system can employ bucket algorithms and request filtering strategies to perform rate limiting and multi-dimensional filtering on multiple candidate requests. The bucket algorithm distributes requests into multiple "buckets," limiting the number of requests within each bucket, thus effectively preventing resource contention or system crashes caused by a large influx of requests simultaneously. Whenever a request arrives, the system distributes it into different buckets according to preset rules and controls the processing speed and concurrency by monitoring the number of requests within each bucket.

[0061] In addition, the request filtering strategy further filters candidate requests from multiple dimensions, potentially removing invalid or unreasonable requests based on factors such as the request's token, timestamp, request source, and request frequency. For example, the system can determine whether a request is within a valid time window based on its timestamp, or determine whether it originates from malicious order-brushing behavior based on request frequency.

[0062] Finally, after the bucket algorithm and multi-dimensional filtering, the system can obtain multiple valid requests, which will enter the next processing stage, thereby ensuring the fairness of the flash sale and the stability of the system.

[0063] S103: Based on the number of the multiple valid requests, the inventory list in Redis is deducted using the LPOP command, and a reserved order corresponding to each of the multiple valid requests is generated. The reserved order is then bound to the corresponding user account.

[0064] When processing multiple valid requests, the system analyzes the number of valid requests and uses the LPOP command in Redis to deduct the corresponding amount of inventory from the inventory list, ensuring that each request receives the corresponding product inventory. The inventory list is a queue maintained in Redis that records the ID of the target product and its current inventory quantity. Once a valid request is confirmed, the system removes the corresponding amount of product inventory from the inventory list using the LPOP command. This ensures that the inventory quantity matches the actual purchase request, preparing for subsequent order processing and shipping. The LPOP command is an atomic operation command in Redis for list-type data, specifically removing and returning the first element from the left side of the list.

[0065] Next, the system generates a reserved order for each valid request and binds the reserved order to the corresponding user's account. This ensures that every user's flash sale request is processed and that each order is accurately associated with the user's information. This approach enables rapid inventory updates and avoids overselling under concurrent conditions, ensuring the fairness of the flash sale and the efficiency of the system.

[0066] In one possible implementation, reserved orders are stored in a database (such as MySQL) for persistent storage and transaction management, ensuring that the reserved orders remain valid even after a system restart or in the event of an anomaly. Reserved orders include the following:

[0067] order_token: Reserved order identifier, used to uniquely identify each reserved order, ensuring that the order can be accurately found and processed in subsequent operations;

[0068] user_id: User ID, which identifies the user who initiated the reservation order. It is used to associate the user account and ensure that the order can be correctly bound to the corresponding user.

[0069] goods_id: The target product ID, which identifies the product the user requests to purchase, ensuring that inventory and order information can be correctly matched;

[0070] status: The initial status is RESERVED, which means that the order is in the reservation stage and payment or shipment has not yet been completed;

[0071] expire_time: Reserved order expiration time (e.g., 5 minutes). This means that if the user does not complete the payment within the specified time, the order will automatically expire and the inventory will be released.

[0072] Storing reserved orders in a database (such as MySQL) ensures the persistence and consistency of order information. Furthermore, transaction management ensures that all related operations are executed atomically during order creation, payment, and expiration, preventing data inconsistency or loss. In addition, order data in the database can be easily queried, updated, and expired, providing strong support for order management and inventory control.

[0073] S104: In response to a payment request initiated by a user account bound to a reserved order, process the payment request.

[0074] When a user account initiates a payment request, the system processes the payment based on the user account information linked to the reserved order. First, the system verifies whether the payment request is associated with a valid reserved order by querying the user's account information and the reserved order. After ensuring the request's legality and accuracy, the system further processes the payment request. This process includes checking if the time interval exceeds the order expiration time. If it does not exceed the expiration time, the system will process the payment through the integrated payment interface, deducting the corresponding amount from the user's account and updating the payment status of the reserved order to ensure successful payment and entry into the shipping process. If the payment request fails verification, the system will return an error message to the user, requiring them to re-verify the payment information or select an alternative payment method. The entire payment processing process must ensure efficiency, security, and data consistency and accuracy.

[0075] Based on the content of S101-S104, the system first processes the concurrent requests from multiple clients, using preset concurrency parameters to smooth out peak traffic and filter out candidate requests. Next, the system uses a bucket algorithm and request filtering strategies to rate limit and filter candidate requests from multiple dimensions, thereby obtaining multiple valid requests. Then, based on the number of valid requests, the system uses the LPOP command to deduct inventory from the Redis inventory list and generates a corresponding reserved order for each valid request, while binding these orders to user accounts. Finally, when a user account bound to a reserved order initiates a payment request, the system processes the payment according to the reserved order. This application can reduce the risk of system overload caused by unexpected traffic surges, and can quickly and atomically deduct from the inventory list and generate corresponding reserved orders to avoid overselling or inconsistent order statuses, significantly improving the user experience.

[0076] In one possible implementation, such as Figure 2 As shown, step S102 performs rate limiting and multi-dimensional filtering on the multiple candidate requests based on the bucket algorithm and request filtering strategy to obtain multiple valid requests, which can be achieved through steps S201-S204:

[0077] S201: Based on the pre-set token bucket capacity, the multiple candidate requests are filtered and tokens are allocated to obtain multiple initial screening requests.

[0078] Based on a pre-set token bucket capacity (e.g., 2000), the system first filters multiple candidate requests. Due to the token bucket's capacity limitation, if the total number of candidate requests exceeds the token bucket capacity, the system will use algorithms such as hashing to filter the multiple candidate requests based on the token bucket capacity. For example, with 3000 candidate requests, the system will use hashing algorithms to filter out 2000 requests from these 3000 requests to ensure that the number of requests the system can handle does not exceed the token bucket capacity. This process controls the rate of concurrent requests through the token bucket algorithm, preventing the system from overloading under high concurrency. For the filtered initial requests, the system assigns a valid identity token to each request to verify the legitimacy of the requester, ensuring that the request comes from an authorized user. Candidate requests after token allocation are marked as initial screening requests and enter the subsequent verification and processing flow. In this way, the system not only ensures the fairness of request processing but also improves security, avoids abuse and unauthorized access, and optimizes the efficiency of request processing.

[0079] S202: Extract key fields from the multiple initial screening requests to obtain multiple key fields corresponding to each initial screening request.

[0080] When extracting key fields from multiple initial screening requests, the system extracts several important fields from each request. These fields are crucial for subsequent verification and processing. Specifically, the key fields extracted by the system include the client's real IP address, client type, identity token, request timestamp, and user ID. The client's real IP address helps determine the physical location of the request source, thus preventing malicious attacks or IP spoofing; the client type can be used to identify the type of device from which the request originated (such as a mobile phone, computer, etc.), for analyzing user behavior patterns; the identity token is used to verify the identity of the requester, ensuring that the request comes from a legitimate user; the request timestamp records the specific time the request was initiated, helping to determine the timeliness and sequence of the requests; and the user ID is a unique identifier for the user in the system, used to associate the user's historical data or behavior. By extracting these key fields, the system can better understand the background of each request, providing basic data for subsequent multi-dimensional verification.

[0081] S203: Perform multi-dimensional verification on each candidate request based on the multiple key fields corresponding to each initial screening request.

[0082] Based on multiple key fields corresponding to each initial screening request, the system performs multi-dimensional verification on each candidate request to ensure that each request complies with the system's security and business rules. During the verification process, the system comprehensively analyzes information such as the client's real IP address, client type, identity token, request timestamp, and user ID. For example, the system can check whether a user's historical behavior matches expectations based on the client's real IP address and user ID to prevent the same user from performing abnormally frequent operations; the request timestamp determines whether the request is within a reasonable time window to avoid timeliness issues; the identity token verifies whether the requester is a legitimate user to prevent unauthorized access; and the client type can be used to analyze whether there is any bot activity. Furthermore, the system checks whether the user ID matches their behavioral data to prevent account abuse or theft. Through this multi-dimensional verification, the system can further filter out requests that do not comply with the rules or pose a risk, ensuring that the requests that ultimately enter the processing flow are legitimate, valid, and secure.

[0083] S204: The initial screening request that passes the multi-dimensional verification is determined to be a valid request.

[0084] A request is considered valid if it meets all the predetermined rules and standards across all validation dimensions. Valid requests must undergo rigorous checks in areas such as identity verification, behavioral analysis, and request timing to ensure that the request originates from a legitimate user and exhibits no abnormal behavior. This process not only enhances the legitimacy of requests but also ensures the security and efficiency of the system when processing requests. Ultimately, all requests that pass the initial screening through multi-dimensional validation will be marked as valid and allowed to proceed to subsequent processing stages, ensuring that system resources are allocated reasonably and fairly to genuine users and preventing non-compliant requests from consuming system resources.

[0085] Through steps S201-S204, the system can effectively filter out malicious requests, overclocking requests, and requests that do not meet the conditions, ensuring that only valid requests that meet the business rules can enter the subsequent processing flow, thereby improving the stability and efficiency of the system.

[0086] In one possible implementation, the multiple key fields include the client's real IP address, identity token, the request timestamp, and the user ID.

[0087] In one possible implementation, such as Figure 3 As shown, step S203 performs multi-dimensional verification on each candidate request based on multiple key fields corresponding to each initial screening request. This can be implemented through steps S301-S305, specifically performing the following multi-dimensional verification on each initial screening request:

[0088] S301: Verify the identity validity of the initial screening request based on the identity token of the initial screening request.

[0089] Based on the identity token in the initial screening request, the system verifies the identity validity of the request. If the request contains a valid identity token, the system will determine that the request comes from an authorized user and pass the identity validity verification; otherwise, if the request lacks an identity token or the token is invalid, the system will consider the authentication of the request to have failed and thus reject the request from further processing. In this way, the system can effectively identify and filter unauthorized requests, ensuring that only authorized users can access system resources.

[0090] S302: If the identity validity verification passes, then the initial screening request is time-validated based on the request timestamp of the initial screening request.

[0091] If the identity verification passes, the system will continue with time validity verification based on the request timestamp from the initial screening request. Specifically, the system calculates the difference between the request timestamp and the current time (i.e., the computer's local time) and compares it with a preset time difference threshold (e.g., 5 seconds). If the difference between the request timestamp and the current time is less than the threshold, it means the request was initiated within a reasonable time frame and meets the time validity requirements, thus passing the verification. If the difference exceeds the threshold, the request is considered to have exceeded the valid time window, the time validity verification fails, and the system will reject the request. Through this verification method, the system can ensure the timeliness of requests and prevent expired requests from being processed.

[0092] S303: If the time validity verification passes, the request frequency of the initial screening request is calculated based on the user ID and the client's real IP of the initial screening request.

[0093] If the time validity verification passes, the system will continue with further frequency analysis based on the user ID and the client's real IP address from the initial screening request. Specifically, the system will count the number of requests initiated by that user or IP address within a unit of time, based on the user ID and client IP address, thereby calculating the request frequency. This frequency value reflects the activity level of the user or client within a short period, helping the system identify any abnormal behavior, such as malicious attacks or fraudulent transactions. By calculating the request frequency, the system can effectively monitor the rationality and abnormal fluctuations of requests, and then take corresponding security measures.

[0094] S304: If the request frequency is less than the frequency threshold, then query the activity status key in Redis.

[0095] If the request frequency is less than the set frequency threshold, the system will further query the activity status key in the Redis database to confirm whether the request meets the conditions for continuing processing. Querying the activity status key is to obtain the current activity status of the user or client in the system, ensuring that their behavior is not abnormal or outside the normal range. The value of the activity status key typically reflects the status of the flash sale, such as whether it is currently in a flash sale or has ended.

[0096] S305: If the value of the activity status key is the first flag bit, then the multi-dimensional verification of the initial screening request is confirmed to be successful; otherwise, the multi-dimensional verification of the initial screening request is confirmed to be unsuccessful.

[0097] If the retrieved activity status key value is the first flag (e.g., 1), the system confirms that the initial screening request has passed multi-dimensional verification, indicating that the request meets all the conditions stipulated by the system, the current activity (e.g., a flash sale) is still ongoing, and the user's behavior is reasonable. Therefore, the system allows the request to continue processing. Conversely, if the activity status key value is not the first flag, the system considers the request to have failed multi-dimensional verification, possibly because the flash sale has ended or the user's request does not meet the conditions of the current activity. Therefore, the request will be rejected to prevent invalid or non-compliant requests from impacting system resources. In this way, the system can ensure that it only responds to requests that meet the activity conditions, thereby optimizing resource allocation and protecting the system from abuse.

[0098] Steps S301-S305 ensure that the initial screening request undergoes comprehensive and rigorous verification before entering subsequent processing, thereby improving the reliability and security of the system.

[0099] In one possible implementation, the multiple key fields also include client type. If the client type is abnormal or represents a non-human, normal operation, it is considered that there is a problem with bot-driven order manipulation, and the multi-dimensional verification of the initial screening request still fails. By checking the client type, the system can effectively identify and prevent order manipulation initiated through bot scripts or automated means, ensuring that only real users participate in the flash sale, thereby guaranteeing the fairness and security of the flash sale.

[0100] In one possible implementation, processing the payment request in step S104 includes:

[0101] The request time interval is obtained, wherein the request time interval includes the time from the start of the reserved order generation to the generation of the payment request. If the request time interval does not exceed the order expiration time, the payment request is confirmed as valid and payment processing is performed, and the order status of the reserved order is updated to paid.

[0102] Specifically, the system first calculates the request time interval, which is the total time from the generation of the reserved order to the completion of the payment request. This time interval is crucial for determining whether the order is still valid. If the request time interval does not exceed the order's expiration time, the system considers the payment request still valid and begins the payment processing flow. During the payment process, the system first calls the payment gateway to complete the deduction operation. This step ensures that the user's payment behavior is executed correctly, and the payment amount is deducted from the user's account. After successful payment, the system updates the reserved order status to "paid" and generates a settlement order, ensuring that the order's payment information is officially confirmed. The settlement order is persistently stored in the database to ensure long-term data availability.

[0103] Simultaneously, upon successful payment, the system triggers an automated logistics process to create a corresponding shipping order, preparing for subsequent goods shipment. This seamlessly integrates the payment, order confirmation, and shipping processes, improving transaction efficiency and ensuring timely order fulfillment.

[0104] In this way, the system not only ensures the validity and security of payments, but also improves the overall business flow efficiency and user experience through automated order processing and logistics management.

[0105] In one possible implementation, after processing the payment request, the method further includes:

[0106] The successfully paid reserved orders are converted into target orders. Then, structured voucher data is generated for the target orders, including fields such as qualification ID, user ID, target product ID, and expiration time. Finally, based on the structured voucher data, actual inventory is allocated to the target orders, and the inventory status is updated to sold.

[0107] Specifically, firstly, successfully paid reserved orders are converted into target orders. This step aims to confirm that the payment status of the order has been verified and the payment transaction is valid, thus laying the foundation for subsequent processing. Next, the system generates structured credential data for the target order. This data contains several key information fields, such as eligibility ID, user ID, target product ID, and expiration time (e.g., 15 minutes). These fields play a crucial role throughout the order fulfillment process, especially in ensuring that the order is processed and completed within the valid timeframe.

[0108] The generated structured voucher data is used for further inventory allocation. Based on this data, the system allocates actual inventory to the target order and updates the inventory status of the corresponding product to "sold." This process ensures that inventory is promptly deducted from the system after successful order payment, avoiding overselling or inventory errors. Furthermore, updating the inventory status to "sold" helps maintain the accuracy of inventory management, preventing multiple orders from simultaneously requesting inventory for the same product.

[0109] Through this process, the system can effectively manage order payment, inventory, and product information, ensuring the smooth completion of each transaction. Inventory information can also be updated in real time, thereby improving order processing efficiency and the user's purchasing experience.

[0110] In one possible implementation, the method further includes:

[0111] Based on a pre-set inventory allocation and sorting strategy, actual inventory is allocated to each target order in sequence. This inventory allocation process is to ensure that inventory resources are allocated fairly and reasonably to each order, and to prevent one party's user from being unable to successfully purchase goods due to insufficient inventory.

[0112] Inventory allocation and sorting strategies can take several forms. The first strategy is to sort requests according to the time they arrive at the gateway, i.e., first-come, first-served, allocating inventory based on the order of payment requests. This method ensures that users who submit payment requests first receive product inventory first during order processing.

[0113] The second strategy is to prioritize users by membership level, allocating inventory based on their membership tier or points. Typically, higher-level members or users with high points receive priority access to inventory, thus increasing user satisfaction and encouraging membership program activity.

[0114] The third strategy is to use a completely random and fair allocation model for sorting. This method ensures that every user has an equal opportunity to obtain inventory through random selection. This approach avoids the unfairness caused by over-reliance on time-based sorting or membership levels, ensuring that users at different levels can participate in the product purchase process fairly.

[0115] Regardless of the strategy adopted, the ultimate goal is to ensure the reasonable and fair allocation of inventory resources, while avoiding user complaints and disputes caused by unfair allocation or insufficient inventory.

[0116] In one possible implementation, when the flash sale is in progress, the value of the activity status key in Redis is the first flag bit; otherwise, it is another flag bit.

[0117] Specifically, during the flash sale, the system uses the value of the activity status key in Redis to indicate whether the activity is in progress. When the flash sale is in progress, the value of the activity status key stored in Redis is set to the "first flag," indicating that the activity is ongoing. The system will trigger a series of activity-related operations based on this status value. For example, if a user can participate in the purchase, the system will determine whether to allow the user to submit an order and allocate inventory based on the activity status.

[0118] If the flash sale is not in progress, the activity status key will be set to another flag, such as "end flag" or "pause flag". This flag indicates that the activity has ended or is temporarily paused. The system will use this status value to prevent users from taking further actions, such as submitting orders or participating in the flash sale, to ensure that actions during the activity comply with business rules.

[0119] In this way, Redis, as a high-speed caching storage system, plays a crucial role in flash sales, enabling real-time updates to the event status and timely responses to different business needs. The dynamic identification of the event status provides the system with flexible control methods, ensuring the smooth operation of the flash sale and preventing system chaos or user dissatisfaction caused by status errors.

[0120] In one possible implementation, the method further includes:

[0121] If payment fails, roll back the order status and release the inventory.

[0122] Specifically, when a payment fails, the system will execute a series of remedial measures to ensure the accuracy of order and inventory status:

[0123] First, the system will roll back the order status, restoring orders that were originally in the "pending payment" or "paid" state to the "payment failed" or "pending payment" state. This ensures that the order status is updated promptly, guaranteeing that subsequent order processing logic executes correctly and preventing the system from mistakenly assuming that the order has been paid.

[0124] Next, the system will release the inventory. Since the payment was not completed successfully, the inventory originally reserved for this order needs to be returned to the available inventory to ensure that other users have the opportunity to purchase the product. This process is achieved by adding the quota (i.e., the inventory quantity) back into the queue.

[0125] This mechanism allows the system to quickly roll back orders and inventory in the event of payment failure, ensuring the rational allocation of resources and improving system robustness and user experience. This process not only avoids inventory waste but also allows other users to re-participate during the event, thereby enhancing system efficiency and fairness.

[0126] In one possible implementation, the method further includes:

[0127] When multiple flash sale requests are processed through multiple clusters, a distributed lock is added to the inventory list to lock the inventory list, thereby preventing concurrent conflicts in high-concurrency scenarios and ensuring the accuracy and consistency of the inventory.

[0128] Specifically, in this process, the locking key is seckill:lock:<product ID>, where <product ID> is the unique identifier of the flash sale product. The lock timeout is usually set to 500ms to ensure that the inventory deduction operation is completed within a short time and to prevent the lock from being held indefinitely, thus avoiding blocking other requests.

[0129] The following steps are involved in the operation after locking:

[0130] Locking: Acquire the inventory lock for the corresponding product by calling the distributed lock service (e.g., seckill:lock:<product ID>). If successful, proceed with the inventory deduction operation. If acquisition fails, it means the lock is already held by another thread, and the current request will be blocked or retried until the lock is acquired.

[0131] Inventory Deduction: Once the lock is successfully acquired, the system can safely perform an inventory deduction operation. At this time, only the current thread can operate on the inventory of this product, preventing other threads from concurrently modifying the inventory and causing overselling.

[0132] Unlocking: After the inventory deduction is complete, the system releases the lock, ensuring that other requests can continue to access and modify the inventory. This step is crucial for ensuring the effectiveness of the distributed lock mechanism.

[0133] Handling timeouts and retries: If the set timeout period (e.g., 500ms) is exceeded when locking, a retry mechanism can be triggered, or a message indicating that the flash sale failed can be returned to avoid system lag caused by the lock not being released.

[0134] By combining distributed locks and high-concurrency request handling mechanisms, the system can accurately manage inventory during flash sales, ensuring that each order receives the correct inventory allocation. This prevents issues such as overselling inventory and data inconsistency caused by concurrency problems, thereby improving system stability and user experience.

[0135] See Figure 4 , Figure 4 This is a schematic diagram of the structure of a system for processing flash sale requests, provided in an embodiment of this application. Figure 4 As shown, the system for processing the flash sale request includes: a web server 401 and a microservice gateway 402; the web server 401 is connected to the microservice gateway 402; the web server 401 is configured with concurrency parameters; and the microservice gateway 402 is configured with a bucket algorithm.

[0136] The web server 401 is configured to: respond to multiple flash sale requests sent in parallel by multiple clients, perform peak shaping on the multiple flash sale requests based on the concurrency parameters to obtain multiple candidate requests; the flash sale requests are obtained by encapsulating user request parameters; the user request parameters include user ID, target product ID and request timestamp;

[0137] The microservice gateway 402 is used to: perform rate limiting and multi-dimensional filtering on the multiple candidate requests based on the bucket algorithm and request filtering strategy to obtain multiple valid requests; deduct inventory from the inventory list in Redis using the LPOP command based on the number of the multiple valid requests and generate reserved orders corresponding to each of the multiple valid requests, and bind the reserved orders to the corresponding user accounts; the inventory list records the target product ID and the target product inventory quantity; in response to a payment request initiated by the user account bound to the reserved order, obtain the request time interval; the request time interval includes the time from the start of the reserved order generation to the generation of the payment request; if the request time interval does not exceed the order expiration time, confirm the payment request as valid and perform payment processing, and update the order status of the reserved order to paid.

[0138] In one possible implementation, the bucket algorithm and request filtering strategy are used to perform rate limiting and multi-dimensional filtering on the multiple candidate requests to obtain multiple valid requests, including:

[0139] Based on the pre-set token bucket capacity, the multiple candidate requests are filtered and tokens are allocated to obtain multiple initial screening requests; the initial screening requests are candidate requests carrying identity tokens.

[0140] Key fields are extracted from the multiple initial screening requests to obtain multiple key fields corresponding to each initial screening request.

[0141] Each candidate request is validated in multiple dimensions based on the multiple key fields corresponding to each initial screening request.

[0142] Requests that pass the initial screening through the multi-dimensional verification will be determined as valid requests.

[0143] In one possible implementation, the multiple key fields include the client's real IP address, identity token, the request timestamp, and the user ID.

[0144] In one possible implementation, the multi-dimensional verification of each candidate request based on multiple key fields corresponding to each initial screening request includes:

[0145] For each of the initial screening requests, the following multi-dimensional verifications are performed:

[0146] The identity validity of the initial screening request is verified based on the identity token of the initial screening request.

[0147] If the identity validity verification passes, the initial screening request is then time-validated based on the request timestamp of the initial screening request; wherein, the time validity verification passes when the difference between the request timestamp and the current time is less than a time difference threshold.

[0148] If the time validity verification passes, the request frequency of the initial screening request is calculated based on the user ID and the client's real IP of the initial screening request.

[0149] If the request frequency is less than the frequency threshold, then query the activity status key in Redis;

[0150] If the value of the activity status key is the first flag bit, then the multi-dimensional verification of the initial screening request is confirmed to have passed; otherwise, the multi-dimensional verification of the initial screening request is confirmed to have failed.

[0151] In one possible implementation, processing the payment request includes:

[0152] Obtain the request time interval; the request time interval includes the time from the start of the reserved order generation to the generation of the payment request;

[0153] If the requested time interval does not exceed the order expiration time, the payment request is confirmed as valid and payment is processed, and the order status of the reserved order is updated to paid.

[0154] In one possible implementation, the microservice gateway 402 is further configured to:

[0155] Convert successfully paid reserved orders into target orders;

[0156] Generate structured voucher data for the target order; the structured voucher data includes fields such as qualification ID, user ID, target product ID, and expiration time;

[0157] The actual inventory is allocated to the target order based on the structured voucher data.

[0158] In one possible implementation, the microservice gateway 402 is further configured to:

[0159] Based on a pre-set inventory allocation and sorting strategy, actual inventory is allocated sequentially to each of the target orders.

[0160] The inventory allocation sorting strategy includes sorting by the time the request arrives at the gateway; or sorting by membership level; or sorting using a completely random fair allocation mode.

[0161] In one possible implementation, when the flash sale is in progress, the value of the activity status key in Redis is the first flag bit; otherwise, it is another flag bit.

[0162] In addition, this application embodiment also provides a processing device for a flash sale request, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the flash sale request processing method as described above.

[0163] In addition, this application embodiment also provides a computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to perform the processing method for the flash sale request as described above.

[0164] This application employs a concurrency parameter-based peak-shaving approach, combined with bucket algorithms and request filtering strategies, to precisely control the traffic of flash sale requests, effectively limiting rates and filtering across multiple dimensions. This reduces the risk of system overload caused by a rapid influx of requests. By implementing concurrency control at the request entry stage, system load can be balanced, ensuring stable operation even during high-concurrency traffic periods like flash sales. Furthermore, by incorporating Redis's inventory deduction mechanism, the system can quickly deduct product inventory from the inventory list under high concurrency and simultaneously generate reserved orders, ensuring the efficiency and atomicity of the operation. This approach not only avoids overselling but also effectively prevents inconsistencies in order status, further improving system response speed and user experience.

[0165] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The system embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. The components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0166] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for processing a flash request, characterized in that, The method comprises: In response to a plurality of flash sale requests sent in parallel by a plurality of clients, performing peak clipping processing on the plurality of flash sale requests based on preset concurrency parameters to obtain a plurality of candidate requests; the flash sale request is obtained by parameter encapsulation based on a user request parameter; the user request parameter comprises a user identifier (ID), a target commodity ID and a request timestamp; Performing flow control and multi-dimensional filtering processing on the plurality of candidate requests based on a bucket algorithm and a request filtering strategy to obtain a plurality of valid requests; Based on the number of the plurality of valid requests, performing inventory deduction on an inventory list in a remote dictionary server (Redis) through an LPOP instruction and generating a reserved order corresponding to each of the plurality of valid requests, and binding the reserved order with a corresponding user account; the inventory list records the target commodity ID and the target commodity inventory quantity; In response to a payment request initiated by the user account bound with the reserved order, processing the payment request.

2. The method of claim 1, wherein, The method comprises: Based on the preset token bucket capacity, performing request filtering and token allocation on the plurality of candidate requests to obtain a plurality of preliminary screening requests; the preliminary screening request is a candidate request carrying an identity token; Extracting a plurality of key fields corresponding to each of the preliminary screening requests to obtain the plurality of key fields corresponding to each of the preliminary screening requests; Based on the plurality of key fields corresponding to each of the preliminary screening requests, performing multi-dimensional verification on each of the candidate requests; The preliminary screening request that passes the multi-dimensional verification is determined as a valid request.

3. The method of claim 2, wherein, The plurality of key fields comprise a client real Internet Protocol (IP), an identity token, the request timestamp and the user ID; The method comprises: For each preliminary screening request, the following multi-dimensional verification is performed: Based on the identity token of the preliminary screening request, performing identity validity verification on the preliminary screening request; If the identity validity verification passes, based on the request timestamp of the preliminary screening request, performing time validity verification on the preliminary screening request; wherein the time validity verification passes when the difference between the request timestamp and the current time is less than a time difference threshold value; If the time validity verification passes, based on the user ID and the client real IP of the preliminary screening request, calculating the request frequency of the preliminary screening request; If the request frequency is less than a frequency threshold value, querying an active state key in Redis; If the value of the active state key is a first flag bit, it is confirmed that the multi-dimensional verification of the preliminary screening request passes, otherwise it is confirmed that the multi-dimensional verification of the preliminary screening request does not pass.

4. The method of claim 1, wherein, The method comprises: Obtaining a request time interval; the request time interval comprises the time from the start of the generation of the reserved order to the generation of the payment request; If the request time interval does not exceed the order expiration time, it is confirmed that the payment request is valid and payment processing is performed, and the order state of the reserved order is updated to paid.

5. The method of claim 1, wherein, After processing the payment request, the method further comprises: convert the reservation order of the payment success into a target order; generate structured voucher data for the target order; the structured voucher data includes fields such as qualification ID, user ID, target product ID, and expiration time; allocate actual inventory for the target order based on the structured voucher data.

6. The method of claim 5, wherein, The method further comprises: sequentially allocate actual inventory for each of the target orders based on a pre-set inventory allocation ranking strategy; The inventory allocation ranking strategy includes ranking according to the time of request arrival at the gateway, or ranking according to membership level, or ranking using a completely random fair allocation mode.

7. The method of claim 3, wherein, When the flash sale activity is in the running phase, the value of the activity state key in the Redis is the first flag bit, otherwise it is other flag bits.

8. A system for processing a flash request, the system comprising: The system comprises a Web server and a micro-service gateway; the Web server is connected to the micro-service gateway; the Web server is configured with a concurrency parameter; the micro-service gateway is configured with a bucket algorithm; The Web server is configured to: in response to a plurality of flash sale requests sent in parallel by a plurality of clients, perform peak clipping processing on the plurality of flash sale requests based on the concurrency parameter to obtain a plurality of candidate requests; a flash sale request is obtained by parameter encapsulation based on user request parameters; the user request parameters include user ID, target product ID, and request timestamp; The micro-service gateway is configured to: perform flow limiting and multi-dimensional filtering processing on the plurality of candidate requests based on the bucket algorithm and request filtering strategy to obtain a plurality of valid requests; perform inventory deduction on an inventory list in Redis based on the number of the plurality of valid requests through an LPOP instruction and generate a reservation order corresponding to each of the plurality of valid requests; the reservation order is bound to a corresponding user account; the inventory list records the target product ID and the target product inventory quantity; in response to a payment request initiated by the user account bound to the reservation order, obtain a request time interval; the request time interval includes the time from the generation of the reservation order to the generation of the payment request; if the request time interval does not exceed the order expiration time, confirm that the payment request is valid and perform payment processing, and update the order state of the reservation order to paid.

9. A processing device of a flash sale request, characterized in that, It comprises: a memory, a processor, and a computer program stored on the memory and executable on the processor; when the processor executes the computer program, it implements the flash sale request processing method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores instructions, when the instructions run on a terminal device, the terminal device executes the flash sale request processing method of any one of claims 1-7.

Images