Online service request processing method and device, computer equipment and storage medium

Abstract

The invention relates to an online service request processing method and device, computer equipment and a storage medium. The method comprises the following steps: acquiring a target load index value, and determining a token generation rate corresponding to each token bucket based on the target load index value; obtaining an online service request, and determining a target token bucket corresponding to the online service request from the token buckets based on the service type of the online service request; the tokens in the target token bucket are generated based on the corresponding token generation rate; and under the condition that the target token corresponding to the online service request is obtained from the target token bucket, processing the online service request to obtain service response information corresponding to the online service request. By adopting the method, the integrity of online service request processing can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an online service request processing method, apparatus, computer equipment, and storage medium. Background Technology

[0002] With the development of computer technology, bank online systems need to handle massive online business requests. When encountering business peaks (such as payroll disbursement and e-commerce promotion payments) or abnormal traffic (such as malicious order brushing and interface scanning), a large number of online business requests will overwhelm the bank's online system, which may lead to problems such as transaction timeouts and discrepancies between accounts and actual transactions.

[0003] In traditional technologies, bank online systems typically use rate limiting algorithms to limit the number of online service requests. When the number of online service requests exceeds a preset limit, the system directly returns a failure response for the requests exceeding the preset limit, resulting in some online service requests not being processed and low integrity in the processing of online service requests. Summary of the Invention

[0004] Therefore, it is necessary to provide an online service request processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the integrity of online service request processing in response to the above-mentioned technical problems.

[0005] Firstly, this application provides an online service request processing method. The method includes:

[0006] Obtain the target load metric value, and determine the token generation rate corresponding to each token bucket based on the target load metric value;

[0007] A network service request is obtained, and based on the service type of the network service request, a target token bucket corresponding to the network service request is determined from each of the token buckets; the tokens in the target token bucket are generated based on the corresponding token generation rate;

[0008] If the target token corresponding to the online service request is obtained from the target token bucket, the online service request is processed to obtain the service response information corresponding to the online service request.

[0009] Secondly, this application also provides an online service request processing apparatus. The apparatus includes:

[0010] The rate determination module is used to obtain the target load index value and determine the token generation rate corresponding to each token bucket based on the target load index value.

[0011] The token bucket determination module is used to acquire online service requests, and based on the service type of the online service request, determine the target token bucket corresponding to the online service request from each of the token buckets; the tokens in the target token bucket are generated based on the corresponding token generation rate;

[0012] The processing module is used to process the online service request and obtain the service response information corresponding to the online service request when the target token corresponding to the online service request is obtained from the target token bucket.

[0013] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described in the first aspect.

[0014] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0015] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the first aspects.

[0016] The aforementioned online service request processing method, apparatus, computer equipment, storage medium, and computer program product acquire a target load index value and determine the token generation rate corresponding to each token bucket based on the target load index value; acquire an online service request and, based on the service type of the online service request, determine the target token bucket corresponding to the online service request from each token bucket; generate tokens in the target token bucket based on the corresponding token generation rate; and, if the target token corresponding to the online service request is obtained from the target token bucket, process the online service request to obtain the service response information corresponding to the online service request. The token generation rate of each token bucket is dynamically adjusted by the target load metric to match the token generation rate with the load of the computer equipment. Under low load, the token generation rate is increased to fully utilize the computer equipment's resources, while under high load, the token generation rate is decreased to prevent the computer equipment from overloading and crashing. This ensures that the computer equipment provides target tokens to as many online service requests as possible without overloading and crashing, thus processing more online service requests and improving the integrity of online service request processing. Furthermore, by setting different token buckets for different service types, fine-grained rate limiting management at the service type level is achieved. This ensures that real-time service types are still processed more even under high load, rather than being indiscriminately discarded by limiting policies, further improving the integrity of online service request processing. Attached Figure Description

[0017] Figure 1 This is an application environment diagram of an online service request processing method in one embodiment;

[0018] Figure 2 This is a flowchart illustrating an online service request processing method in one embodiment;

[0019] Figure 3 This is a system parameter configuration table in one embodiment;

[0020] Figure 4 This is a schematic diagram illustrating the process of determining the token generation rate in one embodiment;

[0021] Figure 5 This is a schematic diagram of a queue hierarchy design in one embodiment;

[0022] Figure 6 This is a schematic diagram of the process for determining service response information in one embodiment;

[0023] Figure 7 This is a schematic diagram of the core process of the message queue buffer retry module in one embodiment;

[0024] Figure 8 This is a schematic diagram of the core components, technology selection, and core functions of each layer in a layered architecture in one embodiment.

[0025] Figure 9 This is a flowchart illustrating an online service request processing method in one embodiment;

[0026] Figure 10 This is a structural block diagram of an online service request processing device in one embodiment;

[0027] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0029] The online service request processing method provided in this application embodiment can be applied to, for example, Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated on server 104 or placed on a cloud or other network server. Both the terminal and the server can be used independently to execute the online service request processing method provided in this embodiment. The terminal and server can also work together to execute the online service request processing method provided in this embodiment. For example, server 104 obtains a target load index value, determines the token generation rate corresponding to each token bucket based on the target load index value; obtains an online service request, and determines the target token bucket corresponding to the online service request from each token bucket based on the service type of the online service request; the tokens in the target token bucket are generated based on the corresponding token generation rate; when the target token corresponding to the online service request is obtained from the target token bucket, the online service request is processed to obtain the service response information corresponding to the online service request. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. Server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0030] In one embodiment, such as Figure 2 As shown, an online service request processing method is provided. This embodiment uses the application of this method to a computer device as an example for illustration, including steps 202 to 206.

