Request processing method and device, electronic equipment and storage medium

Abstract

The invention discloses a request processing method and device, electronic equipment and a storage medium, and the method comprises the steps: generating a resource identifier of a first network request in response to the first network request sent by a client; if the resource identifier does not exist in the Promise cache pool, determining that the first network request is a first request, creating a Promise object associated with the resource identifier of the first network request and storing the Promise object in the Promise cache pool, and packaging the network request corresponding to the resource identifier in the associated Promise object for execution; if the resource identifier exists in a Promise cache pool, determining that the first network request is a repeated request, and obtaining a Promise object associated with the resource identifier in the Promise cache pool; the Promise object associated with the resource identifier is returned to the client; and when the Promise object obtains a request execution result of the network request, synchronizing the request execution result to the client obtaining the Promise object. The repeated network requests share the Promise object requested for the first time and the request execution result obtained by the Promise, so that the bandwidth and resource consumption are reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of software development, and in particular to a request processing method, device, electronic device and storage medium. Background Art

[0002] With the continuous development of computer and network technologies, the services that terminals can provide to users are becoming increasingly diverse. For example, in the production process of some game files (such as graphics and dubbing), users can include the production team and the review team. Game files need to go through multiple rounds of review and feedback revisions. Users can then send requests to the corresponding server through the client to obtain the update status or review status of the game files.

[0003] The existing client-server interaction process involves a user triggering a request, the browser establishing a network connection, the server processing and returning data, and the browser rendering and displaying the results. However, when users repeatedly trigger requests by clicking refresh, or when multiple users simultaneously request the same resource, the system fails to recognize these duplicate data requests, causing the server to repeatedly process the same query, resulting in inefficient consumption of bandwidth and computing resources. This can also lead to response delays and interface lag, causing users to spend extended waiting time. Summary of the Invention

[0004] The present invention provides a request processing method to solve the problem that repeated data requests cause ineffective consumption of bandwidth and computing resources and may lead to response delays and interface freezes.

[0005] In a first aspect, the present invention provides a request processing method, comprising:

[0006] In response to a first network request sent by a client, generating a resource identifier of the first network request;

[0007] Determine whether the resource identifier of the first network request exists in the Promise cache pool;

[0008] If not, determining that the first network request is a first request, creating a Promise object associated with the resource identifier of the first network request and storing it in a Promise cache pool, and the network request corresponding to the resource identifier is packaged in the associated Promise object for execution;

[0009] If so, determining that the first network request is a repeated request, and obtaining a Promise object associated with the resource identifier of the first network request from the Promise cache pool;

[0010] Return the Promise object associated with the resource identifier of the first network request to the client; when the Promise object obtains the request execution result of the network request, return the request execution result to the client that has obtained the Promise object.

[0011] In a second aspect, the present invention provides a request processing device, comprising:

[0012] A resource identifier generating module, configured to generate a resource identifier of a first network request in response to a first network request sent by a client;

[0013] A resource identifier determination module is used to determine whether the resource identifier of the first network request exists in the Promise cache pool; if not, execute the content of the creation module; if so, execute the content of the acquisition module;

[0014] a Promise object creation module, configured to determine that the first network request is a first request, create a Promise object associated with the resource identifier of the first network request, and store the Promise object in a Promise cache pool; the network request corresponding to the resource identifier is packaged in the associated Promise object and executed;

[0015] A Promise object acquisition module, configured to determine that the first network request is a repeated request, and obtain a Promise object associated with a resource identifier of the first network request from a Promise cache pool;

[0016] The Promise object returning module is used to return the Promise object associated with the resource identifier of the first network request to the client; when the Promise object obtains the request execution result of the network request, the request execution result is returned to the client that has obtained the Promise object.

[0017] In a third aspect, the present invention provides an electronic device, comprising:

[0018] at least one processor; and

[0019] a memory communicatively connected to the at least one processor; wherein,

[0020] The memory stores a computer program that can be executed by the at least one processor. The computer program is executed by the at least one processor to enable the at least one processor to perform the request processing method described in the first aspect of the present invention.

[0021] In a fourth aspect, the present invention provides a computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a processor to implement the request processing method described in the first aspect of the present invention when executed.

[0022] The embodiment of the present invention provides a request processing method, which has the following beneficial effects:

[0023] For multiple network requests corresponding to the same resource identifier, only the first network request among the multiple network requests is packaged into a Promise object for execution, and other repeated network requests share the Promise object and the request execution results obtained by the Promise. This can greatly reduce server query operations, reduce the ineffective consumption of bandwidth and computing resources, reduce response delays and interface freezes, and also reduce user waiting time.

[0024] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0026] Figure 1 It is a flow chart of a request processing method in the prior art;

[0027] Figure 2 This is a flowchart of a request processing method provided by an embodiment of the present invention;

[0028] Figure 3 This is a flowchart of another method for processing a request when an exception occurs in request execution in the prior art;

[0029] Figure 4 This is a flowchart of a request processing method provided by an embodiment of the present invention;

[0030] Figure 5 Schematic diagram of the relationship between Promise objects corresponding to the first request, repeated request, and retry request for the same resource identifier provided by an embodiment of the present invention;

[0031] Figure 6 This is a schematic diagram of a processing method during a request execution process provided by an embodiment of the present invention;

[0032] Figure 7 This is a flow chart of a request processing method provided by an embodiment of the present invention;

