Request management method and device, computer equipment, storage medium and program product

Abstract

The invention relates to a request management method and device, computer equipment, a storage medium and a program product. The method comprises the following steps: an API gateway determines an index value of a target API request in response to the target API request; searching whether corresponding effective cache data exists or not according to the index value; if yes, feeding back the effective cache data to a sender of the target API request; and if not, obtaining corresponding effective cache data through the background server, and feeding back the obtained effective cache data to a sender of the target API request. By adopting the method, the API request can be managed through the API gateway, and whether the effective cache data exists or not is judged based on the index value, so that different data acquisition modes are adopted under different conditions, and the secure execution of the API request is ensured as far as possible while the back-end service pressure caused by the high-concurrency API request is relieved.

Description

Technical Field

[0001] The present application relates to the field of computer network technology, and in particular to a request management method, apparatus, computer equipment, storage medium and program product. Background Art

[0002] With the rapid development of information technology, driven by cloud computing, big data and mobile Internet, API (Application Programming Interface) has become a key technology for connecting different software applications and services. As a bridge for communication between services, the performance and stability of API directly affect the user experience and business continuity of the entire system.

[0003] As a core component in the microservice architecture, the API gateway undertakes important responsibilities such as request routing and load balancing. However, the current API gateway still faces the dual challenges of efficiency and stability when processing large-scale, high-concurrency API requests. For example, a simple request forwarding mechanism cannot effectively reduce the pressure on backend services, and although the circuit breaker mechanism can prevent system overload, it may cause user request failures and affect service availability. Summary of the invention

[0004] Based on this, it is necessary to provide a request management method, device, computer equipment, storage medium and program product that can manage API requests through an API gateway to address the above technical problems, thereby reducing the back-end service pressure caused by high-concurrency API requests while ensuring the safe execution of API requests as much as possible.

[0005] In a first aspect, the present application provides a request management method, which is applied to an API gateway, including:

[0006] In response to the target API request, determining an index value of the target API request;

[0007] According to the index value, check whether there is corresponding valid cache data;

[0008] If so, the valid cache data is fed back to the sender of the target API request;

[0009] If not, the corresponding valid cache data is obtained through the background server, and the obtained valid cache data is fed back to the sender of the target API request.

[0010] In one embodiment, determining the index value of the target API request includes:

[0011] Obtain characteristic information of the target API request; wherein the characteristic information includes at least one of a method name, a request path, a query parameter, and a request body;

[0012] Use the preset hash function to calculate the index value of the target API request based on the feature information.

[0013] In one embodiment, searching whether corresponding valid cache data exists according to the index value includes:

[0014] According to the index value, searching whether there is corresponding cache data; wherein the cache data includes valid cache data and invalid cache data;

[0015] If so, it is determined whether the cached data is valid cached data according to the storage time of the cached data found.

[0016] In one embodiment, after obtaining the corresponding valid cache data through the background server, the method further includes:

[0017] The acquired valid cache data is associated with the index value and stored in the cache system.

[0018] In one embodiment, after the acquired valid cache data is associated with the index value and stored in the cache system, the method further includes:

[0019] When it is determined that the target API request is a non-query request, determine the target resource associated with the target API request according to the resource tag of the target API request;

[0020] Updates the cached data of the target resource.

[0021] In one embodiment, when the number of failures to obtain corresponding valid cache data through the background server reaches a target value, the method further includes:

[0022] Feedback request failure information to the sender of the target API request.

[0023] In a second aspect, the present application also provides a request management device, which is configured in an API gateway, including:

[0024] An index value determination module, configured to determine an index value of a target API request in response to the target API request;

[0025] A data search module is used to search for corresponding valid cache data according to the index value;

[0026] A first feedback module, configured to feed back the valid cache data to the sender of the target API request if there is corresponding valid cache data;

[0027] The second feedback module is used to obtain the corresponding valid cache data through the background server when there is no corresponding valid cache data, and feed back the obtained valid cache data to the sender of the target API request.

[0028] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the method of the first aspect when executing the computer program.

[0029] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the method of the first aspect when the computer program is executed by a processor.

[0030] In a fifth aspect, the present application further provides a computer program product, comprising a computer program, which implements the steps of the method of the first aspect when executed by a processor.