[0031] Step 202: Obtain the target load metric value and determine the token generation rate corresponding to each token bucket based on the target load metric value.

[0032] Online transaction requests refer to data packets of business operation instructions initiated by clients (such as mobile banking applications or Point of Sale (POS) terminals) to the server. In the online banking transaction system, these can be understood as standardized data packets exchanged in real-time between the client and server to complete a specific transaction. Target load metrics are key performance data collected in real-time from the online banking system, reflecting the current processing pressure of online transaction requests. Target load metrics include, but are not limited to, processor (Central Processing Unit) utilization, business response time, and database lock wait count. A token bucket is a container for generating and storing tokens. The token bucket can continuously generate tokens according to the configured token generation rate. Token buckets can be built based on the Nginx (Engine X) rate limiting module and deployed at the Nginx gateway layer. At the Nginx gateway layer of the online banking system, independent token buckets can be configured for different business types, including, but not limited to, transfer token buckets for transfer transactions, query token buckets for query transactions, payment token buckets for payment transactions, and export token buckets for export transactions. Different token buckets correspond to different business types; that is, online business requests of different business types obtain tokens from different token buckets. Token generation rate refers to the rate at which tokens are generated. For example, a token generation rate of 1000 tokens / second means that 1000 tokens are generated per second, or a token generation rate of 800 tokens / second means that 800 tokens are generated per second.

[0033] For example, the computer device obtains the target load index value and determines the token generation rate corresponding to each token bucket based on the target load index value.

[0034] In one embodiment, the computer device acquires a target load metric value based on a preset time interval, and determines the token generation rate corresponding to each token bucket based on the target load metric value. The preset time interval is a pre-set time interval used to acquire the target load metric value, and can be set according to actual needs; no limitation is imposed here.

[0035] Step 204: Obtain the online service request; based on the service type of the online service request, determine the target token bucket corresponding to the online service request from each token bucket; the tokens in the target token bucket are generated based on the corresponding token generation rate.

[0036] The service type refers to the category of the online service request, which includes, but is not limited to, transfer, query, payment, and export services. Service types can be represented by service codes, which are identifiers that characterize the service type. For example, 0100 represents a transfer, 0200 represents a query, and 0300 represents a payment. The target token bucket is the token bucket that matches the service type of the online service request; that is, the token bucket corresponding to the service type of the online service request.

[0037] For example, a computer device obtains an online service request, parses the online service request to obtain the service type of the online service request, and determines the token bucket corresponding to the service type of the online service request from multiple token buckets as the target token bucket corresponding to the online service request. The target token bucket generates a token based on the corresponding token generation rate.

[0038] In one embodiment, the computer device can use the Nginx ngx_http_limit_req_module to parse the service code in the header of the online service request, and determine the target token bucket corresponding to the service code of the online service request from among multiple token buckets. The target token bucket generates tokens based on the corresponding token generation rate. If the service code represents the service type, the service code representing the service type is directly used to match the target token bucket.

[0039] Step 206: If the target token corresponding to the online service request is obtained from the target token bucket, the online service request is processed to obtain the service response information corresponding to the online service request.

[0040] The target token refers to the token corresponding to the online service request, obtained from the target token bucket. Obtaining the target token for the online service request indicates that the bank's online system can immediately process the request. The service response information refers to the result of the bank's online system processing the online service request; it is the information returned to the client.

[0041] For example, if a token exists in the target token bucket, the computer device retrieves the target token corresponding to the online service request from the target token bucket, then processes the online service request to obtain the service response information corresponding to the online service request.

[0042] In one embodiment, if the computer device has a token in the target token bucket of the Nginx gateway layer, it retrieves the target token corresponding to the online service request from the target token bucket of the Nginx gateway layer, and then forwards the online service request to the application layer. The application layer processes the online service request and obtains the corresponding service response information. Here, the application layer refers to the computing layer that carries the core business logic and domain model. It is responsible for receiving legitimate online service requests from the gateway layer, executing specific business operations, data processing, state management, and transaction coordination, and generating service response information.

[0043] In the aforementioned online service request processing method, the token generation rate of each token bucket is dynamically adjusted based on the target load index value. This ensures that the token generation rate of the token bucket matches the load of the computer equipment. Under low load, the token generation rate is increased to fully utilize the computer equipment's resources, while under high load, the token generation rate is decreased to prevent the computer equipment from overloading and crashing. This guarantees that the computer equipment can provide target tokens for as many online service requests as possible without overloading and crashing, thus processing more online service requests and improving the integrity of online service request processing. Furthermore, by setting different token buckets for different service types, fine-grained rate limiting management at the service type level is achieved. This ensures that real-time service types can still be processed more even under high load, rather than being indiscriminately discarded by the limiting policy, further improving the integrity of online service request processing.

[0044] In one embodiment, when the target load metric values ​​include processor utilization, business response time, and database lock wait count, determining the token generation rate for each token bucket based on the target load metric values ​​includes:

[0045] The response ratio is determined based on the business response time and response threshold; the lock wait ratio is determined based on the number of database lock waits and the lock wait threshold; the load factor is determined based on the processor utilization, response ratio, and lock wait ratio; and the token generation rate for each token bucket is determined based on the relationship between the load factor and the load threshold.

