Service request processing method and device, computer equipment and storage medium

Abstract

The invention belongs to the technical field of data processing, and relates to a service request processing method and device, computer equipment and a storage medium, and the method comprises the steps: receiving a service request input by a user; calling a target interface corresponding to the service request, and obtaining target timeout time corresponding to the target interface; based on the timed scheduling task, obtaining a target current limiting rule corresponding to the target interface from a cache database; performing current limiting verification on the service request based on the target current limiting rule; if the service request passes the current limiting verification, processing the service request, and performing timeout verification on the service request based on the target timeout time; if the service request passes the overtime verification, obtaining response data generated after processing the service request; and returning the response data to the user based on the target interface. The business request processing method and device can be applied to business request processing scenes in the financial science and technology field and the medical field, the business request processing flexibility is improved, and the system stability and reliability are improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology and can be applied to fields such as financial technology and digital medicine, and in particular to business request processing methods, devices, computer equipment and storage media. Background Art

[0002] In existing system request processing architectures, when faced with a large influx of requests, system resources are quickly consumed, easily leading to crashes and difficulty ensuring stable operation in high-concurrency scenarios. This results in a lack of flexibility in request processing, an inability to dynamically adjust processing strategies based on actual conditions, and poor system stability.

[0003] Specifically, traditional systems typically use simple sequential processing or fixed-rule scheduling when processing requests, lacking consideration of multi-dimensional factors such as request priority and resource usage. In the financial sector, taking securities trading systems as an example, when market conditions fluctuate drastically, a large number of trading requests can flood in instantly. Because traditional systems are unable to effectively identify and process high-priority requests (such as large trades and emergency stop-loss orders), these critical requests may be delayed, resulting in financial losses for clients and affecting the reputation and competitiveness of securities firms.

[0004] In the healthcare sector, hospital information management systems face a large number of patient requests during peak hours (such as registration and bill payment peaks). Traditional systems are unable to properly schedule requests based on their urgency (e.g., emergency room registrations, critically ill patient examination appointments). This can result in untimely responses to urgent medical needs, delaying treatment and endangering patients' lives and health.

[0005] Therefore, there is an urgent need to provide a system request processing method with high concurrent processing capabilities, the ability to flexibly respond to requests and strong stability, so as to improve the service quality and reliability of the system in different scenarios. Summary of the Invention

[0006] The purpose of the embodiments of the present application is to propose a business request processing method, apparatus, computer equipment and storage medium to solve the technical problem that the existing request processing method lacks flexibility and leads to poor system stability.

[0007] In a first aspect, a service request processing method is provided, comprising:

[0008] Receive business requests input by users;

[0009] Calling a target interface corresponding to the service request and obtaining a target timeout period corresponding to the target interface;

[0010] Based on a preset timed scheduling task, a target current limiting rule corresponding to the target interface is obtained from a pre-built cache database;

[0011] Performing a current limiting check on the service request based on the target current limiting rule;

[0012] If the service request passes the current limiting check, the service request is processed based on a preset processing strategy, and a timeout check is performed on the service request based on the target timeout period;

[0013] If the service request passes the timeout check, obtaining response data generated after processing the service request;

[0014] Based on the target interface, the response data is returned to the user.

[0015] In a second aspect, a service request processing device is provided, comprising:

[0016] A receiving module, used to receive a service request input by a user;

[0017] A first processing module is configured to call a target interface corresponding to the service request and obtain a target timeout period corresponding to the target interface;

[0018] A first acquisition module is used to acquire a target current limiting rule corresponding to the target interface from a pre-built cache database based on a preset timed scheduling task;

[0019] A verification module, configured to perform a flow limiting verification on the service request based on the target flow limiting rule;

[0020] A second processing module is configured to process the service request based on a preset processing strategy if the service request passes the current limiting check, and perform a timeout check on the service request based on the target timeout period;

[0021] A second acquisition module is used to obtain response data generated after processing the business request if the business request passes the timeout check;

[0022] A returning module is used to return the response data to the user based on the target interface.

[0023] In a third aspect, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned service request processing method when executing the computer program.

[0024] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned service request processing method are implemented.

[0025] In the solution implemented by the above-mentioned business request processing method, device, computer equipment and storage medium, a business request input by a user is first received; then the target interface corresponding to the business request is called, and the target timeout time corresponding to the target interface is obtained; then, based on a preset timed scheduling task, the target flow limiting rule corresponding to the target interface is obtained from a pre-built cache database; subsequently, the target flow limiting rule performs flow limiting verification on the business request; if the business request passes the flow limiting verification, the business request is processed based on a preset processing strategy, and a timeout verification is performed on the business request based on the target timeout time; if the business request passes the timeout verification, the response data generated after processing the business request is obtained; finally, the target interface returns the response data to the user. Based on the above processing flow, after receiving the business request input by the user, this application will obtain the target flow limiting rules that match the target interface corresponding to the business request from the pre-built cache database based on the use of timed scheduling tasks. After detecting that the business request passes the flow limiting check based on the use of the target flow limiting rules, it will process the business request based on the use of the processing strategy, and perform a timeout check on the business request based on the target timeout time of the target interface. Subsequently, after detecting that the business request passes the timeout check, the response data generated after processing the business request is obtained, and then the response data is returned to the user based on the use of the target interface. In this way, this application processes the business request based on the combination of flow limiting check processing and timeout check processing, which can effectively avoid the system crash due to too many business requests, ensure that the system can still operate normally under high concurrency, effectively improve the processing flexibility of business requests, and improve the stability and reliability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the solutions in this application, a brief introduction will be given below to the drawings required for use in the description of the embodiments of this application. Obviously, the drawings described below are some embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0027] Figure 1 is an exemplary system architecture diagram to which the present application may be applied;

