Business request processing method and device, electronic equipment and storage medium

Abstract

The application discloses a service request processing method and device, electronic equipment and a storage medium. The method creates an independent counting unit for each time window, and destroys the counting unit associated with the target time window if the life cycle of the time window ends. In this way, the service requests of a preset type in each time window can be counted independently, and only the number of service requests of the preset type needs to be accumulated, without performing the complex and error-prone deduction operation in the conventional technology. On the one hand, since the data deduction operation is saved, the implementation complexity and performance overhead of the system are reduced, and the stability and reliability of the system are enhanced. On the other hand, in a high-concurrency environment, the system only needs to process the number accumulation process of the service requests of the preset type, reduces the competition for resources of the data accumulation and data deduction processes, and improves the accuracy of the counting result and the system state determination.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method, apparatus, electronic device and storage medium for processing business requests. Background Technology

[0002] In e-commerce, online payment, and financial services, systems frequently need to handle a large number of business requests. In certain scenarios, the system may receive a dense influx of business requests within a short period, exceeding the normal business scope. This could be caused by malicious attacks or system malfunctions. To protect system assets and maintain system stability, a globally shared counting unit can be maintained to count the occurrence of preset types of business requests within a predefined time window. If a preset type of business request occurs, the number of requests is incremented; if the duration of a preset type of business request exceeds the length of the time window, the number of requests is deducted.

[0003] However, the above process requires the execution of accumulation and deduction operations. In distributed caching systems, traditional counting methods require simultaneous accumulation and deduction operations, which is complex and has a large performance overhead. Furthermore, asynchronous deduction mechanisms are prone to causing the cache count value to become out of sync with the actual business flow state. In high-concurrency scenarios, this can easily lead to inaccurate counting results, resource contention, and inaccurate system state determination. Summary of the Invention

[0004] This application provides a business request processing method to overcome the technical problems of inaccurate counting results, resource contention, and inaccurate system state determination when processing business requests in a high-concurrency environment.

[0005] According to one embodiment of this application, a business request processing method is proposed, the method comprising: Determine multiple pre-divided time windows; For each target time window among the plurality of time windows, a counting unit associated with the target time window is created; the counting unit counts service requests of a preset type within the target time window, the preset type of service requests including rollback requests for the target service state; If a service request of the preset type occurs within the target time window, the number of service requests of the preset type recorded in the counting unit is updated; In response to the end of the lifecycle of the target time window, the counting unit associated with the target time window is destroyed.

[0006] According to one embodiment of this application, a service request processing apparatus is provided, the apparatus comprising: The time window determination module is configured to determine multiple pre-divided time windows; A creation module is configured to create a counting unit associated with each target time window within the plurality of time windows; the counting unit counts service requests of a preset type within the target time window, the preset type of service requests including rollback requests for the target service state; The update module is configured to update the number of service requests of the preset type recorded in the counting unit if a service request of the preset type occurs within the target time window. The destruction module is configured to destroy the counting unit associated with the target time window in response to the end of the target time window's lifecycle.

[0007] According to one embodiment of this application, an electronic device is provided, the device including a memory and a processor, the memory being used to store computer instructions executable on the processor, and the processor being used to implement the method as described in any of the preceding claims when executing the computer instructions.

[0008] According to one embodiment of this application, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method as described in any of the preceding claims.

[0009] The business request processing scheme provided in this application creates an independent counting unit for each time window and destroys the counting unit associated with the target time window when the time window's lifecycle ends. In this way, business requests of a preset type can be counted independently within each time window, requiring only the accumulation of the number of these preset type requests, without performing the complex and error-prone deduction operation of traditional technologies. On the one hand, because the above process saves data deduction operations, it reduces the system's implementation complexity and performance overhead, enhancing the system's stability and reliability. On the other hand, in a high-concurrency environment, the system only needs to handle the accumulation process of the preset type of business requests, reducing resource contention between data accumulation and deduction processes, and improving the accuracy of counting results and system status determination.

[0010] Other features and advantages of the technical solution proposed in this application are described below. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this specification and, together with the description, serve to explain the principles of this specification.

[0012] Figure 1A flowchart illustrating a service request processing method according to an embodiment of this application is shown.