[0046] Among these, processor utilization refers to the percentage of time the central processing unit (CPU) spends executing non-idle tasks (such as calculations, logical judgments, and data processing). Service response time refers to the time from when a terminal sends an online service request to the bank's online system to when the terminal receives the service response information from the bank's online system. Database lock wait count refers to the number of database sessions that have to enter a waiting state because they need to access data resources that are locked by other sessions. Response threshold refers to the pre-set, maximum allowed service response time. Response percentage is the ratio between service response time and response threshold; it quantifies the severity of response latency in the bank's online system. Lock wait threshold refers to the pre-set, maximum allowed number of database lock waits. Lock wait percentage is the ratio between the number of database lock waits and lock wait threshold; it quantifies the intensity of database resource contention. Load factor is a numerical value characterizing the overall load status of computer equipment; it is a comprehensive evaluation value calculated by weighted fusion of processor utilization, response percentage, and lock wait percentage. The load threshold is a pre-set critical value that divides the load coefficient. Multiple load thresholds can be set, such as the first load threshold and the second load threshold.

[0047] For example, the computer device determines the ratio between the business response time and the response threshold as the response ratio, and the ratio between the number of database lock waits and the lock wait threshold as the lock wait ratio. The processor utilization, response ratio and lock wait ratio are weighted and fused to obtain the load coefficient. Then, based on the relationship between the load coefficient and the load threshold, the token generation rate corresponding to each token bucket is determined.

[0048] In one embodiment, the load coefficient is determined based on processor utilization, response ratio, and lock wait ratio. This includes adding the processor utilization to a first weight, the response ratio to a second weight, and the lock wait ratio to a third weight to obtain the load coefficient. The first weight is a pre-set weight representing the importance of processor utilization. The second weight is a pre-set weight representing the importance of response ratio. The third weight is a pre-set weight representing the importance of lock wait ratio. For example, if the first weight is 0.4, the second weight is 0.3, and the third weight is 0.4, then the load coefficient = 0.4 × response ratio + 0.3 × response ratio + 0.3 × lock wait ratio.