[0028] Figure 2 is a flowchart of an embodiment of a method for processing a business request according to the present application;

[0029] Figure 3 is a structural diagram of an embodiment of a service request processing device according to the present application;

[0030] Figure 4 It is a structural diagram of an embodiment of a computer device according to the present application. DETAILED DESCRIPTION

[0031] Unless otherwise defined, all technical and scientific terms used herein have the same meanings as commonly understood by those skilled in the art to which this application belongs. The terms used in the specification of the application are for the purpose of describing specific embodiments only and are not intended to limit this application. The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. The terms "first", "second", etc. in the specification and claims of this application or the above-mentioned drawings are used to distinguish different objects, not to describe a specific order.

[0032] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0033] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0034] like Figure 1 As shown, system architecture 100 may include a terminal device 101, a network 102, and a server 103. Terminal device 101 may be a laptop computer 1011, a tablet computer 1012, or a mobile phone 1013. Network 102 is a medium for providing a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0035] The user can use the terminal device 101 to interact with the server 103 via the network 102 to receive or send messages, etc. Various communication client applications can be installed on the terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0036] The terminal device 101 can be various electronic devices with a display screen and supporting web browsing. In addition to the laptop computer 1011, tablet computer 1012 or mobile phone 1013, the terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 (Moving Picture Experts Group Audio Layer IV) player, a laptop computer and a desktop computer, etc.

[0037] The server 103 may be a server that provides various services, such as a background server that provides support for web pages displayed on the terminal device 101 .

[0038] It should be noted that the service request processing method provided in the embodiment of the present application is generally executed by a server / terminal device, and accordingly, the service request processing device is generally set in the server / terminal device.

[0039] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks and servers may be provided as required.

[0040] Continue to refer Figure 2 , shows a flowchart of an embodiment of the business request processing method according to the present application. According to different needs, the order of the steps in the flowchart can be changed, and some steps can be omitted. The business request processing method provided in the embodiment of the present application can be applied to any scenario where business request processing is required, and the business request processing method can be applied to products in these scenarios, for example, business request processing scenarios in the financial technology field and the medical field. The business request processing method includes the following steps:

[0041] Step S201: receiving a service request input by a user.

[0042] In this embodiment, the service request processing method is executed on the electronic device (eg Figure 1The server / terminal device shown in the figure) can obtain the service request input by the user through a wired connection or a wireless connection. It should be pointed out that the above-mentioned wireless connection methods may include but are not limited to 3G / 4G / 5G connection, WiFi connection, Bluetooth connection, WiMAX connection, Zigbee connection, UWB (ultra wideband) connection, and other wireless connection methods currently known or to be developed in the future. The executive subject of this application is specifically a service request processing system, which can be referred to as the system for short. The user initiates a service request to be processed through a front-end application (such as an insurance company's mobile APP, web page, etc.), and the service request is transmitted through the network to the interface responsible for processing the service request in the service request processing system. The interface is usually composed of a series of network service components, such as a load balancer, which will distribute the service requests to be processed to the appropriate server nodes according to certain strategies (such as polling, minimum number of connections, etc.) to ensure that the service requests can be reasonably allocated processing resources.

[0043] Among them, this application can be applied to business request processing scenarios in the financial technology field and the medical field. For example, in the insurance business processing scenario in the financial technology field, the user demand background corresponding to the above business processing request includes: users hope to learn about insurance product information, conduct insurance insurance or claims and other operations through the online platform to meet their own risk protection needs. Correspondingly, the business processing request can be an insurance product query and recommendation request, an insurance insurance processing request, an insurance claim application and review request, an insurance service consultation and complaint handling request, and so on.

[0044] In healthcare business processing scenarios within the medical field, the user needs for these business processing requests include: users wanting to obtain health status assessments and personalized health recommendations through online platforms to better manage their health. Corresponding business processing requests can include requests for health data upload and integration, health risk assessments, personalized health recommendations, and health record management.

[0045] In the healthcare field, for example, the user needs for these business processing requests include: seniors or their families seeking to access information about home-based elderly care services through online platforms and arrange for appropriate services to improve their quality of life. These business processing requests can include submitting service requests, matching service resources, generating and confirming service orders, and monitoring and providing feedback on service progress.

[0046] Step S202: calling a target interface corresponding to the service request, and obtaining a target timeout period corresponding to the target interface.

[0047] In this embodiment, the target interface may be a dedicated interface responsible for processing the business request. For example, if the business request is a claim settlement request, the corresponding target interface may be the claim settlement interface. For another example, if the business request is a health risk assessment request, the corresponding target interface may be the health risk assessment interface.

[0048] Among them, the system maintains an interface configuration information table at the interface layer, which records the timeout configuration information of each interface. When a service request reaches the interface layer, the system will search the interface configuration information table for the corresponding timeout configuration information based on the interface identifier of the service request (such as interface name, path, etc.), and use it as the timeout period corresponding to the interface. If the timeout configuration information is found, it means that the interface has a timeout configuration; if not found, it is assumed that the interface has no timeout limit. For example, the system searches the configuration information table for the interface name "userProfile" and finds that the interface is configured with @timeOut(3,SECONDS), which means the timeout period is 3 seconds.

[0049] Step S203: Based on the preset timed scheduling task, the target current limiting rule corresponding to the target interface is obtained from the pre-built cache database.

[0050] In this embodiment, the above-mentioned specific implementation process of obtaining the target current limiting rules corresponding to the target interface from the pre-built cache database based on the preset timed scheduling task will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0051] Step S204: Perform a flow limiting check on the service request based on the target flow limiting rule.