[0013] Figure 2 A schematic diagram comparing a system scheme according to an exemplary embodiment of this application with related technologies is shown.

[0014] Figure 3 This is a schematic diagram of the structure of an electronic device shown in at least one embodiment of this application. Detailed Implementation

[0015] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0016] In e-commerce, online payment, and financial services, systems often need to handle a large number of business requests, including but not limited to order payment requests, inventory deduction requests, and transaction cancellation requests. In certain scenarios, due to malicious attacks such as exploiting system vulnerabilities for fraudulent purposes, or system malfunctions such as program errors leading to duplicate transactions, the system may receive a dense stream of business requests that exceed the normal business scope within a short period of time.

[0017] To protect system assets and maintain system stability, technical personnel typically introduce risk control mechanisms. One common risk control mechanism is to statistically analyze high-frequency business requests. This involves counting the number of times a set type of business request occurs within a preset time window. When the number of such requests exceeds a preset risk threshold, the system will trigger corresponding protective measures, such as temporarily blocking subsequent requests of the same type and sending an alert to operations and maintenance personnel.

[0018] Current methods for counting high-frequency service requests rely on a globally shared counting unit to record and update the number of service requests. For example, when a service request of a preset type is generated, the system increments the number recorded in the counting unit; to achieve a time window effect, the number recorded in the counting unit needs to be decremented after a period of time following the generation of the service request. In today's widely used distributed systems that handle high-concurrency requests, the inherent flaws of this pattern are further amplified.

[0019] First, the accumulation and deduction in related technologies are two separate asynchronous operations. In high-concurrency scenarios, multiple threads or service nodes simultaneously read and write to the same shared counting unit, which can easily lead to race conditions, resulting in data inconsistency. The final count value cannot accurately reflect the number of events occurring in the real world per unit of time. Second, to solve the counting inaccuracy problem caused by concurrency, engineers have to introduce complex distributed locks or transaction mechanisms to ensure the atomicity of operations. However, in high-frequency read / write scenarios, the locking mechanism itself becomes a performance bottleneck, significantly increasing request latency and reducing system throughput, which is unacceptable for risk control systems requiring real-time responses. Therefore, related technical solutions are complex and have significant performance overhead, easily leading to inaccurate counting results, resource contention, and inaccurate system state determination in high-concurrency scenarios.

[0020] To address the aforementioned issues, this application provides a business request processing scheme that eliminates the need for the traditional approach of reading, writing, and modifying a single, persistent shared counting unit. Instead, it employs a time window as an independent business request processing cycle. Within the lifecycle of each time window, the system associates it with a counting unit and performs accumulation operations only on that unit. At the end of the time window's lifecycle, the corresponding counting unit is destroyed, thus resetting the number of business requests implicitly without locks or conflicts. This reduces the complex and error-prone deduction operations introduced in related technologies to achieve the time window effect, lowers the system's implementation complexity and performance overhead, enhances system stability and reliability, and reduces resource contention during data accumulation and deduction processes, thereby improving the accuracy of counting results and system status determination.

[0021] To enable those skilled in the art to more fully understand the technical solution of this application, the following will be described in conjunction with the appendix. Figure 1 This application provides a detailed explanation of the business request processing methods provided.

[0022] Figure 1 A flowchart illustrating a service request processing method according to an embodiment of this application is shown. The method includes the following steps S101 to S104.

[0023] Step S101: Determine multiple pre-divided time windows.

[0024] This embodiment can predefine the time window division rules at the system level, thereby dividing the infinitely continuing time axis into independent time intervals, i.e., time windows, based on these rules. The length of each time window can be fixed or variable; and the time windows can be connected end-to-end but do not overlap. For example, the duration of a time window can be fixed at one minute, then the time axis can be divided into a series of time windows such as [10:00:00-10:01:00), [10:01:00-10:02:00), [10:02:00-10:03:00), etc.