[0049] In this embodiment, a load factor is determined to characterize the overall load status of the computer equipment by using processor utilization (which measures the utilization of the central processing unit), response ratio (which measures the severity of response latency in the bank's online system), and lock wait ratio (which measures the intensity of database resource contention). This allows the load factor to comprehensively and accurately characterize the true load status of the computer equipment, avoiding misjudgments of the load status that may be caused by a single load indicator value. Then, the token generation rate corresponding to each token bucket is determined based on the relationship between the load factor and the load threshold, so that the token generation rate of the token bucket matches the load status of the computer equipment.

[0050] In one embodiment, the token generation rate for each token bucket is determined based on the relationship between the load factor and the load threshold, including:

[0051] Obtain the preset rate corresponding to each token bucket; when the load factor is less than the first load threshold, determine the token generation rate corresponding to the token bucket based on the preset rate and the boost ratio; the boost ratio is greater than one; when the load factor is equal to or greater than the first load threshold and less than the second load threshold, determine the preset rate corresponding to the token bucket as the token generation rate corresponding to the token bucket; the second load threshold is greater than the first load threshold; when the load factor is equal to or greater than the second load threshold, if the service type corresponding to the token bucket is a real-time service type, then determine the preset rate corresponding to the token bucket as the token generation rate corresponding to the token bucket; if the service type corresponding to the token bucket is a non-real-time service type, then determine the token generation rate corresponding to the token bucket based on the preset rate and the downgrade ratio; the downgrade ratio is less than one.

[0052] The preset rate refers to the baseline rate for token generation set for the token bucket during the initialization or configuration phase. Different service types may have different preset rates for their token buckets; the higher the priority of the service type, the higher the preset rate of its corresponding token bucket. For example, the system parameter configuration table is as follows: Figure 3 As shown, the priorities from highest to lowest are: transfer, payment, query, and export. The preset rate of the token bucket corresponding to the transfer is higher than that of the payment, which is higher than that of the query, which is higher than that of the export. Specifically, the preset rate of the token bucket corresponding to the transfer is 1200 instructions / second, the preset rate of the token bucket corresponding to the payment is 1000 instructions / second, the preset rate of the token bucket corresponding to the query is 300 instructions / second, and the preset rate of the token bucket corresponding to the export is 1200 instructions / second.

[0053] The first load threshold is the critical load threshold used to distinguish between low load and normal load. The boost ratio is a coefficient that increases the instruction generation rate; the boost ratio is greater than one, for example, 1.2 or 1.5. The second load threshold is the critical load threshold used to distinguish between normal load and high load. The downgrade ratio is a coefficient that decreases the instruction generation rate; the downgrade ratio is less than one, for example, 0.5 or 0.6. Real-time business types refer to business types with extremely high processing timeliness requirements, such as transfer and payment transactions. Non-real-time business types refer to business types with relatively lower processing timeliness requirements, such as query and export transactions.

[0054] For example, the computer device obtains the preset rate corresponding to each token bucket; compares the load coefficient with a first load threshold, and compares the load coefficient with a second load threshold; if the load coefficient is less than the first load threshold, multiplies the preset rate corresponding to the token bucket by an increase ratio greater than one to obtain the token generation rate corresponding to the token bucket; if the load coefficient is equal to or greater than the first load threshold and less than the second load threshold, determines the preset rate corresponding to the token bucket as the token generation rate corresponding to the token bucket; if the load coefficient is equal to or greater than the second load threshold, and the service type corresponding to the token bucket is a real-time service type, then the preset rate corresponding to the token bucket is determined as the token generation rate corresponding to the token bucket; if the service type corresponding to the token bucket is a non-real-time service type, then the preset rate corresponding to the token bucket is multiplied by a decrease ratio less than one to obtain the token generation rate corresponding to the token bucket.

[0055] In one embodiment, the process for determining the token generation rate is illustrated as follows: Figure 4 As shown, it includes:

[0056] Step 402: Obtain target load metrics. Based on preset time intervals, obtain processor utilization, business response time, and database lock wait count.

[0057] Step 404: Determine the load factor. The ratio between the business response time and the response threshold is determined as the response percentage, and the ratio between the number of database lock waits and the lock wait threshold is determined as the lock wait percentage. The processor utilization, response percentage, and lock wait percentage are weighted and combined to obtain the load factor.

[0058] Step 406, load factor range determination. Compare the load factor with the first load threshold, and compare the load factor with the second load threshold.

[0059] Step 408: If the load factor is less than the first load threshold, determine the token generation rate. When the load factor is less than the first load threshold, multiply the preset rate corresponding to the token bucket by an increase ratio greater than one to obtain the token generation rate corresponding to the token bucket.

[0060] Step 410: If the load factor is greater than the first load threshold and less than the second load threshold, determine the token generation rate. If the load factor is equal to or greater than the first load threshold and less than the second load threshold, determine the preset rate corresponding to the token bucket as the token generation rate corresponding to the token bucket.

[0061] Step 412: If the load factor is equal to or greater than the second load threshold, determine the token generation rate. If the service type corresponding to the token bucket is a real-time service type, then the preset rate corresponding to the token bucket is determined as the token generation rate corresponding to the token bucket. If the service type corresponding to the token bucket is a non-real-time service type, then the preset rate corresponding to the token bucket is multiplied by a reduction ratio less than one to obtain the token generation rate corresponding to the token bucket.

[0062] Step 414: Generate Nginx configuration directives. After determining the token generation rate corresponding to the token bucket, generate the Nginx configuration directives.

[0063] Step 416: Push the Nginx configuration directives to the Nginx gateway layer and adjust the token generation rate corresponding to each token bucket.

[0064] Step 418: Record the token generation rate adjustment log. The rate adjustment log includes, but is not limited to, the token generation rate before adjustment, the token generation rate after adjustment, the load factor, and the adjustment time.

[0065] In this embodiment, a load factor less than the first load threshold indicates that the computer device is in a low-load state. By increasing the ratio, the token generation rate is increased so that more online service requests can obtain the target token, making full use of the computer device's idle resources to process more online service requests. A load factor equal to or greater than the first load threshold and less than the second load threshold indicates that the computer device is in a normal load state. At this time, the baseline preset rate is maintained to ensure the stable operation of the computer device. A load factor equal to or greater than the second load threshold indicates that the computer device is in a high-load state. In the high-load state, only the token generation rate of the token bucket for non-real-time service types is reduced, while the token generation rate of the token bucket for real-time service types remains at the baseline preset rate. This ensures that the token supply for real-time services is not affected while ensuring the stable operation of the computer device. The above-mentioned hierarchical and service-specific token generation rate determination mechanism not only ensures the stable operation of the computer device but also realizes intelligent scheduling of resources among services of different priorities. Thus, under the premise of overall load controllability, it maximizes the processing speed of real-time service requests and improves the integrity and reliability of online service request processing.

[0066] In one embodiment, the online service request processing method further includes:

[0067] If the target token corresponding to the online service request is not obtained from the target token bucket, the request type of the online service request is determined based on the service type of the online service request. If the request type of the online service request is a non-real-time request, the target queue corresponding to the online service request is determined based on the service type of the online service request. The online service request is saved to the target queue. The retry interval and retry count corresponding to the target queue are obtained, and the online service request is processed based on the retry interval and retry count to obtain the service response information corresponding to the online service request.

[0068] Request type refers to the basic category categorized based on the timeliness requirements of online service requests. Request types can be divided into real-time requests and non-real-time requests. Non-real-time requests are online service requests that are allowed to be processed after a certain delay, and their service response information is not immediately needed; examples include query and export requests. Real-time requests are online service requests that need to be processed immediately, and their service response information is immediately needed; examples include transfer and payment requests. The target queue is the message queue used to store online service requests. The retry interval is the time interval between two consecutive attempts by a message queue consumer to process the same online service request. The number of retries is the maximum number of times a message queue consumer can attempt to process the same online service request; exceeding the number of retries will result in the online service request being considered a final processing failure.

[0069] For example, if the target token corresponding to the online service request is not obtained from the target token bucket, the computer device determines the request type of the online service request based on its service type. If the request type is a non-real-time request, the device determines the service priority corresponding to the online service request based on its service type, designates the message queue corresponding to the service priority as the target queue, saves the online service request to the target queue, obtains the retry interval and retry count corresponding to the target queue, and processes the online service request based on the retry interval and retry count to obtain the service response information corresponding to the online service request. Here, service priority refers to the order in which online service requests are processed. The target queue corresponds to the service priority of the online service request.

[0070] In one embodiment, a schematic diagram of the queue hierarchy design is shown below. Figure 5As shown, the system includes a core non-real-time queue, a regular business queue, and a low-priority queue. The core non-real-time queue is configured for credit bill inquiries and points redemption inquiries, has a high priority, uses persistent storage, has a 24-hour expiration time, and is prioritized for queue consumption resources (a separate consumer group with a concurrency of ≥5). The regular business queue is configured for transaction record exports and historical detail inquiries, has a medium priority, uses persistent storage, and has a 72-hour expiration time. The low-priority queue is configured for marketing activity inquiries and non-critical information inquiries, has a low priority, uses both memory and disk storage, has a 12-hour expiration time, and reuses a consumer group (concurrency = 2). Based on this queue hierarchy design, the target queue corresponding to the online business request is determined based on the business type of the online business request. This includes: determining the target scenario corresponding to the online business request based on its business type; identifying the message queue corresponding to the same business scenario as the target scenario; and saving the online business request to the target queue. The target scenario refers to the business scenario of the online service request. The target scenario can be one of the following: credit bill inquiry, points redemption inquiry, transaction record export, historical details inquiry, marketing activity inquiry, and non-critical information inquiry.

[0071] In one embodiment, when the online service request is a real-time request, the prompt message is determined to be the service response information corresponding to the online service request. The prompt message refers to information used to indicate that the online service request processing has failed, and the prompt message can suggest that the user re-initiate the online service request.

[0072] In one embodiment, the online service request processing method further includes: determining the retry failure rate for each message queue; and stopping the retrieval of online service requests from the message queue and sending an alarm message if the retry failure rate exceeds a failure rate threshold. The retry failure rate is the ratio of online service requests that fail to be processed after a certain number of retries to the total number of online service requests processed in the message queue. The alarm message is a message sent to operations and maintenance personnel to remind them to investigate business logic anomalies.

[0073] In this embodiment, when an online service request fails to obtain a target token, for online service requests that are not real-time, a target queue for saving the online service request is determined based on the service type corresponding to the online service request. Then, the online service request is saved to the target queue, and the online service request is processed again according to the retry interval and retry count of the target queue, thereby obtaining the service response information corresponding to the online service request. This ensures that non-real-time services will not be permanently lost due to temporary congestion of computer equipment. By continuously digesting rate-limited online service requests, the integrity of online service request processing is improved.

[0074] In one embodiment, obtaining the retry interval corresponding to the target queue includes:

[0075] Obtain the preset interval corresponding to the target queue; determine the adjustment coefficient based on the relationship between the load coefficient and the coefficient threshold; the adjustment coefficient is proportional to the load coefficient; determine the retry interval corresponding to the target queue based on the preset interval and the adjustment coefficient.

[0076] The preset interval refers to the baseline retry interval initially configured for the message queue, which is a dynamically adjusted baseline value. The coefficient threshold refers to the tiered critical value of the load coefficient, used to divide different load state intervals and trigger corresponding retry interval adjustment strategies. The coefficient threshold can be equal to or different from the load threshold. The adjustment coefficient is a proportional factor calculated based on the relationship between the load coefficient and the coefficient threshold; the adjustment coefficient is positively correlated with the load coefficient.

[0077] For example, the computer device obtains the preset interval corresponding to the target queue, compares the load coefficient and the coefficient threshold, determines the adjustment coefficient according to the relationship between the load coefficient and the coefficient threshold, and multiplies the preset interval by the adjustment coefficient to obtain the retry interval corresponding to the target queue.

[0078] In one embodiment, determining an adjustment coefficient based on the relationship between the load coefficient and a coefficient threshold includes: if the load coefficient is less than a first coefficient threshold, determining the first coefficient as the adjustment coefficient; the first coefficient is less than one; if the load coefficient is equal to or greater than the first coefficient threshold and less than a second coefficient threshold, determining the second coefficient as the adjustment coefficient; the second coefficient is equal to one, and the second coefficient threshold is greater than the first coefficient threshold; if the load coefficient is equal to or greater than the second coefficient threshold, determining the third coefficient as the adjustment coefficient; the third coefficient is greater than one. Wherein, the first coefficient threshold, the second coefficient threshold, the first coefficient, the second coefficient, and the third coefficient can be pre-set coefficients, for example, the first coefficient threshold is 50%, the second coefficient threshold is 70%, the first coefficient is 0.5, the second coefficient is 1, and the third coefficient is 2.

[0079] In this embodiment, the adjustment coefficient is dynamically determined by the load factor, so that the retry interval can automatically expand and contract according to the system load status. That is, when the system is under high load, the retry interval is extended by increasing the adjustment coefficient to reduce the repeated pressure on the core system. When the system is under low load, the retry interval is shortened by decreasing the adjustment coefficient to accelerate the digestion and processing of backlogged online service requests. This avoids the risk of increasing the system burden due to frequent retries under high load, and ensures that the buffer queue can be quickly cleared when system resources are restored. Thus, while ensuring system stability, it maximizes the final processing success rate of rate-limited online service requests and improves the integrity and reliability of online service request processing.

[0080] In one embodiment, such as Figure 6 As shown, online service requests are processed based on retry intervals and retries to obtain the corresponding service response information, including:

[0081] Step 602: Based on the retry interval, retrieve online service requests from the target queue.

[0082] For example, a computer device retrieves online service requests from a target queue based on the retry interval of the target queue.

[0083] Step 604: Obtain the request identifier corresponding to the online service request, and based on the request identifier, obtain the processing status corresponding to the online service request.

[0084] The request identifier is a unique identification code assigned to represent an online service request. It is used to accurately track and distinguish the lifecycle of different online service requests in a distributed system. The request identifier can be a Universally Unique Identifier (UUID), which is used as an idempotent identifier. The processing status is an identifier used to represent the processing stage of the online service request. Processing status includes, but is not limited to, pending retry, retrying, successful processing, retry failure, and discarded. Pending retry means the online service request has entered the message queue and is waiting to be consumed. Retrying means the queue consumer is attempting to forward the online service request to the application layer. Successful processing means the online service request has been successfully forwarded and executed normally. Retry failure means the retry count has been reached, but the online service request has not been successfully executed. Discarded means the request has exceeded the processing time.

[0085] For example, the computer device obtains the request identifier corresponding to the online service request, and based on the request identifier, retrieves the processing status corresponding to the online service request from the rate-limiting service status table. The rate-limiting service status table is a table that records the processing stages of an online service request.

[0086] In one embodiment, after obtaining the processing status of the online service request, feedback information corresponding to the processing status is sent to the terminal that initiated the online service request. This feedback information informs the user of the processing stage of the online service request. For example, if the processing status is "Processed successfully," the feedback information "Service completed, results available" is pushed; if the processing status is "Retrying," the feedback information "Service busy, retrying for you" is pushed; if the processing status is "Retry failed," the feedback information "Service recorded, will be automatically processed when the system is idle, results will be notified to you as soon as possible," and a human customer service entry is provided; if the processing status is "Discarded," the feedback information "Service processing timed out, we suggest you re-initiate later."

[0087] Step 606: If the processing status of the online service request is pending retry, call the application layer service interface corresponding to the online service request to process the online service request.

[0088] Application layer service interfaces refer to the standardized call entry points exposed by backend business systems for handling specific business processes.

[0089] For example, when the processing status of an online service request is pending retry, the computer device calls the application layer service interface corresponding to the online service request to process the online service request.

[0090] Step 608: If the application layer service interface fails to process the online service request, update the processing count corresponding to the online service request to obtain the updated processing count.

[0091] Here, "processing failure" refers to the state where no successful response is returned after calling the application layer service interface. The reasons for processing failure may include network timeout, service exception, or business validation failure. "Processing count" refers to the cumulative number of times the application layer service interface has been called for the same online business request. The updated processing count is the number obtained by adding one to the total number of processed requests.

[0092] For example, if the application layer service interface fails to process the online service request, the computer device updates the processing count corresponding to the online service request to obtain the updated processing count.

[0093] Step 610: If the updated processing count is less than the retry count, the online service request is saved to the target queue. The step of retrieving the online service request from the target queue based on the retry interval is repeated until the application layer service interface successfully processes the online service request, or the updated processing count equals the retry count, and the business response information corresponding to the online service request is obtained.

[0094] For example, the computer device compares the updated processing count with the retry count. If the updated processing count is less than the retry count, the online service request is saved to the target queue. The steps of retrieving the online service request from the target queue based on the retry interval are repeated until the application layer service interface successfully processes the online service request, or the updated processing count equals the retry count, and the service response information corresponding to the online service request is obtained.

[0095] In one embodiment, the core process diagram of the message queue buffer retry module is as follows: Figure 7 As shown, the system includes a queue hierarchy design (702), an intelligent retry mechanism (704), a state loop and customer notification (706), and a monitoring and alarm design (708). The queue hierarchy design (702) involves setting up multiple message queues (core non-real-time queue, ordinary service queue, and low-priority queue) and allocating queue resources to these queues. The intelligent retry mechanism (704) retryes online service requests in the message queues based on the retry interval and the number of retries, obtaining the service processing result. If the processing result is successful, the processing status of the online service request in the rate-limiting service status table is updated, and a service response information is sent, indicating that the online service request processing is complete. If the processing result is a failure, retrying is performed based on the retry interval until the number of processing attempts equals the number of retries. The state loop and customer notification (706) synchronizes the processing status of online service requests in the rate-limiting service status table and multi-channel push feedback information in real time. The monitoring and alarm design 708 includes collecting real-time monitoring metrics (such as queue length, inbound / outbound rate per second, retry success rate, failure rate, and core load coefficient correlation curve), determining tiered alarm thresholds (e.g., if the queue length exceeds 1000 entries, or the retry failure rate is ≥30%, it is determined as a general alarm; if the queue length exceeds 5000 entries, or the retry success rate is 0 for 10 consecutive minutes, it is determined as a critical alarm), pushing alarm information through alarm channels (operation and maintenance platform pop-ups, real-time message push, telephone alarms), and operation and maintenance intervention.

[0096] In this embodiment, the collaborative mechanism of request identifier and processing status effectively prevents the repeated processing of online service requests; by updating the processing count in real time and comparing it with the retry count threshold, multiple processing opportunities are provided for online service requests, while avoiding the resource consumption caused by unlimited retries to the system.

[0097] In an exemplary embodiment, the layered architecture for online service request processing includes a client layer, a gateway layer, an application layer, a message queue buffer layer, and a log monitoring layer. A schematic diagram of the core components, technology selections, and core functions of each layer in the layered architecture is shown below. Figure 8As shown, the client layer is mainly used to send online service requests and receive service response information, the gateway layer deploys multiple token buckets, the application layer is mainly used to provide application layer service interfaces, the message queue buffer layer is configured with multiple message queues, and the log monitoring layer is mainly used to monitor the core load.

[0098] Based on the layered architecture for online service request processing described above, a method for processing online service requests is proposed. The flowchart of this method is shown below. Figure 9 As shown, it includes:

[0099] (1) The client sends an online service request.

[0100] (2) The gateway layer accepts online service requests.

[0101] (3) The gateway layer parses the online service request to obtain the service type of the online service request.

[0102] (4) The gateway layer matches the target token bucket for the online service request. The token bucket corresponding to the service type of the online service request among multiple token buckets is determined as the target token bucket for the online service request. The target token bucket generates tokens based on the corresponding token generation rate. The process of determining the token generation rate includes: the gateway layer obtaining the target load index value based on a preset time interval, determining the load coefficient based on the target load index value, and determining the token generation rate corresponding to each token bucket based on the load coefficient.

[0103] (5) The gateway layer determines whether there are available tokens in the target token bucket.

[0104] (6) If there is an available token in the target token bucket, the target token corresponding to the online service request is obtained, and the gateway layer forwards the online service request to the application layer.

[0105] (7) The application layer processes online service requests.

[0106] (8) The application layer sends the business response information to the client.

[0107] (9) If there are no available tokens in the target token bucket, determine whether the online service request is a non-real-time request.

[0108] (10) If the online service request is a real-time request, the gateway layer will send a prompt message to the client.

[0109] (11) If the online service request is a non-real-time request, the gateway layer determines the target queue corresponding to the online service request based on the service type of the online service request.

[0110] (12) Save the online service request to the target queue.

[0111] (13) The message queue buffer layer obtains the load factor, determines the retry interval of the target queue based on the load factor, and then obtains the number of retries of the target queue.

[0112] (14) The message queue consumer obtains the online service request from the target queue based on the retry interval; obtains the request identifier corresponding to the online service request; and obtains the processing status corresponding to the online service request from the rate limiting service status table based on the request identifier; and forwards the online service request to the application layer if the processing status corresponding to the online service request is pending retry.

[0113] (15) If the forwarding is successful, the application layer processes the online service request and sends the service response information to the client.

[0114] (16) In the event of forwarding failure, update the number of processing requests corresponding to the online service request to obtain the updated number of processing requests; compare the updated number of processing requests with the number of retries.

[0115] (17) If the updated number of processing attempts is less than the number of retries, the online service request is saved to the target queue. The message queue consumer repeats the step of retrieving the online service request from the target queue based on the retry interval until the online service request is forwarded to the application layer. The application layer processes the online service request and sends the service response information to the client. Alternatively, the online service request is written to the log system until the updated number of processing attempts equals the number of retries. The client is then sent "The service has been recorded and will be processed when idle".

[0116] The aforementioned online service request processing method aims to address the issues of "missing gateway layer interception, static and rigid thresholds, and direct packet discarding" in bank online message rate limiting. Through a collaborative solution involving Nginx token bucket pre-control, message queue buffering, and dynamic core load balancing, it improves the processing integrity of non-real-time services while ensuring the stability of core bank transactions. Specifically, this is reflected in the following aspects:

[0117] Gateway-level pre-interception: Utilize Nginx token bucket to intercept invalid packets at the gateway layer, reducing network and computing resource consumption of the core system and lowering host load pressure.

[0118] Core transaction protection: By binding the business code to the token bucket, the token supply for core businesses such as transfers and payments is prioritized under high load to avoid interruption of financial transactions.

[0119] Non-real-time business is not lost: By combining message queues to implement buffered retry of rate-limited messages, the problem of "message dropping" in traditional solutions is solved, and the business experience of bank customers is improved.

[0120] Reduced operational costs: Rate limiting can be achieved through Nginx and message configuration adjustments without modifying the core system code, reducing the risk of core system changes.

[0121] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0122] Based on the same inventive concept, this application also provides an online service request processing apparatus for implementing the online service request processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more embodiments of the online service request processing apparatus provided below can be found in the limitations of the online service request processing method described above, and will not be repeated here.