[0052] In this embodiment, the specific implementation process of the current limiting verification of the service request based on the target current limiting rule will be further described in detail in subsequent specific embodiments of this application and will not be elaborated on here.

[0053] Step S205: If the service request passes the current limiting check, the service request is processed based on a preset processing strategy, and a timeout check is performed on the service request based on the target timeout period.

[0054] In this embodiment, when a service request is processed, the system immediately initiates two parallel workflows. First, the request is assigned to the corresponding service processing module, which begins executing the actual service logic, such as querying the database and invoking external services. Second, the system starts a timer to record the service request processing time and performs a timeout check based on the processing time. These two workflows run simultaneously, with the timer continuously ticking while the service processing module processes the request. Parallel processing fully utilizes system resources and avoids the additional delays caused by performing a timeout test first. If a timeout test is performed before processing the service request, the response time of the service request will increase, reducing the overall efficiency of the system. Through parallel processing, the system can monitor the processing time of service requests in real time. Once a timeout is detected, immediate action can be taken to avoid long user waits. This processing approach allows the system to flexibly adjust timeouts and service processing flows based on different service requirements and system load, thereby improving the system's adaptability and stability.

[0055] In addition, while the business processing module is processing a business request, the system will continuously check whether the processing time recorded by the timer exceeds the pre-configured timeout period. If the processing time recorded by the timer exceeds the timeout threshold before the business processing is completed, the business request is deemed to have failed the timeout check. The system will immediately interrupt the current processing flow of the business processing module, construct a timeout prompt message and return it to the user, and may also record a timeout log. If the business processing module completes the processing before the timeout period expires, the business request is deemed to have passed the timeout check. The system will encapsulate the processing result and return it to the user, while stopping the timer.

[0056] In addition, the specific implementation process of processing the service request based on the preset processing strategy will be further described in detail in subsequent specific embodiments of this application and will not be elaborated on here.

[0057] Step S206: If the service request passes the timeout check, then the response data generated after processing the service request is obtained.

[0058] In this embodiment, the service request is processed based on the use of the processing policy, and after the service request is processed, corresponding response data is generated.

[0059] Step S207: Return the response data to the user based on the target interface.

[0060] In this embodiment, the generated response data can be returned to the user through the use of the target interface to complete the response processing for the service request triggered by the user. The system can also record the processing log of the above service request, including the processing time of the service request, the business operations involved, etc., for subsequent audit and performance analysis.

[0061] This application first receives a business request input by a user; then calls the target interface corresponding to the business request and obtains the target timeout period corresponding to the target interface; then, based on a preset timed scheduling task, obtains the target flow limiting rule corresponding to the target interface from a pre-built cache database; subsequently, the target flow limiting rule performs flow limiting verification on the business request; if the business request passes the flow limiting verification, the business request is processed based on a preset processing strategy, and a timeout verification is performed on the business request based on the target timeout period; if the business request passes the timeout verification, the response data generated after processing the business request is obtained; finally, the target interface returns the response data to the user. Based on the above processing flow, after receiving the business request input by the user, this application will obtain the target flow limiting rules that match the target interface corresponding to the business request from the pre-built cache database based on the use of timed scheduling tasks. After detecting that the business request passes the flow limiting check based on the use of the target flow limiting rules, it will process the business request based on the use of the processing strategy, and perform a timeout check on the business request based on the target timeout time of the target interface. Subsequently, after detecting that the business request passes the timeout check, the response data generated after processing the business request is obtained, and then the response data is returned to the user based on the use of the target interface. In this way, this application processes the business request based on the combination of flow limiting check processing and timeout check processing, which can effectively avoid the system crash due to too many business requests, ensure that the system can still operate normally under high concurrency, effectively improve the processing flexibility of business requests, and improve the stability and reliability of the system.

[0062] In some optional implementations, step S203 includes the following steps:

[0063] Get the interface identifier of the target interface.

[0064] In this embodiment, the target interface can be queried for its identifier to obtain the corresponding interface identifier, wherein the interface identifier may include the interface name, URL path, etc.

[0065] Calls a pre-built cache database.

[0066] In this embodiment, the system maintains a rate limiting rules table in persistent storage (i.e., a cache database, specifically Redis). This rate limiting rules table details the rate limiting configuration for each interface. Rate limiting rules include, but are not limited to, parameters such as interface identifier, time period (e.g., peak period, off-peak period), user group classification (e.g., VIP users, ordinary users), business scenario, maximum number of concurrent requests, and request quota per unit time (e.g., number of requests per second).

[0067] Based on the timed scheduling task, the specified current limiting rule corresponding to the interface identifier is queried from the cache database at a specified time interval.

[0068] In this embodiment, the system pre-sets an independent timer scheduling task to pull the latest current limiting rules from the above-mentioned cache database at preset time intervals (such as every 10 seconds). Among them, the timer scheduling task ensures that the current limiting rules can be dynamically updated to adapt to changes in business needs or adjustments to system resources. In addition, when a business request arrives at the interface layer, the system searches for the corresponding current limiting rules in the current limiting rule table in the above-mentioned cache database based on the interface identifier (such as interface name, URL path) of the target interface corresponding to the business request. In addition, the system may also further match more fine-grained current limiting rules (such as special quotas for VIP users) based on the user identifier or business scenario identifier in the request.

[0069] The specified current limiting rule is used as the target current limiting rule corresponding to the target interface.