[0025] In some implementations, time windows of different durations can be configured for different preset attributes based on their risk sensitivity and traffic characteristics. These preset attributes include, but are not limited to, business channels, product / service types, user characteristic dimensions, transaction characteristic dimensions, and geographic and device dimensions. Business channels are used to distinguish different business sources or regions; for example, in a payment platform, business channels can differentiate between different business sources such as Brand A App and Brand B App. Product / service types involve the specific content of the transaction, such as physical goods versus virtual goods, e-commerce retail versus financial services, etc. User characteristic dimensions include user level, credit rating, and behavioral patterns. Transaction characteristic dimensions cover amount levels, transaction types, and time characteristics. Geographic and device dimensions include geographical location, device environment, and network environment.

[0026] Taking business channels in the preset attributes as an example, different business channels exhibit significant differences in risk sensitivity and traffic characteristics. Therefore, different time windows can be configured for different business channels based on their risk sensitivity and traffic characteristics. For channels with high risk sensitivity, shorter time windows, such as 1-5 minutes, can be configured to achieve rapid anomaly detection and response, preventing large-scale attacks in a short period of time. For channels with medium risk sensitivity, medium-length time windows, such as 15-30 minutes and 30-60 minutes, can be configured to balance security and business continuity. For channels with low risk sensitivity, longer time windows, such as 12-24 hours, can be configured to reduce system overhead.

[0027] Step S102: For each time window in the multiple time windows, hereinafter referred to as the target time window, create a counting unit associated with the target time window; the counting unit counts business requests of a preset type within the target time window, the preset type of business requests including rollback requests of the target business state.

[0028] After determining multiple time windows, this step creates a counting unit for each time window, with the counting units created for different time windows being isolated from each other. The initial count of a newly created counting unit is 0. Within the time window corresponding to the counting unit, for each business request of a preset type received, the initial count of the counting unit is incremented by 1. In some implementations, the method of this embodiment is applicable to distributed caching systems, such as Redis, where the counting units are stored, thereby effectively supporting high-concurrency read and write access and meeting real-time requirements.

[0029] According to this embodiment, counting units can be created in a flexible manner. In one implementation, counting units can be created using an on-demand creation mode, also known as lazy loading. This means that the system only creates a counting unit when the first service request of a preset type is received within a time window, effectively saving system resources and avoiding the creation of idle counting units for time windows with no service traffic. In another implementation, counting units can be created immediately when a new time window begins. This approach is logically simple and direct, ensuring that counting units are ready when any service request arrives. These creation methods all fall within the scope of protection of this application.

[0030] The created counting unit is used to record the number of business requests of a preset type. In a specific application scenario, a preset type of business request can refer to a rollback request for a target business state. The target business state refers to a specific intermediate or final state in the business processing flow, and a rollback request refers to a request operation that restores the business state from its current state to the state before the target business state. Examples include order cancellation requests in a payment system, inventory deduction requests in an e-commerce system, or posting requests in a social application. The system can identify whether a business request belongs to a type requiring risk control based on its interface address, message type, or other business parameters.

[0031] In some implementations, a single counting unit can be created for each time window. In other implementations, for more granular risk management, multiple counting units can be created and associated with each time window. These multiple counting units correspond to various preset attributes of preset types of business requests, and counting units corresponding to different preset attributes are isolated from each other. Each counting unit can be used to record the number of preset type business requests with preset attribute information associated with that counting unit.

[0032] The preset attributes here can be flexibly defined to classify and identify business requests. The specific content and acquisition method of these preset attributes can be flexibly set according to the business scenario. For example, the preset attribute can be a business channel, user ID, user IP address, or user device ID. The system can obtain the preset attribute by parsing a specific field in the request body or request header of the business request, or by parsing the URL path of the business request, through authentication information associated with the business request, such as an API key, or by analyzing the network layer information from which the business request originates. The network layer information could be, for example, an IP address.

[0033] Step S103: If a service request of a preset type occurs within the target time window, update the number of service requests of the preset type recorded in the counting unit.

[0034] When the system receives a business request, it can determine which target time window the request falls into based on the timestamp of the request's arrival at the server. After determining the target time window to which the business request belongs, the counting unit associated with that target time window can be obtained. In some implementations, in distributed system application environments, the counting unit can typically be deployed in a high-performance distributed caching system, such as Redis, to effectively support high-concurrency read and write access and meet real-time requirements. Furthermore, in embodiments where different preset attributes correspond to different counting units, multiple counting units associated with the target time window can be obtained first, then the target counting unit corresponding to the preset attribute of the preset type of business request can be determined from among the multiple counting units, and then the number of preset type of business requests recorded in the target counting unit can be updated.