[0123] In one embodiment, such as Figure 10 As shown, an online service request processing device is provided, including: a rate determination module 1002, a token bucket determination module 1004, and a processing module 1006, wherein:

[0124] The rate determination module 1002 is used to obtain the target load index value and determine the token generation rate corresponding to each token bucket based on the target load index value.

[0125] The token bucket determination module 1004 is used to obtain online service requests, and based on the service type of the online service request, determine the target token bucket corresponding to the online service request from each token bucket; the tokens in the target token bucket are generated based on the corresponding token generation rate.

[0126] The processing module 1006 is used to process the online service request and obtain the service response information corresponding to the online service request when the target token corresponding to the online service request is obtained from the target token bucket.

[0127] In one embodiment, the token bucket determination module 1004 is further configured to: determine the response ratio based on the business response time and the response threshold; determine the lock wait ratio based on the number of database lock waits and the lock wait threshold; determine the load coefficient based on the processor utilization, the response ratio, and the lock wait ratio; and determine the token generation rate corresponding to each token bucket based on the relationship between the load coefficient and the load threshold.

[0128] In one embodiment, the token bucket determination module 1004 is further configured to: obtain the preset rate corresponding to each token bucket; when the load coefficient is less than a first load threshold, determine the token generation rate corresponding to the token bucket based on the preset rate and the boost ratio; the boost ratio is greater than one; when the load coefficient is equal to or greater than the first load threshold and less than a second load threshold, determine the preset rate corresponding to the token bucket as the token generation rate corresponding to the token bucket; the second load threshold is greater than the first load threshold; when the load coefficient is equal to or greater than the second load threshold, if the service type corresponding to the token bucket is a real-time service type, then determine the preset rate corresponding to the token bucket as the token generation rate corresponding to the token bucket; if the service type corresponding to the token bucket is a non-real-time service type, then determine the token generation rate corresponding to the token bucket based on the preset rate and the downsizing ratio; the downsizing ratio is less than one.