[0070] This application obtains the interface identifier of the target interface; then calls the pre-built cache database; then based on the timed scheduling task, queries the specified current limiting rule corresponding to the interface identifier from the cache database at a specified time interval; and subsequently uses the specified current limiting rule as the target current limiting rule corresponding to the target interface. Based on the above processing flow, this application queries the target current limiting rule corresponding to the interface identifier from the cache database at a specified time interval based on the use of the timed scheduling task, thereby achieving efficient and accurate pulling of current limiting rules from the cache database, allowing the system to update the current limiting strategy in a timely manner to adapt to different business scenarios and traffic changes, effectively ensuring the accuracy of the acquired target current limiting rules.

[0071] In some optional implementations of this embodiment, step S204 includes the following steps:

[0072] A target request counter corresponding to the target interface is called.

[0073] In this embodiment, the system maintains a request counter for each interface in advance, and the request counter is used to record the number of requests processed in the current time window.

[0074] The cumulative number of requests processed by the target interface within a specified time window is obtained based on the target request counter.

[0075] In this embodiment, the target request counter can be used to record the number of requests processed by the target interface in the current time window as the corresponding cumulative number of requests processed. For each business request, the system will initiate a query operation to the cache database (Redis service) to obtain the cumulative number of requests for the interface in the current time window. As a high-performance memory database, Redis can quickly respond to query requests and return the current number of requests. By making a request to Redis to determine whether the business request exceeds the limit, the high performance characteristics of Redis are utilized to quickly and accurately obtain the request quantity information, avoid the system crashing due to too many requests, and ensure that the system can still operate normally under high concurrency.

[0076] Get the quantity threshold in the target current limiting rule.

[0077] In this embodiment, a threshold query can be performed on the target current limiting rule to obtain a corresponding quantity threshold.

[0078] Determine whether the cumulative number of request processing is less than the number threshold.

[0079] In this embodiment, the system compares the acquired cumulative number of request processing with the number threshold specified in the above target current limiting rule to determine whether the cumulative number of request processing is less than the number threshold.

[0080] If the cumulative number of request processing is less than the number threshold, it is determined that the service request passes the current limiting check; otherwise, it is determined that the service request fails the current limiting check.

[0081] In this embodiment, if the cumulative number of processed requests does not exceed the threshold, the service request is allowed to continue processing and the request counter is updated. If the cumulative number of processed requests exceeds the threshold, the current limiting logic is triggered, and the request is rejected according to the preset policy (such as returning a "too frequent requests" prompt) or placed in a waiting queue (such as using a message queue for buffering).

[0082] In addition, the system records throttling trigger logs, including the throttled interface, request source, and trigger time, for subsequent auditing and performance analysis. Furthermore, the system displays the request volume and throttling status of each interface in real time through a monitoring dashboard, helping operations personnel quickly understand system load.

[0083] This application calls the target request counter corresponding to the target interface; then obtains the cumulative number of request processing of the target interface within the specified time window based on the target request counter; then obtains the number threshold in the target current limiting rule; subsequently determines whether the cumulative number of request processing is less than the number threshold; if the cumulative number of request processing is less than the number threshold, then it is determined that the business request has passed the current limiting check, otherwise it is determined that the business request has not passed the current limiting check. Based on the above processing flow, this application obtains the cumulative number of request processing of the target interface within the specified time window based on the use of the target request counter, and then compares the cumulative number of request processing with the number threshold specified in the target current limiting rule, so that the current limiting check result of the business request can be efficiently and accurately generated according to the obtained numerical comparison result, which effectively improves the processing efficiency of the current limiting check of the business request and ensures the data accuracy of the obtained current limiting check result.

[0084] In some optional implementations, the processing of the service request based on a preset processing strategy in step S205 includes the following steps:

[0085] The service request is parsed to obtain request parameters in the service request.

[0086] In this embodiment, the parameter parsing process for the service request may involve parsing information such as the request body, query string, and request header to extract specific data required for service processing, namely the request parameters mentioned above.

[0087] The request parameters are verified based on a preset verification strategy.

[0088] In this embodiment, the verification policy includes verifying the request parameters, including checking the parameter format, type, and required fields, to ensure the integrity and legitimacy of the request data. The request parameters can be verified based on the verification policy to obtain corresponding parameter verification results. The parameter verification results may include whether the request parameters passed verification or failed verification.

[0089] If the request parameters pass the verification, query processing is performed on the request parameters based on the preset service to obtain corresponding query data.

[0090] In this embodiment, based on the business requirements corresponding to the request parameters, the database can be accessed to query relevant data and obtain the corresponding query data, such as user information, policy details, historical transaction records, medical data, etc. Alternatively, it may be necessary to call other internal or external services, such as credit inquiry services, payment services, third-party data services, etc., to obtain additional information required to process the request.

[0091] The query data is integrated to obtain corresponding integrated data.

[0092] In this embodiment, data obtained from a database or external service can be integrated, calculated, or analyzed to generate corresponding integrated data. For example, a user profile interface may integrate multi-dimensional data such as a user's historical insurance records, browsing behavior, and preference settings to generate a comprehensive user profile through an algorithm or rule engine.

[0093] The integrated data is encapsulated to obtain response data corresponding to the service request.

[0094] In this embodiment, the generated integrated data can be encapsulated according to the interface specification, typically converted into a standard format such as JSON or XML, thereby obtaining response data corresponding to the above-mentioned service request. The encapsulation process includes setting the response status code, response header, response body, etc. to ensure that the response data conforms to the interface definition and client expectations.