[0033] Figure 8 is a structural diagram of a request processing device provided by an embodiment of the present invention;

[0034] Figure 9 It is a structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0035] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0036] Some terms involved in the embodiments of the present invention are now explained:

[0037] Promise cache pool: Its essence is a map, which is a place to store resource data. The resource identifier is used as the key and the data (Promise object) is stored as the value.

[0038] In JavaScript, you can use the new Promise() constructor to create a Promise object. The constructor accepts an executor function as a parameter, which is called immediately and passes in two callback functions: resolve and reject.

[0039] The Promise object is a constructor used to generate a Promise instance. The Promise object itself does not "execute" network requests, but rather wraps asynchronous operations such as network requests within a Promise for execution. Typically, a Promise instance is created and the asynchronous operation (such as a network request) is executed within its constructor's executor function. The executor function takes two function parameters: resolve and reject. Resolve indicates that the Promise object's status has changed from incomplete to successful, while reject indicates that the Promise object's status has changed from incomplete to failed. The Promise object can be used in a browser environment.

[0040] A Promise object can be in one of three states:

[0041] 1. Pending: The initial state, which is neither redeemed nor rejected.

[0042] 2. Fulfilled: The operation was completed successfully and the resolve function was called.

[0043] 3.Rejected: The operation failed and the reject function was called.

[0044] Figure 1 This is a flowchart of a request processing method in the prior art, which is applied in art review work scenarios, such as Figure 1 As shown, in the prior art, the request processing method when there are repeated requests is as follows:

[0045] The workflow of the traditional art review system: the reviewer of client A clicks on the browser to view the list of works, and the browser generates request 1 (to obtain the work data) and sends it to the server. At this time, the server is a remote server that stores the work data. The server responds to request 1 and returns the work list data to the browser, and displays the work list on client A.

[0046] Simultaneous operation scenario (multiple reviewers operating simultaneously): If the reviewer on client A performs the above operations within a short time, and the reviewer on client B also clicks on the browser to view the work list, the browser generates request 2 (get work data) and sends it to the server. The server responds to request 2 and returns the same work data to the browser, and displays the same work list on client B as on client A. Alternatively, if the reviewer on client A performs the above operations and then refreshes the page, the browser generates request 3 (get work data) and sends it to the server. The server responds to request 3 and returns the same work data to the browser, and displays the same work list on client A.

[0047] It can be seen that in the existing technology, whether it is multiple repeated data requests sent by the same client or repeated data requests for the same target resource sent by different clients, the system is unable to identify these repeated data requests, causing the server to repeatedly process the same query operation, resulting in ineffective consumption of bandwidth and computing resources. This repeated processing not only increases the server load, but also directly affects the system's response speed, causing reviewers to spend more time waiting for the page to load.

[0048] In order to solve the above-mentioned problems existing in the prior art, an embodiment of the present invention provides a request processing method. This embodiment is applicable to request processing situations. The method can be executed by a request processing device. The request processing device can be implemented in the form of hardware and / or software. The request processing device can be configured in an electronic device.

[0049] Figure 2 A flowchart of a request processing method provided by an embodiment of the present invention is shown in FIG. Figure 2 As shown, the request processing method includes:

[0050] S201: In response to a first network request sent by a client, generate a resource identifier of the first network request.

[0051] The first network request is a data request generated by the browser based on a user operation at the client. Each user operation corresponds to a first network request. These first network requests can come from the same client or from different clients.

[0052] The first network request may be an HTTP request. An HTTP request is a process in which a client sends data to a server based on the HTTP protocol. Its core function is to transmit resource operation instructions and parameters, specifically including the resource address of the requested resource and the specific parameter content. Therefore, a resource identifier may be generated based on the resource address and specific parameter content in the first network request. The resource address is the resource path URL, which can be used to locate the corresponding resource data on the network. The parameter content is the specific parameter item to be called at the resource address. For example, if the resource data at the resource address includes data A1, data A2, and data A3, and the parameter content only points to data A3, then the specific parameter item to be called is data A3.

[0053] The resource identifier of a network request is associated with the resource requested by the network request, i.e., the resource identifier points to the resource requested by the network request. Optionally, the first network request includes a resource address and call parameter content, and the resource identifier is generated based on the resource address and call parameter content. When the resource addresses and call parameter content of different first network requests are the same, the resource identifiers corresponding to these first network requests are also the same.

[0054] In an optional embodiment, the first network request includes a resource address and call parameter content, and in response to the first network request sent by the client, a resource identifier of the first network request is generated, including: in response to the first network request sent by the client, determining the resource address and call parameter content in the first network request; splicing the resource address and call parameter content according to a preset splicing method to obtain a resource identifier corresponding to the first network request.

[0055] When generating a resource identifier, the resource address and call parameter content are obtained from the first network request, and then spliced ​​according to a preset splicing method to obtain the resource identifier. The specific splicing method can be: the resource address and call parameter content are sorted according to a preset order to obtain multiple first data items; the multiple first data items are converted into JSON serialized parameters to obtain second data items; and all of the second data items are concatenated using a preset delimiter to obtain the resource identifier corresponding to the first network request.

[0056] JSON serialization is the process of converting a data structure or object into JSON format. It is mainly used to control data filtering and formatting during the serialization process. The preset delimiter can be an underscore, a slash, or a dash, etc., which is not limited to this invention.