[0035] Taking the preset attribute as a business channel as an example, when the system determines that the business channel associated with the business request is the A brand APP, it can find the counting unit that belongs to the A brand APP and the target time window for operation, thereby realizing the isolation of the business request processing process of different business channels and preventing them from interfering with each other.

[0036] When updating the number of business requests, if a business request is received, the number of that type of business request recorded in the counting unit can be incremented by 1 to record the occurrence of this event. This embodiment employs an atomic accumulation operation to address the inaccurate counting problem in related technologies under concurrent environments. Atomicity ensures the correct execution of the accumulation operation when multiple requests access the same counting unit simultaneously, reducing data loss or overwriting and thus improving the accuracy of the count value.

[0037] Specifically, the operations of verifying the update conditions of the counting unit, reading the count value of the counting unit, and updating the count value of the counting unit can be encapsulated into atomic operations and executed to update the number of business requests of the preset type recorded in the counting unit. Specifically, atomic execution logic pre-installed on the server side of the distributed caching system can be invoked to execute the operations of verifying the update conditions of the counting unit, reading the count value of the counting unit, and updating the count value of the counting unit in an exclusive locking manner. Each time a business request of the preset type is received, the above three operations are executed for that business request. Only after all three operations are completed will the next business request of the preset type be processed.

[0038] In some implementations, when the counting unit is deployed in a distributed caching system like Redis, the operations of verifying the update conditions of the counting unit, reading the count value of the counting unit, and updating the count value of the counting unit can be encapsulated into a Lua script. This allows the atomic accumulation operation to be implemented by executing the Lua script. Leveraging the single-threaded execution of Lua scripts by the Redis server, the entire operation process can be naturally guaranteed not to be interrupted by other commands, thus efficiently achieving the atomicity of the counting process in the distributed system.

[0039] Specifically, when a client receives a business request, it can call this Lua script. Internally, the Lua script first retrieves the current value of the target counter key using Redis's key-value read command. If the key does not exist (i.e., the request is triggered for the first time within the current time window), it enters the initialization process. An atomic write command sets the initial value of the counter key to a preset initial value, and simultaneously calls a lifecycle setting command to set its expiration time (TTL), ensuring the counter unit automatically resets after the time window expires. The preset initial value could be, for example, 1. If the key already exists, it enters the threshold judgment process, comparing the current count value with a preset traffic threshold. If the upper limit has not been reached, an atomic increment operation is performed to increment the count value by 1. If the threshold has been reached or exceeded, a blocking signal is returned to terminate subsequent counting. Although Redis itself provides single atomic commands such as INCR and SETNX, these commands only guarantee the atomicity of a single operation and cannot simultaneously complete the complex logic of checking existence, initializing conditions, comparing thresholds, incrementing on demand, or rejecting within an atomic unit. If multiple native commands are invoked separately, the client and server need to make multiple network round trips. Under high concurrency, two requests may simultaneously read the same old value, each incrementing after passing the threshold check, causing the actual count to exceed the threshold and not be intercepted. However, by leveraging Redis's single-threaded execution of Lua scripts, the entire process of reading-judging-initializing / comparing-incrementing / rejecting-setting expiration is executed continuously in one go in the server kernel space. During this time, no commands from other clients will be interrupted, thus eliminating race conditions at the physical level and achieving strong consistency and atomicity of counting control in a distributed environment, while reducing network interaction latency.