[0031] In the above-mentioned request management method, apparatus, computer equipment, storage medium and program product, the API gateway responds to the target API request and determines the index value of the target API request; based on the index value, it searches whether there is corresponding valid cache data; if so, the valid cache data is fed back to the sender of the target API request; if not, the corresponding valid cache data is obtained through the background server, and the obtained valid cache data is fed back to the sender of the target API request. This application manages API requests through an API gateway, and determines whether there is valid cache data based on the index value, so as to adopt different data acquisition methods in different situations, so as to reduce the back-end service pressure caused by high-concurrency API requests while ensuring the safe execution of API requests as much as possible. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0033] Figure 1 A diagram of an application environment of a request management method in an embodiment;

[0034] Figure 2 A flowchart of a request management method in one embodiment;

[0035] Figure 3 A schematic diagram of a process for calculating an index value in one embodiment;

[0036] Figure 4 A schematic diagram of a process for updating cache data in one embodiment;

[0037] Figure 5 A flowchart of a request management method in another embodiment;

[0038] Figure 6 is a structural block diagram of a request management device in one embodiment;

[0039] Figure 7 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

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

[0041] The request management method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers. The API gateway can be implemented by the server 104, and in response to the target API request, it determines the index value of the target API request; according to the index value, it searches whether there is corresponding valid cache data; if so, the valid cache data is fed back to the sender of the target API request; if not, the corresponding valid cache data is obtained through the background server, and the obtained valid cache data is fed back to the sender of the target API request.

[0042] The terminal 102 may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, IoT devices, portable wearable devices, etc. The server 104 may be an independent physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services.

[0043] In an exemplary embodiment, Figure 2 As shown, a request management method is provided, which is applied to an API gateway, including:

[0044] S201, in response to a target API request, determining an index value of the target API request.

[0045] Among them, the API gateway can be a server that receives all API requests initiated by clients to the business system and processes the API requests accordingly. In high-traffic application scenarios, these API requests bring high concurrency problems.

[0046] The target API request is the API request currently to be processed, which may include query requests and non-query requests. Query requests refer to API requests used to retrieve data without modifying the data status, such as GET requests, etc. Non-query requests refer to API requests involving operations such as creation, update, or deletion of data, such as POST requests, PUT requests, or DELETE requests.

[0047] For example, the business system is an e-commerce system that can provide APIs such as product query and order management for front-end applications to call, and the target API request can be a product query request or an order management request. With the increase in the number of users, especially during promotional activities, the frequency of query requests has increased rapidly, which has brought great pressure to the database.

[0048] The API gateway responds to the target API request sent by any client and determines the corresponding index value based on the relevant information of the target API request. The index value of each API request is unique and is used to distinguish different API requests for corresponding processing. The index value can be associated with the cache data and stored in the cache subsystem included in the business system. The cache subsystem can be implemented through Redis, which is not limited in this embodiment.

[0049] Optionally, the API gateway intercepts a target API request initiated by the client to the business system, and then determines an index value of the intercepted target API request.

[0050] Optionally, the target API request is parsed to obtain identification information carried in the target API request, and then the corresponding index value is determined according to the identification information.

[0051] Optionally, feature extraction is performed on the target API request to obtain key features of the target API request, and then a corresponding index value is determined based on the key features.

[0052] S202: Search, according to the index value, whether there is corresponding valid cache data.

[0053] If yes, execute S203; if no, execute S204.

[0054] The index value of the target API request is searched in the cache subsystem. If the index value is found, it is determined whether there is cache data stored in association with the index value. If there is cache data stored in association with the index value, it is further determined whether the associated cache data is valid cache data.

[0055] Optionally, first identify the type of the target API request, that is, determine whether the target API request is a query request or a non-query request. Only when the target API request is a query request, find out whether there is corresponding valid cache data according to the index value. The type of the target API request can be distinguished by a mark, such as 00 for a query request and 01 for a non-query request, which is not limited in this embodiment.

[0056] S203: Feedback the valid cache data to the sender of the target API request.

[0057] When valid cache data of the target API request is stored in the cache subsystem, the valid cache data can be sent directly to the client that initiates the target API request, that is, the sender of the target API request, through the API gateway to complete the related business of the target API request.

[0058] S204, obtaining corresponding valid cache data through the background server, and feeding back the obtained valid cache data to the sender of the target API request.

[0059] The background server is a server for providing back-end services, and may be a server for running a business system.

[0060] In the case where valid cache data for the target API request is not stored in the cache subsystem, such as the index value of the target API request is not stored in the cache subsystem, or the cache data associated with the index value of the target API request is not stored in the cache subsystem, or the cache data associated with the index value of the target API request stored in the cache subsystem is invalid cache data, the target API request can be forwarded to the backend server for processing through the API gateway, so that the backend server obtains the corresponding valid cache data based on the target API request, and sends the obtained valid cache data directly to the client that initiates the target API request, that is, the sender of the target API request, to complete the relevant business of the target API request.