[0057] S202: Determine whether the resource identifier of the first network request exists in the Promise cache pool.

[0058] If not, execute S203 and S205; if so, execute S204 and S205.

[0059] S203: Determine that the first network request is the first request, create a Promise object associated with the resource identifier of the first network request and store it in the Promise cache pool, and the network request corresponding to the resource identifier is packaged in the associated Promise object for execution.

[0060] If the resource identifier does not exist in the Promise cache pool, it means that the network request for the resource pointed to by the resource identifier is not currently being executed. Therefore, the Promise object associated with the resource identifier can be recreated to obtain the resource by wrapping the first network request in a Promise object. When creating a new Promise object, the resource identifier is associated with the new Promise object and stored in the Promise cache pool.

[0061] Resource identifiers and Promise objects exist in the Promise cache pool as key-value pairs, with the resource identifier as the Key and the Promise object as the Value. The Promise cache pool typically contains a cache mapping table, which is primarily used to store the mapping between the unique identifier of an interface request (such as a key generated by a combination of URLs and parameters) and the corresponding Promise object. In the Promise cache pool design, this approach allows the system to quickly locate the Promise object for a specific request, enabling request reuse and cache cleanup.

[0062] S204: Determine that the first network request is a repeated request, and obtain a Promise object associated with the resource identifier of the first network request from the Promise cache pool.

[0063] When a resource identifier exists in the Promise cache pool, it means that there is at least one Promise object associated with the resource identifier in the Promise cache pool. The Promise objects in the Promise cache pool are usually in the Pending state. Therefore, when a resource identifier exists in the Promise cache pool, it means that the network request for the resource is being executed, and the Promise object associated with the resource identifier will be able to obtain the execution result of the request for the resource. In order to avoid repeatedly executing the network request for the same resource, the Promise object associated with the resource identifier is first returned to the client that issued the first network request.

[0064] In the embodiment of the present invention, the types of the first network request include an initial request and a repeated request. Both the initial request and the repeated request exist relatively within a certain time period. The following examples are used for explanation:

[0065] For request 1, the generation time is 15:03:02:01, and the target resource to be requested is XY1. If the resource identifier does not exist in the Promise cache pool, request 1 is the first request.

[0066] For request 2, its generation time is 15:03:02:02, and the target resource it requests is also XY1. If its resource identifier is the same as the resource identifier of request 1, and if the resource identifier already exists in the Promise cache pool, then request 2 is a duplicate request.

[0067] For request 3, its generation time is 15:03:02:05, and the target resource it requests is also XY1. If its resource identifier is the same as that of request 1, but if the resource identifier does not exist in the Promise cache pool, then request 3 is the first request.

[0068] Request 1, request 2, and request 3 may be identical, partially identical, or completely different from the corresponding client IP addresses.

[0069] S205: Return the Promise object associated with the resource identifier of the first network request to the client; when the Promise object obtains the request execution result of the network request, return the request execution result to the client that has obtained the Promise object.

[0070] When it is determined that a Promise object associated with the resource identifier of the first network request already exists in the Promise cache pool, the Promise object is returned to the client. At this time, the Promise object is equivalent to a promise to return the request result of the first network request, which indicates a state that has not yet been completed but is expected to be completed in the future.

[0071] If the first network request is the first request, the first network request is wrapped in the Promise object associated with the resource identifier for execution. When the execution is completed, the Promise object obtains the request execution result of the first network request; if the first network request is a repeated request, the first network request and the first request with the same resource identifier share a Promise object. When the Promise object associated with the resource identifier of the first network request is determined, the first request has been wrapped in the Promise object for execution. Therefore, the Promise object is returned first. When the execution of the first request is completed, the Promise object obtains the request execution result of the first request.

[0072] When a Promise object receives the result of a network request, it returns it to the client that received the Promise object, fulfilling the promise. The client can obtain the final result of the network request without polling. The execution results include both successful and failed executions. It's important to note that the Promise object itself doesn't directly store the request execution result, but through its state changes and chaining mechanism, the network request result can be obtained indirectly.

[0073] It can be known that when there are first requests and repeated requests for the same resource within the same time period, only the first request is wrapped in a Promise object for execution. For subsequent repeated requests, the existing Promise object can be quickly returned to the client, reducing the client's waiting time; the server only needs to respond to the resource query request once, and the repeated requests after the first request share the request result of the first request, which can reduce the computing power resource usage of the server and improve the server's response speed.

[0074] An embodiment of the present invention provides a request processing method. For multiple network requests corresponding to the same resource identifier, only the first network request among the multiple network requests is packaged into a Promise object for execution, and other repeated network requests share the Promise object and the request execution result obtained by the Promise. This can greatly reduce the server's query operations, reduce the ineffective consumption of bandwidth and computing resources, reduce response delays and interface freezes, and also reduce user waiting time.

[0075] In the prior art, Figure 3 This is a flowchart of another method for processing a request when an exception occurs in request execution in the prior art. Figure 3 As shown, the process of request execution exception (such as network exception) includes:

[0076] When a worker on client A clicks "Download" on a work, the browser generates a download request and sends it to the server. However, a network timeout or connection failure occurs on the server or browser, preventing the browser from receiving the work's file data. Client A displays an error message on the browsing page. The worker on client A manually clicks "Download" again, causing the browser to generate a new download request and send it to the server. If the server and browser are properly connected, the server returns the work's file data to the browser, and client A displays a successful download.