[0095] This application parses the business request to obtain the request parameters in the business request; then verifies the request parameters based on a preset verification strategy; if the request parameters pass the verification, the request parameters are queried based on the preset service to obtain the corresponding query data; then the query data is integrated to obtain the corresponding integrated data; and subsequently the integrated data is packaged to obtain the response data corresponding to the business request. Based on the above processing flow, this application can efficiently process the user's business request by performing parameter parsing, parameter verification, integration processing, and packaging processing on the business request, and provide the user with the required services or data accurately and promptly, thereby improving the processing efficiency of the business request and improving the user's experience.

[0096] In some optional implementations, after step S205, the electronic device may further perform the following steps:

[0097] If the service request fails the timeout check, the service request is interrupted.

[0098] In this embodiment, when it is detected that the service request fails the timeout check, that is, when the request processing time of the service request exceeds the target timeout time pre-configured corresponding to the target interface, the system will interrupt the processing of the service request.

[0099] Constructing timeout prompt information corresponding to the service request, and recording a timeout log corresponding to the service request.

[0100] In this embodiment, after the processing of the above service request is interrupted, the system will construct a timeout prompt message matching the service request, such as "Request processing timed out, please try again later."

[0101] The timeout prompt information is sent to the user.

[0102] In this embodiment, the system will return the generated timeout prompt information to the user, so that the user can understand the request status in time and avoid the user waiting for a long time.

[0103] The timeout log is sent to a preset operation and maintenance personnel.

[0104] In this embodiment, at the same time, the system will record the timeout log corresponding to the above service request to facilitate subsequent analysis and troubleshooting.

[0105] If the present application detects that the business request has not passed the timeout check, the business request is interrupted; then a timeout prompt message corresponding to the business request is constructed, and a timeout log corresponding to the business request is recorded; thereafter, the timeout prompt message is sent to the user; and the timeout log is sent to the preset operation and maintenance personnel. Based on the above processing flow, the present application can effectively avoid business requests occupying system resources for a long time, resulting in a decline in system performance, by performing timeout processing on business requests. When the processing time of a business request is too long, the user interrupts the request in time and returns a timeout prompt message, which allows the user to understand the request status in time and avoids the user waiting for a long time. At the same time, recording timeout logs helps developers analyze system performance bottlenecks, optimize system performance, and improve the response speed and stability of the system.

[0106] In some optional implementations of this embodiment, after step S203, the electronic device may further perform the following steps:

[0107] Based on a preset health check strategy, the service status of the cache database is detected. In this embodiment, the system has a built-in health check strategy that periodically (e.g., every second or every few seconds) sends a probe request (e.g., a PING command) to the cache database (Redis service) to detect the connection status and response of the cache database. When the health check mechanism fails to receive a normal response from the cache database for multiple consecutive times (e.g., three consecutive times), the system determines that the cache database is unavailable and triggers the service degradation processing mechanism.

[0108] If the service status is unavailable, a preset service degradation process is performed.

[0109] In this embodiment, after the service degradation processing mechanism is triggered, the system will immediately switch to a pre-configured hard-coded current limiting strategy. This strategy will limit the number of requests processed for non-core businesses (such as certain report generation, non-real-time data analysis, etc.), or even completely reject these requests, to ensure that core businesses (such as user profile interfaces, underwriting interfaces, etc.) can obtain sufficient system resources to continue running. Among them, the system will record the corresponding degradation log, including the specific time when the degradation occurred, the conditions that triggered the degradation, the affected business interfaces, and other information for subsequent analysis and auditing.

[0110] Generate alarm notification information corresponding to the cache database.

[0111] In this embodiment, the alarm notification information may include detailed information about the cache database failure.

[0112] The alarm notification information is sent to the preset operation and maintenance personnel.

[0113] In this embodiment, the system will send an alarm notification message to the operation and maintenance personnel through a preset notification channel (such as email, SMS, instant messaging tools, etc.), informing them of the detailed information of the cache database (Redis service) failure so that the operation and maintenance personnel can intervene and handle it in time. Among them, after receiving the alarm, the operation and maintenance personnel will start the recovery process of the Redis service, which may include checking the operating status of the Redis server, expanding the capacity of Redis resources, repairing network connection problems, etc. When the Redis service resumes operation, the system will again detect the connection status of Redis through the health check strategy. Once it is confirmed that the Redis service has returned to normal, the system will automatically reconnect to Redis and gradually restore the previously downgraded non-core business processing capabilities, so that the system can fully return to normal operation.

[0114] This application detects the service status of the cache database based on a preset health check strategy; if the service status is unavailable, the preset service degradation process is executed; then an alarm notification message corresponding to the cache database is generated; and the alarm notification message is subsequently sent to the preset operation and maintenance personnel. Based on the above processing flow, when the service status of the cache database is detected to be unavailable based on the use of a health check strategy, that is, when an abnormality occurs in the cache database, the application can automatically and intelligently execute service degradation processing, so that the system can avoid cascading avalanches caused by a single component failure and ensure the normal operation of the core business. In addition, by sending the alarm notification message corresponding to the cache database to the operation and maintenance personnel, it helps the operation and maintenance personnel to understand the system failure situation in a timely manner, take corresponding measures to repair it, and restore the normal operation of the system as soon as possible, which is conducive to ensuring the stable operation of the system.

[0115] In some optional implementations of this embodiment, after step S207, the electronic device may further perform the following steps:

[0116] Obtain request processing indicator data of the target interface based on a preset monitoring tool.