[0129] In one embodiment, the processing module 1006 is further configured to: if no target token corresponding to the online service request is obtained from the target token bucket, determine the request type of the online service request based on the service type of the online service request; if the request type of the online service request is a non-real-time request, determine the target queue corresponding to the online service request based on the service type of the online service request; save the online service request to the target queue; obtain the retry interval and retry count corresponding to the target queue, and process the online service request based on the retry interval and retry count to obtain the service response information corresponding to the online service request.

[0130] In one embodiment, the processing module 1006 is further configured to: obtain a preset interval corresponding to the target queue; determine an adjustment coefficient based on the relationship between the load coefficient and the coefficient threshold; the adjustment coefficient is proportional to the load coefficient; and determine a retry interval corresponding to the target queue based on the preset interval and the adjustment coefficient.

[0131] In one embodiment, the processing module 1006 is further configured to: obtain an online service request from a target queue based on a retry interval; obtain a request identifier corresponding to the online service request, and obtain a processing status corresponding to the online service request based on the request identifier; if the processing status corresponding to the online service request is a pending retry status, call the application layer service interface corresponding to the online service request to process the online service request; if the application layer service interface fails to process the online service request, update the processing count corresponding to the online service request to obtain the updated processing count; if the updated processing count is less than the retry count, save the online service request to the target queue, and repeat the step of obtaining the online service request from the target queue based on the retry interval until the application layer service interface successfully processes the online service request, or the updated processing count is equal to the retry count, to obtain the service response information corresponding to the online service request.