[0077] It can be seen that in the prior art, when a request execution exception occurs, a prompt indicating execution failure or execution error is directly fed back to the client, and the user needs to re-operate to download the file, which increases the number of user operations and reduces the user experience. In order to solve the above technical problems, an embodiment of the present invention also provides a request processing method. Figure 4 A flowchart of a request processing method provided by an embodiment of the present invention is shown in FIG. Figure 4 As shown, the request processing method also includes:

[0078] S401: When the network request is a first request or a retry request, use the network request as a target network request.

[0079] In the above embodiment, the first network request includes the first request and the repeated request. Only the first request will be packaged in a Promise object for execution, while the repeated request shares the request execution result of its related first request. The retry request is a request generated by re-executing a network request that has been completed and failed. The completed network request can also be the first request or the retry request. The retry request also needs to be packaged in a Promise object for execution. Both the first request and the repeated request are generated based on user operations, and the retry request is generated based on the failed execution result of the previous network request.

[0080] In general, the target network request is a network request that is wrapped in a Promise object.

[0081] S402. When an exception occurs during the execution of a target network request, cached data of the target network request is obtained. The cached data of the target network request includes original data, exception type, and cumulative execution times. The original data of the target network request includes request content and client configuration parameters. The request content includes a resource address and call parameter content. The client configuration parameters include a retry strategy.

[0082] Each target network request corresponds to a data storage unit, and its cached data is stored in the corresponding data storage unit. The cached data of the target network request includes the original data, exception type, and cumulative execution count. During the execution of the target network request, its original data remains unchanged, while the exception type and cumulative execution count can change in real time. It should be noted that the exception type only exists after the network request has been executed and an exception has occurred. When the network request executes normally, the exception type data is empty.

[0083] Among them, the original data is the data contained in the first network request (this must be the first request at this time) corresponding to the target network request. The original data includes the request content and client configuration parameters. The request content includes the resource address and call parameter content. The request content can be used to generate a resource identifier. The client configuration parameters are the parameters and policies pre-configured by the user to control the request execution process. The retry policy is the parameters and policies for re-executing the network request when an exception occurs during the request execution. Specifically, the retry policy includes the exception types allowed for retries, the maximum cumulative number of executions, the retry delay setting, etc.

[0084] S403: Determine whether to re-execute the target network request based on the exception type, the cumulative number of executions, and the retry strategy.

[0085] The retry policy includes the exception type allowed for retry and the maximum cumulative execution times. When the exception type of the target network request belongs to one of the exception types allowed for retry in the retry policy, and the cumulative execution times of the target network request is not greater than the maximum cumulative execution times, the retry policy is satisfied, and it can be determined to re-execute the target network request, and S405 is executed. Otherwise, the retry policy is not satisfied, and it is determined not to re-execute the target network request, and S404 is executed.

[0086] Exception types include timeout errors, network errors, server errors, request code errors, and user input information errors. Timeout errors, network errors, and server errors are exception types that allow retry. Therefore, if the network request exception type is a request code error or a user input information error, retry is not allowed. The exception types allowed for retry and the maximum cumulative number of executions can be set based on actual needs and are not limited by the present invention.

[0087] It should be noted that when determining to re-execute the target network request, the Promise object corresponding to the target network request does not obtain the request execution result of the current target network request.

[0088] S404: Determine whether the target network request has been completed and failed.

[0089] When the target network request is not re-executed, it can be determined that the target network request is completed and failed, and the state of the Promise that wraps the target network request is changed to Rejected.

[0090] S405: Generate a second network request, and update the cached data of the second network request according to the cached data of the target network request.

[0091] When it is determined that the target network request is to be re-executed, the cached data of the second network request is updated based on the cached data of the target network request. Specifically, this includes: using the original data of the target network request as the original data of the second network request; increasing the cumulative execution count in the cached data of the target network request by 1, which is used as the cumulative execution count in the cached data of the second network request; and setting the exception type data in the cached data of the second network request to be empty. With respect to the cumulative execution count, when the second network request is currently generated, since the second network request is pending execution, the cumulative execution count is determined to be increased by 1. With respect to the exception type, since the second network request has not yet been executed, it is impossible to determine whether the second network request has executed abnormally or the type of exception if the second network request has executed abnormally. Therefore, the exception type data in the cached data of the second network request is empty.

[0092] S406: Obtain the resource identifier of the second network request, recreate a Promise object associated with the resource identifier of the second network request, and associate the resource identifier and the Promise object and store them in the Promise cache pool.

[0093] When it is determined to re-execute the target network request, the resource identifier of the second network request is obtained, a Promise object associated with the resource identifier of the second network request is recreated, and the resource identifier and the Promise object are associated and stored in the Promise cache pool.

[0094] The resource identifier of the second network request is the same as the resource identifier of the target network request. The value of the resource identifier of the target network request can be directly assigned to the resource identifier of the target network request, or it can be recalculated through the cached content of the second network request.