[0117] In this embodiment, the system has a built-in monitoring tool that continuously tracks the request processing status of each interface, including key indicators such as the number of request limit violations, processing success rate, and average response time. The monitoring tool also monitors the operating status of components associated with the interface (such as the credit inquiry component and the payment service component), including their response time and error rate.

[0118] Based on the request processing indicator data, it is determined whether the target interface is in an unstable state.

[0119] In this embodiment, when the monitoring module detects that the number of requests exceeding the limit of a certain interface exceeds the preset threshold within a continuous period of time (such as the last 5 minutes), or the associated component is degraded (such as a significant increase in response time or a sharp increase in error rate), the system will determine that the interface or associated component is in an unstable state and actively trigger the fuse mechanism.

[0120] If yes, get the preset circuit breaker policy.

[0121] In this embodiment, the above-mentioned fuse strategy is a processing strategy corresponding to the above-mentioned fuse mechanism. The policy content of the processing strategy includes: after the fuse mechanism is triggered, the system will immediately take protective measures, such as reducing the flow limit of the interface to 0, that is, completely rejecting new requests; or rejecting traffic from a specific requester based on the requester's identification (such as user ID, IP address, etc.) to prevent the system from crashing due to overload.

[0122] Perform a fuse process on the target interface based on the fuse policy.

[0123] In this embodiment, the target interface may be automatically blown based on the policy content of the blow policy.

[0124] In addition, the system will send alarm information to operation and maintenance personnel and relevant business personnel via email, SMS or other notification methods, detailing the interface, related components, triggering reasons and current system status that triggered the circuit breaker. After receiving the alarm, the operation and maintenance personnel will start the problem investigation and repair process, which may include checking the interface logic, optimizing the performance of related components, increasing system resources, etc. Moreover, when the problem is resolved and the operating status of the interface or related components returns to normal, the operation and maintenance personnel can gradually restore the normal traffic processing capacity of the interface through manual operation (such as clicking the restore button on the management interface) or automatic system detection (such as normal monitoring indicators for a period of time) to enable the system to provide services to users again. In addition, the system will record detailed logs of circuit breaking and recovery, including information such as circuit breaking trigger time, recovery time, operator, etc., for subsequent auditing and performance analysis.

[0125] This application obtains the request processing index data of the target interface based on a preset monitoring tool; then, based on the request processing index data, determines whether the target interface is in an unstable state; if so, obtains a preset fuse policy; and subsequently performs fuse processing on the target interface based on the fuse policy. Based on the above processing flow, this application automatically and intelligently performs fuse processing on the target interface based on the use of the fuse policy after analyzing the request processing index data based on the monitoring tool and determining that the target interface is in an unstable state. Through active fusing, the system can avoid continuing to process a large number of requests in extreme cases, causing the system to crash, effectively improving the intelligence of request processing and ensuring the stability of system operation.

[0126] In some optional implementations, the user information obtained is obtained with the user's consent and complies with relevant laws and policies.

[0127] In addition, any software tools or components not provided by our company that appear in the embodiments of this application are merely examples and do not represent actual use.

[0128] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0129] It should be emphasized that in order to further ensure the privacy and security of the above response data, the above response data can also be stored in a blockchain node.

[0130] The blockchain referred to in this application is a new application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Blockchain is essentially a decentralized database, a series of data blocks generated using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of this information (to prevent counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, the platform product service layer, and the application service layer.

[0131] The embodiments of the present application can acquire and process relevant data based on artificial intelligence technology. Artificial Intelligence (AI) is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use knowledge to achieve optimal results.

[0132] Fundamental AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interaction systems, and mechatronics. AI software technologies primarily encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0133] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware via computer-readable instructions. The computer-readable instructions can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes in the above-described method embodiments. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0134] It should be understood that although the steps in the flowcharts of the accompanying drawings are shown in sequence as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified 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 of the steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0135] Further references Figure 3, as a response to the above Figure 2 The present application provides an embodiment of a service request processing device, which is similar to Figure 2 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0136] like Figure 3 As shown, the service request processing device 300 of this embodiment includes: a receiving module 301, a first processing module 302, a first obtaining module 303, a verification module 304, a second processing module 305, a second obtaining module 306 and a returning module 307.

[0137] Receiving module 301, used to receive a service request input by a user;

[0138] A first processing module 302 is configured to call a target interface corresponding to the service request and obtain a target timeout period corresponding to the target interface;

[0139] A first acquisition module 303 is configured to acquire a target current limiting rule corresponding to the target interface from a pre-built cache database based on a preset timed scheduling task;

[0140] A verification module 304 is configured to perform a flow limiting verification on the service request based on the target flow limiting rule;

[0141] The second processing module 305 is configured to process the service request based on a preset processing strategy if the service request passes the current limiting check, and perform a timeout check on the service request based on the target timeout period;

[0142] The second acquisition module 306 is configured to acquire response data generated after processing the service request if the service request passes the timeout check;

[0143] The returning module 307 is configured to return the response data to the user based on the target interface.

[0144] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the service request processing method in the aforementioned embodiment, and are not described in detail here.

[0145] In some optional implementations of this embodiment, the first obtaining module 303 includes:

[0146] A first acquisition submodule, configured to acquire an interface identifier of the target interface;

[0147] The first calling submodule is used to call the pre-built cache database;

[0148] A query submodule, configured to query the cache database for a specified current limiting rule corresponding to the interface identifier at a specified time interval based on the timed scheduling task;

[0149] The determination submodule is configured to use the specified current limiting rule as a target current limiting rule corresponding to the target interface.

[0150] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the service request processing method in the aforementioned embodiment, and are not described in detail here.