[0132] Each module in the aforementioned online service request processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0133] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 11 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements an online service request processing method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0134] Those skilled in the art will understand that Figure 11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0135] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0136] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0137] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0138] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0139] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0140] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0141] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for processing online service requests, characterized in that, The method includes: Obtain the target load metric value, and determine the token generation rate corresponding to each token bucket based on the target load metric value; A network service request is obtained, and based on the service type of the network service request, a target token bucket corresponding to the network service request is determined from each of the token buckets; the tokens in the target token bucket are generated based on the corresponding token generation rate; If the target token corresponding to the online service request is obtained from the target token bucket, the online service request is processed to obtain the service response information corresponding to the online service request.

2. The method according to claim 1, characterized in that, When the target load metric values ​​include processor utilization, service response time, and database lock wait count, determining the token generation rate for each token bucket based on the target load metric values ​​includes: The response percentage is determined based on the business response time and response threshold. Based on the number of database lock waits and the lock wait threshold, the lock wait percentage is determined; The load factor is determined based on the processor utilization, the response ratio, and the lock wait ratio. Based on the relationship between the load coefficient and the load threshold, the token generation rate corresponding to each token bucket is determined.

3. The method according to claim 2, characterized in that, The step of determining the token generation rate corresponding to each token bucket based on the relationship between the load coefficient and the load threshold includes: Obtain the preset rate corresponding to each of the token buckets; If the load factor is less than the first load threshold, the token generation rate corresponding to the token bucket is determined based on the preset rate and the boost ratio corresponding to the token bucket; the boost ratio is greater than one. If the load factor is equal to or greater than the first load threshold and less than the second load threshold, the preset rate corresponding to the token bucket is determined as the token generation rate corresponding to the token bucket; the second load threshold is greater than the first load threshold. If the load factor is equal to or greater than the second load threshold, and the service type corresponding to the token bucket is a real-time service type, then the preset rate corresponding to the token bucket is determined as the token generation rate corresponding to the token bucket. If the service type corresponding to the token bucket is a non-real-time service type, then the token generation rate corresponding to the token bucket is determined based on the preset rate corresponding to the token bucket and the reduction ratio; the reduction ratio is less than one.