[0095] It is important to distinguish between repeated requests and retry requests. For repeated requests, their resource identifiers already exist in the Promise cache pool. You only need to get the Promise object associated with the resource identifier from the Promise cache pool for sharing. For retry requests, although their resource identifiers already exist in the Promise cache pool, the previous target network request is equivalent to having been executed, and the Promise object corresponding to the target network request has also completed its task. Therefore, a new Promise object needs to be recreated to execute the second network request. Figure 5 A diagram showing the relationship between the Promise objects corresponding to the first request, repeated request, and retry request for the same resource identifier. Figure 5 It can be seen that repeated requests for the same resource identifier share the Promise object generated during the first request, and retry requests for the same resource identifier regenerate a new Promise object.

[0096] In an optional embodiment, the target network request is further configured with an operation identifier, i.e., both the initial request and the retry request are configured with an operation identifier. The operation identifier is unique and may also correspond one-to-one with the Promise object that wraps the target network request. The operation identifier can be used to distinguish each execution of the operation. In this case, the cached data of the target network request may also include the operation identifier.

[0097] In this embodiment, when the target network request is executed abnormally, it is determined whether to re-execute it. When it meets the retry strategy, a second network request is generated, and a new Promise object is created. The second network request is packaged in the new Promise object for execution, that is, the user request is automatically re-executed according to the retry strategy, avoiding directly determining that the target network request has failed to execute and increasing the user's request resources, thereby improving the user experience.

[0098] In an alternative embodiment, please refer to Figure 4 After obtaining the resource identifier of the second network request, recreating the Promise object associated with the resource identifier of the second network request and storing it in the Promise cache pool (S405), the request processing method further includes:

[0099] S407: Determine the type of the target network request.

[0100] The target network request is a first request or a retry request.

[0101] S408. When the target network request is the first request, update the Promise object corresponding to the target network request to the Promise object corresponding to the second network request.

[0102] When the target network request is the first request, if there is an exception in its execution process, when it is determined to be re-executed, in order to avoid the Promise object corresponding to the target network request being directly determined as a rejection state and returning the result of execution failure to the client corresponding to the target network request, after the Promise object of the second network request is generated, the Promise object corresponding to the target network request is updated to the Promise object corresponding to the second network request. Then, the target network request can share the Promise object corresponding to the retry request (the second network request), that is, share the request execution result of the retry request.

[0103] In an alternative embodiment, please refer to Figure 4 In S408, when the target network request is a first request, the request processing method further includes:

[0104] The first network request that determines that the resource identifier is the same as the target network request and is a duplicate request fails.

[0105] That is, it is restricted that only the first request can be re-executed when the execution fails, and the request execution result of the re-executed second network request is shared. The re-executed second network request belongs to the retry request corresponding to the first request, but does not belong to the retry request corresponding to the retry request, and the retry request cannot be re-executed. Therefore, it can be directly determined that the execution of the repeated first network request failed.

[0106] S409: When the target network request is a retry request, determine that the resource identifier is the same as the target network request and is the first network request for the first time, and update the Promise object corresponding to the first network request to the Promise object corresponding to the second network request.

[0107] When the target network request is a retry request, its execution process is stored in an exception. Since the first first network request (first request) corresponding to the retry request shares the request execution result of the current target network request, when it is determined that the target network request is still to be re-executed, the current target network request has failed to execute. In order to avoid directly determining that the first first network request has failed, after generating the Promise object of the second network request, first determine the first network request whose resource identifier is the same as the target network request and is the first request, and update the Promise object corresponding to the first network request to the Promise object corresponding to the second network request. Then, the first first network request can share the Promise object corresponding to the retry request (second network request), that is, share the request execution result of the retry request.

[0108] In an optional embodiment, the request processing method further includes:

[0109] When determining to re-execute the target network request, the delay duration is calculated based on the cumulative number of executions and a preset retry interval algorithm; and the second network request is executed after the delay duration.

[0110] The delay duration is primarily used to control the frequency of retries, preventing frequent requests within a short period of time from causing excessive server pressure or triggering anti-crash mechanisms. Properly setting the interval can balance retry success rate and system stability. The preset retry interval algorithm can set the delay duration to be proportional to the cumulative number of executions, meaning that the greater the cumulative number of executions, the longer the delay duration.

[0111] Optionally, the preset retry interval algorithm is an exponential backoff algorithm.

[0112] In general, Figure 4 The corresponding embodiment describes the processing method when an exception occurs in the request execution, and combines the retry execution strategy to process the request with the exception. In order to clearly present the processing method, Figure 6 And the following example to illustrate, Figure 6 A schematic diagram of a processing method during request execution is shown in FIG. Figure 6 Shown, including:

[0113] When executing a request, detect the network status;

[0114] If the network is normal, continue executing until it is successfully completed;

[0115] If the network is abnormal, perform abnormal analysis to determine the abnormality type;

[0116] When the exception type is a timeout error, network error, or server error, and it is determined to be an exception type that allows retry, the process enters the retry judgment stage.

[0117] When the exception type is Other Error, it is determined to be a non-retryable error and the request is determined to have failed;

[0118] Retry judgment: judge whether the cumulative number of executions exceeds the maximum number;

[0119] If the maximum number of times is exceeded, the request is determined to have failed;

[0120] If the number of times is within the limit, the exponential backoff algorithm is used to calculate the delay, wait for the delay, and continue to execute the request after the delay ends.