[0151] In some optional implementations of this embodiment, the verification module 304 includes:

[0152] A second calling submodule, configured to call a target request counter corresponding to the target interface;

[0153] A second acquisition submodule is configured to acquire, based on the target request counter, a cumulative number of requests processed by the target interface within a specified time window;

[0154] A third acquisition submodule is used to obtain the quantity threshold in the target current limiting rule;

[0155] A judging submodule, configured to judge whether the cumulative number of request processing is less than the number threshold;

[0156] The determination submodule is configured to determine that the service request has passed the current limiting check if the cumulative number of request processing is less than the number threshold, and otherwise determine that the service request has failed the current limiting check.

[0157] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the service request processing method in the aforementioned embodiment, and are not described in detail here.

[0158] In some optional implementations of this embodiment, the second processing module 305 includes:

[0159] The parsing submodule is used to parse the service request to obtain the request parameters in the service request;

[0160] A verification submodule, configured to verify the request parameters based on a preset verification strategy;

[0161] A processing submodule, configured to query the request parameters based on a preset service to obtain corresponding query data if the request parameters pass verification;

[0162] An integration submodule, configured to integrate the query data to obtain corresponding integrated data;

[0163] The encapsulation submodule is used to encapsulate the integrated data to obtain response data corresponding to the business request.

[0164] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the service request processing method in the aforementioned embodiment, and are not described in detail here.

[0165] In some optional implementations of this embodiment, the service request processing apparatus further includes:

[0166] An interruption module, configured to interrupt the service request if the service request fails the timeout check;

[0167] A third processing module is used to construct timeout prompt information corresponding to the service request and record a timeout log corresponding to the service request;

[0168] A first sending module, configured to send the timeout prompt information to the user;

[0169] The second sending module is used to send the timeout log to a preset operation and maintenance personnel.

[0170] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the service request processing method in the aforementioned embodiment, and are not described in detail here.

[0171] In some optional implementations of this embodiment, the service request processing apparatus further includes:

[0172] A detection module, configured to detect the service status of the cache database based on a preset health check strategy;

[0173] an execution module, configured to execute a preset service degradation process if the service status is unavailable;

[0174] A generating module, configured to generate alarm notification information corresponding to the cache database;

[0175] The third sending module is used to send the alarm notification information to the preset operation and maintenance personnel.

[0176] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the service request processing method in the aforementioned embodiment, and are not described in detail here.

[0177] In some optional implementations of this embodiment, the service request processing apparatus further includes:

[0178] A third acquisition module is used to obtain the request processing indicator data of the target interface based on a preset monitoring tool;

[0179] A judgment module, configured to judge whether the target interface is in an unstable state based on the request processing indicator data;

[0180] A fourth acquisition module is used to obtain a preset circuit breaker strategy if yes;

[0181] A fourth processing module is configured to perform a fuse process on the target interface based on the fuse policy.

[0182] In this embodiment, the operations performed by the above modules or units correspond one-to-one to the steps of the service request processing method in the aforementioned embodiment, and are not described in detail here.

[0183] To solve the above technical problems, the present application also provides a computer device. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0184] The computer device 4 includes a memory 41, a processor 42, and a network interface 43 that are interconnected through a system bus. It should be noted that the figure only shows a computer device 4 with components 41-43, but it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented instead. Among them, those skilled in the art can understand that the computer device here is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to microprocessors, application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0185] The computer device may be a desktop computer, notebook computer, PDA, cloud server, etc. The computer device may interact with the user via a keyboard, mouse, remote control, touchpad, or voice control device.

[0186] The memory 41 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 41 can be an internal storage unit of the computer device 4, such as the hard disk or memory of the computer device 4. In other embodiments, the memory 41 can also be an external storage device of the computer device 4, such as a plug-in hard disk equipped on the computer device 4, a smart media card (SMC), a secure digital (SD) card, a flash memory card, etc. Of course, the memory 41 can also include both the internal storage unit of the computer device 4 and its external storage device. In this embodiment, the memory 41 is generally used to store the operating system and various application software installed on the computer device 4, such as computer-readable instructions of the service request processing method. In addition, the memory 41 can also be used to temporarily store various types of data that have been output or are to be output.

[0187] In some embodiments, the processor 42 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 42 is generally used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is used to execute computer-readable instructions stored in the memory 41 or process data, such as computer-readable instructions for executing the service request processing method.

[0188] The network interface 43 may include a wireless network interface or a wired network interface. The network interface 43 is generally used to establish a communication connection between the computer device 4 and other electronic devices.

[0189] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0190] In an embodiment of the present application, after receiving a business request input by a user, the present application will obtain a target flow limiting rule that matches the target interface corresponding to the business request from a pre-built cache database based on the use of a timed scheduling task, and after detecting that the business request passes the flow limiting check based on the use of the target flow limiting rule, the present application will process the business request based on the use of the processing strategy, and perform a timeout check on the business request based on the target timeout time of the target interface. Subsequently, after detecting that the business request passes the timeout check, the present application will obtain the response data generated after processing the business request, and then return the response data to the user based on the use of the target interface. In this way, the present application processes the business request based on the combination of flow limiting check processing and timeout check processing, which can effectively avoid the system crash due to too many business requests, ensure that the system can still operate normally under high concurrency, effectively improve the processing flexibility of business requests, and improve the stability and reliability of the system.

[0191] The present application also provides another embodiment, namely, providing a computer-readable storage medium, which stores computer-readable instructions. The computer-readable instructions can be executed by at least one processor to enable the at least one processor to perform the steps of the business request processing method as described above.