[0040] In some implementations, after updating the number of preset type business requests within a target time window, the number of preset type business requests that have occurred within that target time window can be compared with a preset quantity threshold. This preset quantity threshold is a risk threshold; if the number of preset type business requests that have occurred within the target time window exceeds this threshold, a risk or anomaly is identified, requiring intervention for the aforementioned preset type of business requests. In some embodiments, it is not necessary to wait for the target time window to end; instead, the updated number can be compared with the aforementioned risk threshold immediately after updating the number of preset type business requests within the target time window. If the updated number exceeds the risk threshold, a preset risk control operation is immediately executed. This instant judgment mechanism ensures the real-time nature of risk control. For example, in e-commerce or payment systems, a one-minute time window can be set to detect whether the number of order cancellation requests or fraudulent order requests within that window exceeds a normal threshold; if it does, a risk or anomaly is identified, triggering an interception mechanism to reject subsequent order cancellation requests or fraudulent order requests or issue an alarm. In this way, abnormal traffic can be detected and blocked in a timely manner in high-concurrency scenarios, improving business security.

[0041] In some implementations, risk thresholds can be configured for different preset attributes, such as different business channels, different user IDs, different user IP addresses, or different user device IDs, to achieve more refined management. For example, if the preset attribute is a business channel, the risk threshold for channel A can be set to 100, and the risk threshold for channel B can be set to 500.

[0042] In some implementations, risk control operations may include intercepting service requests of a preset type received within the remaining time period of a target time window. For example, if the preset type of service request is a cancellation request, after determining that the number of cancellation requests within the target time window has reached a risk threshold, subsequent cancellation requests arriving within the target time window will be intercepted.

[0043] When this embodiment combines the aforementioned independent counting based on different preset attribute values, the interception operation here can achieve more refined control. For example, the preset attribute can be a business channel identifier, and different preset attribute values ​​can include Brand A channel and Brand B channel. If a cancellation request from Brand A APP triggers a risk threshold on its dedicated counting unit, assuming that the number of cancellation requests from Brand B APP within the target time window has not reached the risk threshold, the system will only block subsequent cancellation requests from Brand A APP within the target time window, and will not block cancellation requests from Brand B APP within the same target time window.

[0044] In some implementations, to enhance external intervention capabilities such as manual intervention on top of automatic interception, risk control operations also include: during the interception period, if a release instruction is received for a preset type of business request received within the remaining time period, the interception of such requests is suspended. For example, a cancellation request from Brand A's app triggers a risk threshold within a target time window, causing the system to intercept subsequent cancellation requests from Brand A's app within that target time window. If, after manual verification, it is determined that the current cancellation requests from Brand A's app do not exhibit obvious anomalies—for example, if operations or maintenance personnel confirm that the current traffic is not malicious—a release instruction can be manually triggered to suspend the interception operation. This allows the system to continue receiving cancellation requests from Brand A's app during the remaining time period of the target time window. This adds a flexible security mechanism to the automated, rigid risk control system, reduces business losses caused by rule misjudgments, and further improves user experience and system fault tolerance.

[0045] Step S104: In response to the end of the lifecycle of the target time window, the counting unit associated with the target time window is destroyed.

[0046] According to this embodiment, when a time window naturally ends, for example, after 10:01 and the time reaches 10:02, the system automatically, or through a garbage collection mechanism, actively destroys or causes the counting units associated with the [10:01-10:02] time window to expire naturally. Destruction refers to configuring a corresponding lifetime parameter for the counting unit based on the preset length of the target time window when it is created, so as to utilize the storage system's built-in memory reclamation mechanism to automatically trigger the physical release of the counting unit after the target time window ends. Through this destruction operation, the number of business requests of a preset type is cleared / reset in an implicit, automatic, and lock-free manner. In the next time window [10:02-10:03), the system will begin maintaining a completely new counting environment starting from zero. This design in this embodiment removes the deduction operation introduced by related technologies to simulate time windows, which needs to be performed some time after a business request is generated. Since only atomic accumulation exists, the corresponding, difficult-to-manage asynchronous deduction is eliminated. This embodiment reduces counting errors caused by concurrent read and write of shared resources, simplifies system logic, and improves system robustness and performance.

[0047] To demonstrate the technical solution of this application and its beneficial effects more clearly and intuitively, the following will refer to the appendix. Figure 2 The implementation process of this application is illustrated by a specific end-to-end example.

[0048] Figure 2The upper part illustrates the architecture and processing flow of the relevant technology. In this technology, all cancellation requests, regardless of when they arrive, operate on the same globally shared and long-term existing counting unit. The system performs both total accumulation and total deduction operations on this counting unit simultaneously. As analyzed earlier, this can easily lead to counting errors due to race conditions in high-concurrency scenarios, thus affecting the accuracy of risk control.