[0121] In this embodiment, when a request is executed abnormally, an abnormality analysis and a cumulative number of executions are first performed. When all conditions are met in the retry strategy, the request is re-executed after a delay, thereby automatically re-executing the request according to the retry strategy, avoiding the operation of directly determining that the request execution has failed and increasing the user's request resources, thereby improving the user experience and making the process of re-executing the request proceed in an orderly manner. When this solution is applied to art review work, the problem of work interruption caused by network anomalies is effectively solved by utilizing multi-strategy intelligent retry decision steps. The system can automatically identify network timeouts and connection errors, and use appropriate retry strategies to resume operations, reducing manual re-operations caused by network problems by more than 80%. Reviewers do not need to manually repeat clicks and wait, and the average completion time of each review task is shortened by 15 to 20 minutes, significantly improving work efficiency and user experience.

[0122] In an optional embodiment, an embodiment of the present invention provides a request processing method, Figure 7 A flowchart of a request processing method provided by an embodiment of the present invention is shown in FIG. Figure 7 As shown, the request processing method includes:

[0123] S701: When the network request is a first request or a retry request, use the network request as a target network request.

[0124] The target network request is the first request or the retry request. The first request and the retry request will be wrapped in a Promise object for execution.

[0125] S702: Create a cancellation control token associated with the target network request, where the cancellation control token is used to perform cancellation execution control on the associated target network request.

[0126] For ordinary requests, once the request is executed, it cannot be canceled externally. Therefore, a cancellation control token is set to manage the executed target network request.

[0127] S703: Obtain corresponding management parameters from the request management policy according to the type of the target network request. The management parameters include life cycle and timeout monitoring parameters.

[0128] By setting a lifecycle, you can control the initiation and cancellation of network requests throughout their lifecycle. For example, canceling unfinished requests when a component is destroyed prevents memory leaks and unnecessary error handling. By setting timeout monitoring parameters, you can automatically trigger a cancellation token after a specified period of time to interrupt long-unresponsive network requests. These methods not only improve app performance but also enhance the user experience by preventing unnecessary network traffic and error handling.

[0129] S704: Set a token mapping table of a cancellation control token associated with the target network request according to the management parameters. The token mapping is used to indicate a mapping relationship between the cancellation control token and the management parameters.

[0130] By setting the token mapping table, you can set and manage the management parameters of token cancellation.

[0131] S705: Store the token mapping table in the cache data of the target network request.

[0132] S706: After the target network request is executed, clear the cached data of the target network request according to the execution status of the target network request.

[0133] Since network requests are usually large in number, the amount of cached data for network requests is also large. After the request is executed, it is automatically cleaned up according to the execution status to release memory resources.

[0134] Specifically, clearing cache data of the target network request according to the execution status of the target network request includes:

[0135] When the target network request is successfully executed, all cached data of the target network request is cleared; when the target network request fails to be executed, the token mapping table in the cached data of the target network request is cleared.

[0136] That is, the degree of cache data cleaning is related to whether the target network request is executed successfully. If the execution is successful, all cache data will be cleaned up. If it is unsuccessful, only the token data will be cleaned up. The remaining cache data will be retained until the next retry request. The next retry request is the second network request corresponding to the target network request.

[0137] Through layered resource management and automated cleanup, this invention addresses the memory leaks and performance degradation caused by prolonged operation. The system automatically tracks and cleans up ineffective network request resources, reducing the application's memory usage by 40% after eight hours of continuous operation compared to traditional solutions. Page response speeds remain stable, with no noticeable lag. This resource optimization enables a single client to handle more concurrent operations, avoiding browser crashes caused by frequent operations.

[0138] Figure 8 A schematic diagram of the structure of a request processing device provided by an embodiment of the present invention. Figure 8 As shown, the request processing device includes:

[0139] The resource identifier generation module 100 is configured to generate a resource identifier for a first network request sent by a client;

[0140] The resource identifier determination module 200 is used to determine whether the resource identifier of the first network request exists in the Promise cache pool; if not, execute the content of the creation module; if so, execute the content of the acquisition module;

[0141] A Promise object creation module 300 is configured to determine that the first network request is a first request, create a Promise object associated with the resource identifier of the first network request, and store the Promise object in a Promise cache pool. The network request corresponding to the resource identifier is packaged in the associated Promise object and executed.

[0142] A Promise object acquisition module 400 is configured to determine that the first network request is a repeated request and obtain a Promise object associated with a resource identifier of the first network request from a Promise cache pool;

[0143] The Promise object returning module 500 is used to return the Promise object associated with the resource identifier of the first network request to the client; when the Promise object obtains the request execution result of the network request, the request execution result is returned to the client that has obtained the Promise object.

[0144] Optionally, the first network request includes a resource address and call parameter content, and the resource identifier generation module 100 includes:

[0145] A data acquisition submodule, configured to respond to a first network request sent by a client and determine a resource address and call parameter content in the first network request;

[0146] The data splicing submodule is used to splice the resource address and the call parameter content to obtain a resource identifier corresponding to the first network request.

[0147] Optionally, the data splicing submodule is used to:

[0148] Sorting the resource address and the call parameter content in a preset manner to obtain a plurality of first data items;

[0149] Convert the plurality of the first data items into JSON serialization parameters to obtain second data items;

[0150] All of the second data items are concatenated using a preset separator to obtain a resource identifier corresponding to the first network request.

[0151] Optionally, the request processing device further includes:

[0152] A first target request determining module, configured to use the network request as a target network request when the network request is a first request or a retry request;