[0061] Optionally, after the backend server obtains the corresponding valid cache data based on the target API request, it can also send the valid cache data to the API gateway, and then the API gateway forwards it to the sender of the target API request.

[0062] In the above request management method, the API gateway responds to the target API request and determines the index value of the target API request; based on the index value, it searches whether there is corresponding valid cache data; if so, the valid cache data is fed back to the sender of the target API request; if not, the corresponding valid cache data is obtained through the background server, and the obtained valid cache data is fed back to the sender of the target API request. This embodiment manages API requests through the API gateway, and determines whether there is valid cache data based on the index value, so that different data acquisition methods are used in different situations, so as to reduce the backend service pressure caused by high-concurrency API requests while ensuring the safe execution of API requests as much as possible.

[0063] In an exemplary embodiment, Figure 3 As shown, the above S201 includes:

[0064] S301, obtaining characteristic information of a target API request.

[0065] The characteristic information includes at least one of the method name, request path, query parameter and request body. The method name is such as GET method or POST method.

[0066] The API gateway parses the path and parameters of the target API request, extracts the key features, and obtains the feature information of the target API request.

[0067] S302, using a preset hash function to calculate the index value of the target API request according to the feature information.

[0068] The preset hash function can be implemented based on the MD5 algorithm or the SHA-256 algorithm, etc., and this embodiment does not limit this. Accordingly, the index value can be expressed as a hash value. The use of the preset hash algorithm for calculation can ensure that the generated hash value has high hashability and low conflict rate, thereby ensuring its uniqueness, which is conducive to maintaining the stability of the business system.

[0069] The API gateway uses the characteristic information of the target API request as the input of the preset hash function and obtains the output index value after calculation.

[0070] Exemplarily, the API gateway parses the target API request to obtain the path and parameters of the target API request, and then uses a hash function to concatenate the path and parameter strings into a SHA-256 hash value. The path can be URL (Uniform Resource Locator) information.

[0071] In this embodiment, the index value of the target API request is calculated by a preset hash function, which can ensure the uniqueness of the index value and make it have the characteristics of an index, which is conducive to maintaining the stability of the business system and improving the accuracy of managing the target API request.

[0072] In an exemplary embodiment, the above S202 includes: searching whether corresponding cache data exists according to the index value; wherein the cache data includes valid cache data and invalid cache data; if so, determining whether the cache data is valid cache data according to the storage time of the cache data found.

[0073] The cache data may refer to cache entries, and the storage time of the cache data refers to the time the cache data has been stored in the cache subsystem.

[0074] In order to ensure the real-time and effectiveness of the business, cache data that has been stored for a long time can be determined as invalid cache data.

[0075] Exemplarily, a target value of storage time is determined according to the change frequency of cache data and business requirements. When the storage time of cache data reaches the target value, the cache data is converted from valid cache data to invalid cache data.

[0076] The API gateway searches the cache subsystem for cache data associated with the index value of the target API request, and then identifies the storage time of the cache data if cache data associated with the index value is found, and determines whether the cache data is valid cache data based on the storage time.

[0077] Optionally, the target value is a TTL (Time To Live) value. The API Gateway sets a TTL value for each cached data to define the survival time of the cached data in the cache subsystem. In actual applications, the TTL value can be appropriately reduced during peak traffic periods to ensure that the client obtains valid cached data as close to real-time data as possible. The API Gateway can also delete the cached data from the cache subsystem when the storage time of the cached data reaches the TTL value.

[0078] In this embodiment, a specific method for determining valid cache data is provided. The associated cache data can be accurately found according to the index value, and then more real-time valid cache data can be obtained according to the storage time of the cache data, thereby ensuring the accuracy of responding to the target API request and improving the stability and reliability of the business system.

[0079] In an exemplary embodiment, after obtaining corresponding valid cache data through the background server, the request management method further includes: storing the obtained valid cache data in association with the index value in the cache system.

[0080] It is understandable that only when there is no valid cache data required by the target API request in the cache subsystem, it is necessary to obtain valid cache data through the backend server. Therefore, after obtaining valid cache data through the backend server, the obtained valid cache data and index value can be associated and stored in the cache system (i.e., cache subsystem).

[0081] Exemplarily, the backend server sends the valid cache data to the API gateway, so that the API gateway stores the valid cache data in the cache subsystem. If the corresponding cache data is not found according to the index value, the valid cache data and the index value are associated and stored in the cache system; if the corresponding invalid cache data is found according to the index value, the invalid cache data associated with the index value is replaced with the valid cache data. Furthermore, the storage time of the valid cache data is updated.