[0049] Figure 2 The lower half illustrates the architecture and processing flow according to exemplary embodiments of this application. This application abandons the globally shared counting unit and instead divides the timeline into a series of independent, non-overlapping time windows, such as... Figure 2 The "Window 1 17:00-17:01", "Window 2 17:01-17:02", etc. shown in the diagram create and associate locally shared short-term counting units for each time window. The following example illustrates this with a specific business scenario.

[0050] Suppose we need to process order cancellation requests from Brand A's App business channels. We set a time window rule where each window lasts for 1 minute and the risk threshold is 4 times. That is, if there are more than 4 order cancellation requests within 1 minute, risk control will be triggered.

[0051] At 17:00:00, the system enters a new time window, that is... Figure 2 In window 1, the system can associate a brand new counting unit with an initial value of 0 for Brand A's App channel within this period.

[0052] At 17:00:15, the system received cancellation request 1 from this business channel. Based on the timestamp of cancellation request 1, the system determined that the request belonged to window 1, and therefore atomically incremented the counter unit of window 1, making the count value 1. This count value represents the number of cancellation requests. The system determined that the count value of 1 did not exceed the threshold 4, and the request was processed normally.

[0053] At 17:00:30, the system received cancellation request 2. The counter value in window 1 was updated to 2. Since 2 did not exceed the threshold of 4, the request was processed normally.

[0054] At 17:00:50, the system received cancellation request 3. The counter value in window 1 was updated to 3. Since 3 did not exceed the threshold 4, the request was processed normally.

[0055] At 17:01:00, the lifecycle of window 1 ends. The associated counting unit with a count value of 3 is immediately destroyed or marked as expired. Simultaneously, the system enters the next time window. Figure 2Window 2 in the time window, namely 17:01-17:02, and associate a brand new counting unit with an initial value of 0 with this business channel in window 2.

[0056] At 17:01:20, the system received cancellation request 4. This request belongs to window 2. The system increments the new counter unit in window 2, and the counter value becomes 1. Since 1 does not exceed the threshold of 4, the request is processed normally. Subsequent processing is similar.

[0057] According to this embodiment, the periodicity, isolation, and automatic reset of the count are achieved through a time window and a counting unit bound to its lifecycle. The entire process involves only simple atomic accumulation, with clear logic and high accuracy and reliability.

[0058] In summary, the business request processing method provided in this embodiment solves the counting inaccuracies and performance bottlenecks caused by shared counting units in concurrent operations in related technologies by introducing a series of time windows and associating each window with an independent counting unit. This embodiment employs atomic accumulation operations and destroys the counting unit at the end of the window to achieve implicit reset, thus eliminating the complex and error-prone deduction logic. It should be noted that this application abandons the asynchronous logic maintenance in traditional solutions and instead utilizes the physical lifetime (TTL) characteristic of the storage medium to achieve implicit reset of the statistical window. Each time window corresponds to a physically independent counting unit, which is automatically released by the storage medium at the end of the window. This "stateless" design avoids dependence on exception compensation logic. When facing the counting consistency problem under high concurrency, related technologies typically tend to increase logical complexity, such as introducing more reliable message middleware or distributed transactions, to avoid the risk of asynchronous operation failures. This application, however, takes the opposite approach, using "logical subtraction" to solve the statistical distortion problem through the native mechanism of the storage engine. This method not only improves the accuracy and real-time performance of business request processing in high-concurrency environments, but also simplifies system design, reduces performance overhead, and helps build an efficient, stable, and reliable business request processing system.

[0059] This application also proposes a service request processing apparatus, comprising: The time window determination module is configured to determine multiple pre-divided time windows; A creation module is configured to create a counting unit associated with each target time window within the plurality of time windows; the counting unit counts service requests of a preset type within the target time window, the preset type of service requests including rollback requests for the target service state; The update module is configured to update the number of service requests of the preset type recorded in the counting unit if a service request of the preset type occurs within the target time window. The destruction module is configured to destroy the counting unit associated with the target time window in response to the end of the target time window's lifecycle.