[0153] a cache data acquisition module, configured to acquire cache data of the target network request when an exception occurs in the execution of the target network request, wherein the cache data of the target network request includes original data, exception type, and cumulative execution times, the original data of the target network request includes request content and client configuration parameters, the request content includes a resource address and call parameter content, and the client configuration parameters include a retry strategy;

[0154] a retry judgment module, configured to judge whether to re-execute the target network request based on the exception type, the cumulative number of executions, and the retry strategy; and if so, execute the content of the second network request generation module;

[0155] A second network request generating module, configured to generate a second network request and update cached data of the second network request according to the cached data of the target network request;

[0156] The Promise object re-creation module is used to obtain the resource identifier of the second network request, re-create the Promise object associated with the resource identifier of the second network request, and store it in the Promise cache pool.

[0157] Optionally, the second network request generating module is configured to:

[0158] The original data of the target network request is used as the original data of the second network request; the cumulative number of executions in the cache data of the target network request is increased by 1, which is used as the cumulative number of executions in the cache data of the second network request; and the data of the abnormal type in the cache data of the second network request is set to empty.

[0159] Optionally, the request processing device further includes:

[0160] A first updating module is configured to update the Promise object corresponding to the target network request to the Promise object corresponding to the second network request when the target network request is a first request;

[0161] The second updating module is used to, when the target network request is a retry request, determine that the resource identifier is the same as the first network request and is the first request, and update the Promise object corresponding to the first network request to the Promise object corresponding to the second network request.

[0162] Optionally, the first update module is further configured to:

[0163] When the target network request is a first request, it is determined that the first network request, which has the same resource identifier as the target network request and is a repeated request, fails to execute.

[0164] Optionally, the request processing device further includes:

[0165] A delay duration calculation module, configured to calculate the delay duration based on the cumulative number of executions and a preset retry interval algorithm when determining to re-execute the target network request;

[0166] The delayed execution module is used to execute the second network request after the delay period.

[0167] Optionally, the request processing device further includes:

[0168] a second target request determining module, configured to use the network request as a target network request when the network request is a first request or a retry request;

[0169] The cancellation control token creation module is used to create a cancellation control token associated with the target network request, and the cancellation control token is used to perform cancellation execution control on the associated target network request.

[0170] Optionally, the target network request includes client configuration parameters, and the client configuration parameters include a request management policy;

[0171] The request processing device further includes:

[0172] A management parameter acquisition module, configured to acquire corresponding management parameters from the request management policy according to the type of the target network request, the management parameters including life cycle and timeout monitoring parameters;

[0173] Setting a token mapping table of the cancellation control token associated with the target network request according to the management parameter, wherein the token mapping is used to represent a mapping relationship between the cancellation control token and the management parameter;

[0174] A storage module is used to store the token mapping table in the cache data of the target network request.

[0175] Optionally, the request processing device further includes:

[0176] The cache clearing module is used to clear the cache data of the target network request according to the execution status of the target network request after the target network request is executed.

[0177] Optionally, the cache clearing module is used to:

[0178] When the target network request is successfully executed, all cached data of the target network request is cleared;

[0179] When the target network request fails to execute, the token mapping table in the cache data of the target network request is cleared.

[0180] The request processing device provided by the embodiment of the present invention can execute the request processing method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0181] Figure 9 A schematic block diagram of an electronic device 90 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are provided for example only and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0182] like Figure 9 As shown, the electronic device 90 includes at least one processor 91 and a memory, such as a read-only memory (ROM) 92, a random access memory (RAM) 93, etc., which is communicatively connected to the at least one processor 91. The memory stores a computer program that can be executed by the at least one processor, and the processor 91 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 92 or the computer program loaded from the storage unit 98 into the random access memory (RAM) 93. Various programs and data required for the operation of the electronic device 90 can also be stored in the RAM 93. The processor 91, ROM 92, and RAM 93 are connected to each other via a bus 94. An input / output (I / O) interface 95 is also connected to the bus 94.

[0183] Multiple components in the electronic device 90 are connected to the I / O interface 95, including an input unit 96, such as a keyboard, a mouse, etc.; an output unit 97, such as various types of displays, speakers, etc.; a storage unit 98, such as a magnetic disk, an optical disk, etc.; and a communication unit 99, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 99 allows the electronic device 90 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0184] The processor 91 may be any general-purpose and / or specialized processing component with processing and computing capabilities. Examples of the processor 91 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors for running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 91 executes the various methods and processes described above, such as the request processing method.

[0185] In some embodiments, the request processing method can be implemented as a computer program that is tangibly contained in a computer-readable storage medium, such as storage unit 98. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 90 via ROM 92 and / or communication unit 99. When the computer program is loaded into RAM 93 and executed by processor 91, one or more steps of the request processing method described above can be performed. Alternatively, in other embodiments, processor 91 can be configured to perform the request processing method in any other suitable manner (e.g., by means of firmware).

[0186] Various embodiments of the systems and techniques described above can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0187] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0188] In the context of the present invention, computer-readable storage media can be tangible media that can contain or store a computer program for use with an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Computer-readable storage media can include but are not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, computer-readable storage media can be machine-readable signal media. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0189] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a monitor having a cathode ray tube or a liquid crystal display) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or a trackball) through which the user can provide input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0190] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0191] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0192] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.