[0082] In this embodiment, by timely updating the valid cache data in the cache system, the valid cache data is fed back to the sender of the target API request as directly as possible according to the index value, avoiding obtaining the valid cache data through the background server multiple times, and reducing the number of times the valid cache data is obtained through the background server, thereby reducing the back-end service pressure caused by high-concurrency API requests and optimizing the request management process.

[0083] In an exemplary embodiment, Figure 4 As shown, after the acquired valid cache data is associated with the index value and stored in the cache system, the request management method further includes:

[0084] S401, when it is determined that the target API request is a non-query request, determine the target resource associated with the target API request according to the resource tag of the target API request.

[0085] The valid cache data obtained through the background server is stored in the cache system, and the type of the target API request is further identified, that is, whether the target API request is a query request or a non-query request. In the case that the target API request is a non-query request, the resource tag pre-set for the target API request is obtained, and the target resource is determined according to the resource tag.

[0086] For each API request, the API gateway sets resource tags based on the resources involved in the API request. When the API request involves multiple resources, the corresponding resource tags also include multiple resources, which ensures that any changes to the resources can be tracked.

[0087] Specifically, the API gateway parses the target API request to obtain the corresponding resource tag, and then determines which resources are operated based on the resource tag, analyzes the impact of the operation on the resources, and determines the target resource.

[0088] S402: Update cache data of the target resource.

[0089] Furthermore, the API gateway determines the scope of cached data that needs to be updated based on the target resource, and resets the cached data of the target resource to ensure that subsequent API requests can obtain the latest valid cached data.

[0090] Optionally, the API gateway responds to the target API request, and after determining the index value of the target API request, it can identify the type of the target API request, and then, when the target API request is a non-query request, execute the steps of updating cached data provided in this embodiment.

[0091] In this embodiment, the resource tag information of the API request is introduced. Based on the resource tag, the target resources that may be affected can be quickly and accurately located, and then the cached data of the target resources can be updated, which is beneficial to improving the stability and reliability of the business system through the caching mechanism.

[0092] In an exemplary embodiment, when the number of failures in obtaining corresponding valid cache data through the background server reaches a target value, the request management method further includes: feeding back request failure information to the sender of the target API request.

[0093] In actual applications, the backend server may encounter an abnormal scenario and fail to obtain valid cached data, thus returning abnormal information to the API gateway. The API gateway can retry to obtain the valid cached data required for the target API request.

[0094] Exemplarily, a target value for the number of failures is preset. When the number of failures of the backend server to obtain valid cached data reaches the corresponding target value, that is, when the API gateway receives abnormal information returned by the backend server that reaches the target value, it is determined that the target API request is an abnormal request that cannot be processed at present, and the request failure information is fed back to the client, that is, the sender of the target API request.

[0095] In this embodiment, when the background server returns an error or times out, the API gateway can capture the exception information and retry or feedback error information (request failure information) according to the preset strategy to adapt to different actual application scenarios and ensure the reliability of request management.

[0096] In an exemplary embodiment, Figure 5 As shown, a request management method is provided, which is applied to an API gateway, including:

[0097] S501, in response to a target API request, obtaining characteristic information of the target API request.

[0098] The characteristic information includes at least one of a method name, a request path, a query parameter, and a request body.

[0099] S502: Using a preset hash function, calculate the index value of the target API request according to the feature information.

[0100] S503: Search whether corresponding cache data exists according to the index value.

[0101] The cache data includes valid cache data and invalid cache data.

[0102] If it exists, execute S504; if it does not exist, execute S506.

[0103] S504: Determine whether the cached data is valid cached data according to the storage time of the found cached data.

[0104] If yes, execute S505; if no, execute S506.

[0105] S505: Feedback the valid cache data to the sender of the target API request.

[0106] S506, obtaining corresponding valid cache data through the background server, and storing the obtained valid cache data in the cache system in association with the index value, and feeding back the valid cache data to the sender of the target API request.

[0107] S507: When it is determined that the target API request is a non-query request, determine the target resource associated with the target API request according to the resource tag of the target API request.

[0108] S508: Update the cache data of the target resource.

[0109] Optionally, when the number of failures in obtaining corresponding valid cache data through the background server reaches a target value, request failure information is fed back to the sender of the target API request.