[0192] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0193] In an embodiment of the present application, after receiving a business request input by a user, the present application will obtain a target flow limiting rule that matches the target interface corresponding to the business request from a pre-built cache database based on the use of a timed scheduling task, and after detecting that the business request passes the flow limiting check based on the use of the target flow limiting rule, the present application will process the business request based on the use of the processing strategy, and perform a timeout check on the business request based on the target timeout time of the target interface. Subsequently, after detecting that the business request passes the timeout check, the present application will obtain the response data generated after processing the business request, and then return the response data to the user based on the use of the target interface. In this way, the present application processes the business request based on the combination of flow limiting check processing and timeout check processing, which can effectively avoid the system crash due to too many business requests, ensure that the system can still operate normally under high concurrency, effectively improve the processing flexibility of business requests, and improve the stability and reliability of the system.

[0194] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0195] Obviously, the embodiments described above are only some of the embodiments of the present application, rather than all of the embodiments. The preferred embodiments of the present application are given in the accompanying drawings, but they do not limit the patent scope of the present application. The present application can be implemented in many different forms. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present application more thorough and comprehensive. Although the present application has been described in detail with reference to the aforementioned embodiments, for those skilled in the art, it is still possible to modify the technical solutions described in the aforementioned specific embodiments, or to make equivalent replacements for some of the technical features therein. Any equivalent structure made using the contents of the present application specification and the accompanying drawings, directly or indirectly used in other related technical fields, is also within the scope of patent protection of the present application.

Claims

1. A method for processing a business request, characterized in that: The steps include: Receive business requests input by users; Calling a target interface corresponding to the service request and obtaining a target timeout period corresponding to the target interface; Based on a preset timed scheduling task, a target current limiting rule corresponding to the target interface is obtained from a pre-built cache database; Performing a current limiting check on the service request based on the target current limiting rule; If the service request passes the current limiting check, the service request is processed based on a preset processing strategy, and a timeout check is performed on the service request based on the target timeout period; If the service request passes the timeout check, obtaining response data generated after processing the service request; Based on the target interface, the response data is returned to the user.

2. The service request processing method according to claim 1, characterized in that: The step of obtaining the target current limiting rule corresponding to the target interface from the pre-built cache database based on the preset timed scheduling task specifically includes: Obtaining the interface identifier of the target interface; Call the pre-built cache database; Based on the timed scheduling task, querying the specified current limiting rule corresponding to the interface identifier from the cache database at a specified time interval; The specified current limiting rule is used as the target current limiting rule corresponding to the target interface.

3. The service request processing method according to claim 1, wherein: The step of performing current limiting verification on the service request based on the target current limiting rule specifically includes: calling a target request counter corresponding to the target interface; Obtaining, based on the target request counter, a cumulative number of requests processed by the target interface within a specified time window; Obtain the quantity threshold in the target flow limiting rule; Determining whether the cumulative number of request processing is less than the number threshold; If the cumulative number of request processing is less than the number threshold, it is determined that the service request passes the current limiting check; otherwise, it is determined that the service request fails the current limiting check.

4. The service request processing method according to claim 1, wherein: The step of processing the service request based on the preset processing strategy specifically includes: Parsing the service request to obtain request parameters in the service request; Verify the request parameters based on a preset verification strategy; If the request parameters pass the verification, query the request parameters based on the preset service to obtain corresponding query data; Performing integration processing on the query data to obtain corresponding integrated data; The integrated data is encapsulated to obtain response data corresponding to the service request.

5. The service request processing method according to claim 1, wherein: After the steps of processing the service request based on the preset processing strategy and performing a timeout check on the service request based on the target timeout period, the method further includes: If the service request fails the timeout check, interrupting the service request; Constructing timeout prompt information corresponding to the service request, and recording a timeout log corresponding to the service request; Sending the timeout prompt information to the user; The timeout log is sent to a preset operation and maintenance personnel.

6. The service request processing method according to claim 1, wherein: After the step of acquiring the target current limiting rule corresponding to the target interface from the pre-built cache database based on the preset timed scheduling task, the method further includes: Based on a preset health check strategy, detect the service status of the cache database; If the service status is unavailable, performing a preset service degradation process; Generating alarm notification information corresponding to the cache database; The alarm notification information is sent to the preset operation and maintenance personnel.

7. The service request processing method according to claim 1, characterized in that: After the step of returning the response data to the user based on the target interface, the method further includes: Obtaining request processing indicator data of the target interface based on a preset monitoring tool; Based on the request processing indicator data, determining whether the target interface is in an unstable state; If yes, get the preset circuit breaker strategy; Perform a fuse process on the target interface based on the fuse policy.

8. A service request processing device, characterized in that: include: A receiving module, used to receive a service request input by a user; A first processing module is configured to call a target interface corresponding to the service request and obtain a target timeout period corresponding to the target interface; A first acquisition module is used to acquire a target current limiting rule corresponding to the target interface from a pre-built cache database based on a preset timed scheduling task; A verification module, configured to perform a flow limiting verification on the service request based on the target flow limiting rule; A second processing module is configured to process the service request based on a preset processing strategy if the service request passes the current limiting check, and perform a timeout check on the service request based on the target timeout period; A second acquisition module is used to obtain response data generated after processing the business request if the business request passes the timeout check; A returning module is used to return the response data to the user based on the target interface.

9. A computer device, characterized in that: The method comprises a memory and a processor, wherein the memory stores computer-readable instructions, and the processor implements the steps of the service request processing method according to any one of claims 1 to 7 when executing the computer-readable instructions.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the service request processing method according to any one of claims 1 to 7.

Images