[0060] Figure 3 This is a schematic diagram of an electronic device provided according to one embodiment of this application. The electronic device may be a server, a personal computer, a mobile terminal, or other device with data processing capabilities. As shown, the device includes a processor and a memory. The memory stores computer instructions that can run on the processor, and the processor, when executing the computer instructions, implements the service request processing method described in any embodiment of this application.

[0061] One embodiment of this application also provides a computer-readable storage medium storing a computer program thereon. This computer-readable storage medium includes all forms of non-volatile memory, media, and devices, such as semiconductor storage devices like EPROMs and flash memory devices, magnetic disks, magneto-optical disks, and CD-ROMs and DVD-ROMs. When the program is executed by a processor, it can implement the service request processing method described in any embodiment of this application.

[0062] The processing and logic flow described in this specification can be implemented by one or more programmable processors executing one or more computer programs, or by special-purpose logic circuits such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). The processor used to execute the computer program can be a general-purpose or special-purpose microprocessor. Typically, the processor receives instructions and data from read-only memory or random access memory. The basic components of a computer include a processor for executing instructions and one or more storage devices for storing instructions and data.

[0063] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of the invention. Certain features described in multiple embodiments may also be implemented in combination in a single embodiment; conversely, various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. Similarly, although the operational flows in the accompanying drawings are depicted in a specific order, this does not require that they be performed in the indicated order or serially to achieve the desired result; in some cases, multitasking or parallel processing may be equally feasible or more advantageous.

[0064] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A business request processing method, characterized in that, The method includes: Determine multiple pre-divided time windows; For each target time window among the plurality of time windows, a counting unit associated with the target time window is created; the counting unit counts service requests of a preset type within the target time window, the preset type of service requests including rollback requests for the target service state; If a service request of the preset type occurs within the target time window, the number of service requests of the preset type recorded in the counting unit is updated; In response to the end of the lifecycle of the target time window, the counting unit associated with the target time window is destroyed.

2. The method according to claim 1, characterized in that, There are multiple counting units associated with each time window. These multiple counting units correspond to various preset attributes of the business request of the preset type, and the counting units corresponding to different preset attributes are isolated from each other. Updating the number of service requests of the preset type recorded by the counting unit includes: Determine the target counting unit among the plurality of counting units that corresponds to the preset attribute of the service request of the preset type; The number of service requests of the preset type recorded in the target counting unit is updated.

3. The method according to claim 1, characterized in that, The method further includes: If the number of service requests of the preset type that have occurred within the target time window exceeds a preset threshold, the service requests of the preset type received within the remaining time period of the target time window will be intercepted.

4. The method according to claim 3, characterized in that, The method further includes: Configure corresponding preset quantity thresholds for different business channels.

5. The method according to claim 3, characterized in that, Also includes: If a permission instruction is received for a service request of a preset type received within the remaining time period, the operation of intercepting the service request of the preset type received within the remaining time period is stopped.

6. The method according to claim 1, characterized in that, Updating the number of service requests of the preset type recorded by the counting unit includes: Invoke the atomic execution logic pre-installed on the server side of the distributed caching system to perform the following operations: Verify the update conditions of the counting unit; Read the count value of the counting unit; and Update the count value of the counting unit.

7. The method according to claim 1, characterized in that, The method is applicable to a distributed caching system, wherein the counting unit is stored in the distributed caching system.

8. A service request processing apparatus, characterized in that, The device includes: The time window determination module is configured to determine multiple pre-divided time windows; A creation module is configured to create a counting unit associated with each target time window within the plurality of time windows; the counting unit counts service requests of a preset type within the target time window, the preset type of service requests including rollback requests for the target service state; The update module is configured to update the number of service requests of the preset type recorded in the counting unit if a service request of the preset type occurs within the target time window. The destruction module is configured to destroy the counting unit associated with the target time window in response to the end of the target time window's lifecycle.

9. An electronic device, characterized in that, The device includes a memory and a processor, the memory being used to store computer instructions that can be executed on the processor, and the processor being used to implement the method of any one of claims 1 to 7 when executing the computer instructions.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method according to any one of claims 1 to 7.

Images