[0110] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0111] Based on the same inventive concept, the embodiment of the present application also provides a request management device for implementing the request management method involved above. The implementation solution provided by the device to solve the problem is similar to the implementation solution recorded in the above method, so the specific limitations in one or more request management device embodiments provided below can refer to the limitations of the request management method above, and will not be repeated here.

[0112] In an exemplary embodiment, Figure 6 As shown, a request management device is provided, comprising:

[0113] An index value determination module 10, configured to determine an index value of a target API request in response to the target API request;

[0114] A data search module 20, used to search whether there is corresponding valid cache data according to the index value;

[0115] A first feedback module 30 is used to feed back the valid cache data to the sender of the target API request when there is corresponding valid cache data;

[0116] The second feedback module 40 is used to obtain the corresponding valid cache data through the background server when there is no corresponding valid cache data, and feed back the obtained valid cache data to the sender of the target API request.

[0117] In an exemplary embodiment, the index value determination module 10 includes:

[0118] A feature information acquisition unit, used to acquire feature information of a target API request; wherein the feature information includes at least one of a method name, a request path, a query parameter, and a request body;

[0119] The index value determination unit is used to calculate the index value of the target API request according to the characteristic information by using a preset hash function.

[0120] In an exemplary embodiment, the data search module 20 includes:

[0121] A data search unit, used to search whether corresponding cache data exists according to the index value; wherein the cache data includes valid cache data and invalid cache data;

[0122] The data judgment unit is used to determine whether the cache data is valid cache data according to the storage time of the cache data found when the corresponding cache data is found.

[0123] In an exemplary embodiment, the request management device further includes:

[0124] The data storage module is used to associate the acquired valid cache data with the index value and store it in the cache system.

[0125] In an exemplary embodiment, the request management device further includes:

[0126] A resource determination module, used to determine a target resource associated with the target API request according to a resource tag of the target API request when determining that the target API request is a non-query request;

[0127] The data update module is used to update the cached data of the target resource.

[0128] In an exemplary embodiment, the request management device further includes:

[0129] The failure feedback module is used to feedback request failure information to the sender of the target API request when the number of failures in obtaining the corresponding valid cache data through the background server reaches the target value.

[0130] Each module in the above request management device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0131] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 7 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store cache data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a request management method is implemented.

[0132] Those skilled in the art will understand that Figure 7The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0133] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps of the above-mentioned request management method when executing the computer program.

[0134] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above request management method are performed.

[0135] In one embodiment, a computer program product is provided, comprising a computer program, which performs the steps of the request management method when executed by a processor.

[0136] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory 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. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0137] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, 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 application.

[0138] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A request management method, characterized in that: Applied to an application programming interface API gateway, the method includes: In response to a target API request, determining an index value of the target API request; According to the index value, searching whether there is corresponding valid cache data; If yes, feeding back the valid cache data to the sender of the target API request; If not, the corresponding valid cache data is obtained through the background server, and the obtained valid cache data is fed back to the sender of the target API request.

2. The method according to claim 1, characterized in that Determining the index value of the target API request includes: Acquire characteristic information of the target API request; wherein the characteristic information includes at least one of a method name, a request path, a query parameter, and a request body; A preset hash function is used to calculate the index value of the target API request according to the feature information.

3. The method according to claim 1, characterized in that The searching, according to the index value, whether corresponding valid cache data exists includes: According to the index value, searching whether corresponding cache data exists; wherein the cache data includes valid cache data and invalid cache data; If so, it is determined whether the cache data is valid cache data according to the storage time of the cache data found.

4. The method according to claim 1, characterized in that After obtaining the corresponding valid cache data through the background server, the method further includes: The acquired valid cache data is associated with the index value and stored in the cache system.

5. The method according to claim 4, characterized in that After the acquired valid cache data is associated with the index value and stored in the cache system, the method further includes: In the case where it is determined that the target API request is a non-query request, determining a target resource associated with the target API request according to a resource tag of the target API request; Update the cached data of the target resource.

6. The method according to claim 1, characterized in that When the number of failures to obtain corresponding valid cache data through the background server reaches a target value, the method further includes: Feedback request failure information to the sender of the target API request.

7. A request management device, characterized in that: Configured in the API gateway, the device includes: An index value determination module, configured to determine an index value of a target API request in response to the target API request; A data search module, used to search whether there is corresponding valid cache data according to the index value; A first feedback module, configured to feed back the valid cache data to the sender of the target API request when there is corresponding valid cache data; The second feedback module is used to obtain the corresponding valid cache data through the background server when there is no corresponding valid cache data, and feed back the obtained valid cache data to the sender of the target API request.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

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

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

Images