[0193] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A request processing method, characterized in that: include: In response to a first network request sent by a client, generating a resource identifier of the first network request; Determine whether the resource identifier of the first network request exists in the Promise cache pool; If not, determining that the first network request is a first request, creating a Promise object associated with the resource identifier of the first network request and storing it in a Promise cache pool, and the network request corresponding to the resource identifier is packaged in the associated Promise object for execution; If so, determining that the first network request is a repeated request, and obtaining a Promise object associated with the resource identifier of the first network request from the Promise cache pool; Returning the Promise object associated with the resource identifier of the first network request to the client; When the Promise object obtains the request execution result of the network request, the request execution result is returned to the client that has obtained the Promise object.

2. The method according to claim 1, wherein The first network request includes a resource address and call parameter content, and the generating of a resource identifier of the first network request in response to the first network request sent by the client includes: In response to a first network request sent by a client, determining a resource address and call parameter content in the first network request; The resource address and the call parameter content are concatenated to obtain a resource identifier corresponding to the first network request.

3. The method according to claim 2, wherein The concatenating the resource address and the call parameter content to obtain a resource identifier corresponding to the first network request includes: Sorting the resource address and the call parameter content in a preset manner to obtain a plurality of first data items; Convert the plurality of the first data items into JSON serialization parameters to obtain second data items; All of the second data items are concatenated using a preset separator to obtain a resource identifier corresponding to the first network request.

4. The method according to claim 1, wherein The method further comprises: When the network request is the first request or a retry request, the network request is used as the target network request; When an exception occurs in the execution of the target network request, obtaining cached data of the target network request, the cached data of the target network request including original data, exception type, and cumulative execution times, the original data of the target network request including request content and client configuration parameters, the request content including resource address and call parameter content, and the client configuration parameters including a retry strategy; Determine whether to re-execute the target network request according to the exception type, the cumulative number of executions and the retry strategy; If so, generating a second network request, and updating the cached data of the second network request according to the cached data of the target network request; Obtain the resource identifier of the second network request, recreate a Promise object associated with the resource identifier of the second network request, and store the object in the Promise cache pool.

5. The method according to claim 4, wherein The updating of the cache data of the second network request according to the cache data of the target network request includes: The original data of the target network request is used as the original data of the second network request; the cumulative number of executions in the cache data of the target network request is increased by 1, which is used as the cumulative number of executions in the cache data of the second network request; and the data of the abnormal type in the cache data of the second network request is set to empty.

6. The method according to claim 4, wherein After obtaining the resource identifier of the second network request, recreating the Promise object associated with the resource identifier of the second network request and storing it in the Promise cache pool, the method further includes: When the target network request is a first request, updating the Promise object corresponding to the target network request to the Promise object corresponding to the second network request; When the target network request is a retry request, determine that the resource identifier is the same as that of the target network request and that the first network request is a first request, and update the Promise object corresponding to the first network request to the Promise object corresponding to the second network request.

7. The method according to claim 6, wherein When the target network request is a first request, the method further includes: It is determined that the first network request, which has the same resource identifier as the target network request and is a duplicate request, fails to execute.

8. The method according to claim 4, wherein Also includes: When determining to re-execute the target network request, calculating the delay duration according to the cumulative number of executions and a preset retry interval algorithm; The second network request is executed after the delay period.

9. The method according to claim 1, wherein Also includes: When the network request is the first request or a retry request, the network request is used as the target network request; A cancellation control token associated with the target network request is created, where the cancellation control token is used to perform cancellation execution control on the associated target network request.

10. The method according to claim 9, wherein The target network request includes client configuration parameters, and the client configuration parameters include a request management policy; The method further comprises: Acquire corresponding management parameters from the request management policy according to the type of the target network request, the management parameters including life cycle and timeout monitoring parameters; Setting a token mapping table of the cancellation control token associated with the target network request according to the management parameter, wherein the token mapping is used to represent a mapping relationship between the cancellation control token and the management parameter; The token mapping table is stored in the cache data of the target network request.

11. The method according to claim 10, wherein Also includes: After the target network request is executed, cache data of the target network request is cleared according to the execution status of the target network request.

12. The method according to claim 11, wherein The clearing cache data of the target network request according to the execution status of the target network request includes: When the target network request is successfully executed, all cached data of the target network request is cleared; When the target network request fails to execute, the token mapping table in the cache data of the target network request is cleared.

13. A request processing device, characterized in that: include: A resource identifier generating module, configured to generate a resource identifier of a first network request in response to a first network request sent by a client; A resource identifier determination module, configured to determine whether the resource identifier of the first network request exists in the Promise cache pool; If not, execute the content of the creation module, if so, execute the content of the acquisition module; a Promise object creation module, configured to determine that the first network request is a first request, create a Promise object associated with the resource identifier of the first network request, and store the Promise object in a Promise cache pool; the network request corresponding to the resource identifier is packaged in the associated Promise object and executed; A Promise object acquisition module, configured to determine that the first network request is a repeated request, and obtain a Promise object associated with a resource identifier of the first network request from a Promise cache pool; A Promise object returning module, configured to return the Promise object associated with the resource identifier of the first network request to the client; When the Promise object obtains the request execution result of the network request, the request execution result is returned to the client that has obtained the Promise object.

14. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor. The computer program is executed by the at least one processor to enable the at least one processor to perform the request processing method according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the request processing method according to any one of claims 1 to 12 when executed.

Images