4. The method according to claim 1, characterized in that, The method further includes: If the target token corresponding to the online service request is not obtained from the target token bucket, the request type of the online service request is determined based on the service type of the online service request. If the request type of the online service request is a non-real-time request, the target queue corresponding to the online service request is determined based on the service type of the online service request. Save the online service request to the target queue; Obtain the retry interval and retry count corresponding to the target queue, process the online service request based on the retry interval and the retry count, and obtain the service response information corresponding to the online service request.

5. The method according to claim 4, characterized in that, Obtaining the retry interval corresponding to the target queue includes: Obtain the preset interval corresponding to the target queue; An adjustment coefficient is determined based on the relationship between the load coefficient and the coefficient threshold; the adjustment coefficient is directly proportional to the load coefficient. Based on the preset interval and the adjustment coefficient, the retry interval corresponding to the target queue is determined.

6. The method according to claim 4, characterized in that, The process of processing the online service request based on the retry interval and the number of retries to obtain the service response information corresponding to the online service request includes: Based on the retry interval, online service requests are obtained from the target queue; Obtain the request identifier corresponding to the online service request, and based on the request identifier, obtain the processing status corresponding to the online service request; If the processing status of the online service request is pending retry, the application layer service interface corresponding to the online service request is invoked to process the online service request. If the application layer service interface fails to process the online service request, the processing count corresponding to the online service request is updated to obtain the updated processing count. If the updated processing count is less than the retry count, the online service request is saved to the target queue, and the step of retrieving the online service request from the target queue based on the retry interval is repeated until the application layer service interface successfully processes the online service request, or the updated processing count is equal to the retry count, and the service response information corresponding to the online service request is obtained.

7. An online service request processing device, characterized in that, The device includes: The rate determination module is used to obtain the target load index value and determine the token generation rate corresponding to each token bucket based on the target load index value. The token bucket determination module is used to acquire online service requests and, based on the service type of the online service request, determine the target token bucket corresponding to the online service request from each of the token buckets; the tokens in the target token bucket are generated based on the corresponding token generation rate. The processing module is used to process the online service request and obtain the service response information corresponding to the online service request when the target token corresponding to the online service request is obtained from the target token bucket.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

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

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images