Parameter cache concurrent request management method and system, electronic equipment and storage medium
By determining the cache key of a client's request, the system avoids repeatedly processing requests for the same data, thus solving the problems of wasted server resources and increased response time in high-concurrency scenarios, improving user experience, and preventing data loss and memory leaks.
Patent Information
- Application Number
- CN202511724040.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-22
- Publication Date
- 2026-02-17
AI Technical Summary
In high-concurrency scenarios, traditional request processing methods lead to wasted server resources and increased system response time, resulting in a reduced user experience. Existing technologies such as debouncing and Promise aggregation control pose risks of data loss, delayed feedback, and memory leaks.
By checking if the cache key for the client's request exists, if it does not exist, the Promise list is initialized and the request is processed; if it exists, a new Promise is allocated and stored in the pending list to avoid duplicate processing.
It avoids the repeated processing of the same data, saves server resources, reduces system response time, improves user experience, and prevents data loss and memory leaks.
Smart Images
Figure CN121542523A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of computer, more particularly, to a parameter cache concurrent request management method and system, electronic equipment and storage medium. BACKGROUND
[0002] The current e-commerce system is faced with various problems such as large number of users, various types of goods, frequent transactions, large amount of data, etc. Especially during the operation of the system, especially during activities such as flash sales and holidays, the platform is faced with severe high-concurrency scenarios. Under the high-concurrency scenario, a large number of users may simultaneously request the same or similar data, such as product information, inventory status, etc.
[0003] In the traditional request processing mode, even if the same data is requested, each request is still processed independently. This not only leads to waste of server resources, but also increases the system response time due to repeated processing, reducing the user experience. SUMMARY
[0004] Therefore, the present application provides a parameter cache concurrent request management method and system, electronic equipment and storage medium to avoid wasting server resources and to avoid repeated processing to increase the system response time and reduce the user experience.
[0005] The first aspect of the present application provides a parameter cache concurrent request management method, the method comprising:
[0006] When a new client request is received, it is determined whether there is another client request in the pendingMap that is the same as the new client request;
[0007] If not, initialize the corresponding Promise list for the new client request in the pendingMap, and store the new client request and its associated cache key to the Promise list; wherein the cache key is generated according to the new client request;
[0008] Execute the promiseFn function to process the new client request to obtain the corresponding execution result, and feed back the execution result to each Promise in the Promise list to resolve or reject the client request corresponding to each Promise;
[0009] If there is, assign a new Promise to the new client request, and add the new Promise to the pending Promise list corresponding to the new client request;
[0010] The execution result of the first added client request in the to-be-processed Promise list is fed back to the new Promise to resolve or reject the new client request.
[0011] Optionally, when receiving a client request, it is judged whether there is a same client request as the client request in the pendingMap, comprising:
[0012] When receiving a client request, extracting a request parameter from the new client request;
[0013] The request parameter is parsed to generate a cache key unique to the new client request, and it is judged whether there is another client request with the same cache key as the new client request in the pendingMap;
[0014] If there is, it is determined that there is another client request with the same client request in the pendingMap;
[0015] If not, it is determined that there is no other client request with the same client request in the pendingMap.
[0016] Optionally, the method further comprises:
[0017] After resolving or rejecting the target Promise, the target Promise list is traversed to call the function of each target Promise in the target Promise list to delete the corresponding item in the pendingMap; wherein the target Promise is the Promise or the new Promise, and the target Promise list is the Promise list or the to-be-processed Promise list.
[0018] Optionally, the method further comprises:
[0019] During the execution of the promiseFn function, it is detected in real time whether the promiseFn function has an execution error;
[0020] If the promiseFn function has an execution error, the execution error of the promiseFn function is captured, and all Promises in the Promise list are rejected.
[0021] The second aspect of the application provides a parameter cache and concurrent request management system, the system comprises:
[0022] A judging unit is configured to judge whether there is another client request with the same new client request in the pendingMap when receiving a new client request;
[0023] an initialization and storage unit configured to initialize a corresponding Promise list in the pendingMap for the new client request if the pendingMap does not exist, and store the new client request and its associated cache key to the Promise list, wherein the cache key is generated according to the new client request;
[0024] an execution and feedback unit configured to execute the promiseFn function to process the new client request, obtain a corresponding execution result, and feed back the execution result to each Promise in the Promise list to resolve or reject the client request corresponding to each Promise;
[0025] an allocation unit configured to allocate a new Promise to the new client request and add the new Promise to the corresponding to-be-processed Promise list of the new client request if the pendingMap exists;
[0026] a feedback unit configured to feed back the execution result of the first client request added to the to-be-processed Promise list to the new Promise to resolve or reject the new client request.
[0027] Optionally, when receiving a client request, the judging unit judging whether the pendingMap exists the same client request as the client request, comprises:
[0028] extracting a request parameter from the new client request when receiving a client request;
[0029] analyzing the request parameter, generating a cache key unique to the new client request, and judging whether the pendingMap exists other client requests with the same cache key as the new client request;
[0030] if the pendingMap exists, determining that the pendingMap exists other client requests with the same cache key as the new client request;
[0031] if the pendingMap does not exist, determining that the pendingMap does not exist other client requests with the same cache key as the new client request.
[0032] Optionally, the system further comprises a deletion unit;
[0033] The deleting unit is configured to, after resolving or rejecting the target Promise, traverse the target Promise list to call a function of each target Promise in the target Promise list to delete a corresponding item in the pendingMap; wherein the target Promise is the Promise or the new Promise, and the target Promise list is the Promise list or the to-be-processed Promise list.
[0034] Optionally, the system further comprises a rejecting unit.
[0035] The rejecting unit is configured to, in the process of executing the promiseFn function, detect whether an execution error of the promiseFn function occurs in real time; if the execution error of the promiseFn function occurs, capture the execution error of the promiseFn function, and reject all Promises in the Promise list.
[0036] The third aspect of the present application provides an electronic device, comprising: a processor and a memory, the processor and the memory are connected through a bus; wherein the processor is used to call and execute a program stored in the memory; the memory is used to store a program, the program is used to realize a parameter cache concurrent request management method provided by the first aspect of the present application.
[0037] The fourth aspect of the present application provides a computer readable storage medium, the computer readable storage medium stores computer executable instructions, the computer executable instructions are used to execute a parameter cache concurrent request management method provided by the first aspect of the present application.
[0038] This application provides a parameter caching concurrent request management method. When a new customer request is received, it checks whether there are other customer requests identical to the new customer request in the pendingMap. If not, it initializes a corresponding Promise list for the new customer request in the pendingMap and stores the new customer request and its associated cache key in the Promise list. The cache key is generated based on the new customer request. The promiseFn function is executed to process the new customer request, and the corresponding execution result is obtained. The execution result is fed back to each Promise in the Promise list to resolve or reject the customer request corresponding to each Promise. If the new customer request exists, a new Promise is allocated for the new customer request and added to the pending Promise list corresponding to the new customer request. The execution result of the first customer request added to the pending Promise list is fed back to the new Promise to resolve or reject the new customer request. Therefore, the technical solution provided in this application, when a new customer request arrives, can first determine whether another identical customer request already exists. If it does, a new Promise can be allocated for the new customer request, and the new Promise for the new customer request can be stored in the corresponding list of pending Promises for processing, waiting to be processed, thus avoiding the execution of the request processing logic for the new customer request. Only when it is determined that there are no other customer requests identical to the new customer request will the request processing logic for the new customer request be executed. That is, the corresponding Promise list for the new customer request is initialized in the pendingMap, and the new customer request and its associated cache key are stored in the Promise list. Finally, the promiseFn function is executed to process the new customer request. It is not necessary to process every customer request, thereby avoiding the repeated processing of customer requests that request the same data, thus avoiding the waste of server resources and the problems of increased system response time and reduced user experience caused by repeated processing. Attached Figure Description
[0039] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0040] Figure 1 An example diagram illustrating a Promise instance request process provided for existing technologies;
[0041] Figure 2A flowchart illustrating a parameter caching concurrent request management method provided in an embodiment of this application;
[0042] Figure 3 An example diagram illustrating a parameter caching concurrent request management method provided in this application embodiment;
[0043] Figure 4 An example diagram provided for an embodiment of this application shows how to automatically remove the corresponding item from the list of pending Promises after a Promise is resolved or rejected;
[0044] Figure 5 This is a schematic diagram of the structure of a parameter caching concurrent request management system provided in an embodiment of the present invention;
[0045] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0046] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0047] In this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.
[0048] To better understand this application, the following explanations are provided regarding the technologies involved:
[0049] Customer Requests: The system provides services to customers. Clients perform actions such as viewing information and operating resources by sending requests to the system's backend service. Customers typically initiate requests by inputting corresponding parameters or operations through a visual page. The system's backend service processes customer requests logically and returns result information.
[0050] Promise: In JavaScript, a Promise is an object used for asynchronous programming. It represents the eventual completion (with a result value) or failure (with a reason) of an asynchronous operation, and is mainly used to solve problems related to asynchronous operations.
[0051] A Promise object has three states: Pending: the initial state, which is neither success nor failure; Fulfilled (resolved): meaning the operation was successfully completed; Rejected: meaning the operation failed.
[0052] The `then` method is typically used in Promise instances, accepting either a successful (`onFulfilled`) or failed (`onRejected`) asynchronous operation as an argument. It returns a new Promise instance, allowing for chained calls to other operations. The Promise instance request process is as follows: Figure 1 As shown.
[0053] Asynchronous operations: In JavaScript, asynchronous operations are those that do not block the execution of subsequent code. When an asynchronous operation is initiated, it allows the program to continue executing subsequent code without waiting for the operation to complete. Once an asynchronous operation completes, it typically notifies the main program or processes its result through mechanisms such as callback functions or promises.
[0054] Caching mechanisms: In JavaScript, caching is an optimization technique where users store frequently accessed data or resources to improve application performance and responsiveness. Caching mechanisms allow browsers or programs to save resources locally or in memory after the initial load, so that subsequent requests can access these resources more quickly.
[0055] High concurrency: High concurrency usually refers to a large number of users accessing the same API interface or URL address at the same time within a very short unit of time, resulting in multiple requests being sent to the server at the same time.
[0056] As the background information above shows, in traditional request processing methods, each request is processed independently, even if they request the same data. This not only wastes server resources but can also increase system response time and degrade user experience due to duplicate processing.
[0057] In existing technologies, concurrent requests can also be handled by debouncing. Specifically, when a series of events are triggered, only the last request is executed, and requests in the middle are canceled. However, if the user enters new content while waiting, and the previous request is canceled, there is a risk of data loss (e.g., the intermediate input request is not processed) and delayed feedback.
[0058] Alternatively, you can cancel incomplete duplicate requests using Abortable Requests. However, this method carries the risk of race conditions. If a canceled request returns a delayed success, subsequent requests may overwrite the result. In addition, its logic is complex, requiring tracking the AbortController for each request, which increases the risk of memory leaks.
[0059] Alternatively, Promise aggregation can be used for control, i.e., using Promise.all and Promise.race to manage concurrent requests. However, in this approach, each request still needs to be sent to the server independently for processing, which is not only inefficient but also results in longer waiting times for users, leading to a poor user experience.
[0060] Therefore, this application provides a parameter caching concurrent request management method, system, electronic device, and storage medium. When a new client request arrives, it can first determine whether another identical client request already exists. If so, a new Promise can be allocated for the new client request, and the new Promise is stored in the corresponding pending Promise list for processing, avoiding the execution of the request processing logic for the new client request. Instead of indiscriminately canceling new client requests according to fixed rules, the new client request is only placed in the waiting area (pending Promise list) if it is determined that another identical client request exists, thus avoiding... Issues such as data loss, delayed feedback, and memory leaks may occur. If it is determined that no other customer request is identical to the new customer request, the request processing logic for the new customer request is executed. This involves initializing a corresponding Promise list for the new customer request in the pendingMap, storing the new customer request and its associated cache key in the Promise list, and finally executing the promiseFn function to process the new customer request. This avoids processing every customer request individually, thus preventing duplicate processing of customer requests for the same data, avoiding wasted server resources, and preventing increased system response time and reduced user experience due to redundant processing.
[0061] See Figure 2 The diagram illustrates a flowchart of a parameter caching concurrent request management method provided in an embodiment of this application. The method specifically includes the following steps:
[0062] S201: When a new customer request is received, determine whether there are other customer requests in the pendingMap that are the same as the new customer request; if not, proceed to step S202; if so, proceed to step S204.
[0063] In this embodiment of the application, a concurrent request processing function can be predefined, such as the concurPromise function. The concurPromise function can accept not only an asynchronous function promiseFn of a Promise as a parameter, but also an options object containing a comparison function.
[0064] It should be noted that a suitable comparison tool can be selected as the comparison function according to the actual application to determine whether the parameters carried by each request are equal, that is, to determine whether each request is the same.
[0065] During the specific execution of step S201, when a customer request is received, the request parameters are extracted from the new customer request; the request parameters are parsed to generate a unique cache key for the new customer request, and it is determined whether there are other customer requests in pendingMap with the same cache key as the new customer request; if there are, it is determined that there are other customer requests with the same cache key as the new customer request in pendingMap, and step S1004 is executed; if there are no other customer requests with the same cache key as the new customer request in pendingMap, step S202 is executed.
[0066] It should be noted that a corresponding pendingMap can be pre-constructed. The pendingMap includes multiple arrays of pending Promises (pendingPromises), which are multiple lists of pending Promises. For each list of pending Promises, the list must contain at least the first customer request added to the list, its cache key, and multiple Promises corresponding to customer requests. The request parameters of each customer request corresponding to each Promise stored in the list of pending Promises are the same.
[0067] It should also be noted that the list of pending Promises is also used to store all Promise resolution functions (resolve and reject) that are waiting for the current key (the cache key of the first client request) and its corresponding request result.
[0068] In this embodiment, when a new customer request is received, the `concurPromise` function can be called to generate a cache key for the new customer request. The `options` object, which includes a comparison function, is then used to determine whether another customer request with the same cache key exists in the `pendingMap`. If such a request exists, it indicates that another request with the same request parameters as the new customer request already exists. To avoid duplicate processing, the request processing logic for this new customer request is not executed. Instead, a new Promise is returned for the new customer request, and a matching Promise to be processed is determined from the `pendingMap` based on the cache key of the new customer request. The `e` list is used to store the new Promise of the new customer request into a matching list of pending Promises. The new Promise of the new customer request is stored in the "waiting area" to await processing. If no such list exists, it means that there are currently no other customer requests with the same request parameters as the new customer request. In other words, this new customer request is the first customer request at present. In this case, a corresponding Promise list can be created for the new customer request so that when subsequent customer requests with the same request parameters are received, they can be stored in the new customer request's Promise list to avoid duplicate processing of customer requests with identical request parameters.
[0069] S202: Initialize the corresponding Promise list for the new customer request in pendingMap, and store the new customer request and its associated cache key in the Promise list; where the cache key is generated based on the new customer request.
[0070] In the specific execution step S202, if it is determined that there are no other customer requests in pendingMap that are the same as the new customer request, a new Promise list can be initialized in pendingMap for the new customer request. The initialized Promise list is used as the list of pending Promises for the new customer request (i.e., the array of pending Promises (pendingPromises)) to provide a corresponding "waiting area" for subsequent customer requests with the same request parameters as the new customer request. The new customer request is associated with its cache key, and the Promise of the new customer request, its Promise resolution function (resolve and reject), and the cache key are stored in the Promise list.
[0071] S203: Execute the promiseFn function to process the new client request, obtain the corresponding execution result, and feed the execution result back to each Promise in the Promise list to resolve or reject the client request corresponding to each Promise.
[0072] In the specific execution step S203, after storing the cache key associated with the new customer request and the Promise resolution function into the corresponding Promise list, the concurPromise function can be called to execute the promiseFn function returned by the Promise corresponding to the new customer request to process the new customer request; after the promiseFn function is executed, the corresponding execution result is obtained, which can be success or failure; after obtaining the corresponding execution result, it can be checked whether there is a Promise in the Promise list corresponding to the new customer request that has the same request parameters as the new customer request; if it exists, the execution result is fed back to each Promise in the Promise list to resolve or terminate each Promise, that is, to resolve or terminate the customer request that has the same request parameters as the new customer request.
[0073] S204: Assign a new Promise to the new customer request and add the new Promise to the list of pending Promises corresponding to the new customer request.
[0074] During the specific execution of step S204, when it is determined that there are other customer requests with the same request parameters as the new customer request already existing in the pendingMap, in order to avoid repeatedly processing customer requests with the same request parameters, the request processing logic of the new customer request is not executed at this time (i.e., the execution process indicated in step S203 is not executed). Instead, a new Promise is allocated for the new customer request, and a list of other pending Promises with the same cache key as the new customer request is determined so that the new Promise can be added to the list of pending Promises, so that it can be processed when the first customer request added to the list of pending Promises is processed.
[0075] It should be noted that the processing time for a new customer request depends on the processing time of the first customer request added to the corresponding pending Promise list, that is, the execution time of the promiseFn function of the Promise of the first customer request added to the pending Promise list (from initiation to completion, i.e., the duration from pending->fulfilled state or pending->rejected state).
[0076] S205: Feedback the execution result of the first customer request added to the list of pending Promises to the new Promise to resolve or reject the new customer request.
[0077] During the specific execution step S105, it is possible to detect in real time whether the first customer request added to the list of pending Promises corresponding to the new customer request has been processed. If it has been processed, the execution result of the first customer request added to the list of pending Promises can be used as the execution result of all customer requests corresponding to Promises stored in the list of pending Promises. The execution result of the first customer request added to the list of pending Promises can be fed back to the customer requests corresponding to each Promise in the list of pending Promises, that is, the execution result of the first customer request added to the list of pending Promises can be fed back to the new customer request.
[0078] It should be noted that if the execution result of the first client request added to the pending Promise list is successful, then all client requests corresponding to Promises in the pending Promise list can be resolved; if it fails, then all client requests corresponding to Promises in the pending Promise list can be rejected.
[0079] In practical applications, see Figure 3 At the same time, multiple new customer requests are received, including request 2, request 3, ..., request n; a unique cache key is generated for each new customer request based on the request parameters; if the cache keys of all new customer requests are the same, it means that multiple new customer requests with the same request parameters have been received at the same time.
[0080] The `concurPromise` function is called to iterate through the list of pending Promises in `pendingMap`. The `options` object, which contains a comparison function, is used to compare the cache key of the new client request with the cache keys stored in the list of pending Promises to determine whether there are other client requests in the list of pending Promises that have the same cache key as the new client request.
[0081] If it is determined that the cache key of request 1 (another customer request) is the same as the cache key of the new customer request, then a new Promise is assigned to each new customer request, and each new Promise is stored in the list of pending Promises corresponding to request 1, waiting to be processed.
[0082] The system monitors in real time whether the request processing logic for request 1 has been completed. When the completion of the request processing logic for request 1 is detected, the execution result (the execution result of request 1) is fed back to all Promises in the pending Promise list. In other words, the execution result is fed back to the requests (request 1, request 2, request 3, ..., request n) corresponding to all Promises in the pending Promise list, so as to resolve or reject all customer requests in the pending Promise list.
[0083] In some embodiments, other customer requests with the same request parameters as the new customer request can synchronize their corresponding promise status (success or failure) after receiving the corresponding execution result, ensuring that the corresponding Promise is resolved / rejected only once. When the corresponding Promise is resolved or rejected, the corresponding item can be automatically removed from the corresponding pending Promise list to release the corresponding resources.
[0084] It should be noted that the items include the stored cache keys in the list of Promises to be processed and all Promises.
[0085] Furthermore, in this embodiment of the application, after resolving or rejecting the target Promise, the target Promise list is traversed to call the function of each target Promise in the target Promise list to delete the corresponding item in the pendingMap; wherein, the target Promise is a Promise or a new Promise, and the target Promise list is a Promise list or a list of Promises to be processed.
[0086] In practical applications, when the execution result indicates a successful request, the corresponding list of pending Promises is iterated through, the resolve function of each Promise in the list is called, and the corresponding item is removed from the pendingMap. When the execution result indicates a failed request, the list of pending Promises is iterated through, the reject function of each Promise is called, and the corresponding item is removed from the pendingMap.
[0087] For example, see Figure 4Once Promise1, the first client request added to the pending Promise list in the pending Map, has been executed, the pending Promise list can be traversed to obtain the execution results and send them back to the request corresponding to each Promise in the pending Promise list. After sending the corresponding execution results to the request of each Promise, if the execution result indicates that the request was successful, the corresponding pending Promise list can be traversed, the resolve function of each Promise in the pending Promise list can be called, and the corresponding item can be deleted from the pending Map.
[0088] Furthermore, in this embodiment, during the execution of the promiseFn function, whether an execution error occurs in the promiseFn function is detected in real time; if an execution error occurs in the promiseFn function, the execution error of the promiseFn function is captured, and all Promises in the Promise list are rejected.
[0089] It should be noted that if an error occurs during the execution of promiseFn, the error will be caught, and all waiting Promises will be rejected to ensure that the error is properly propagated and handled.
[0090] This application provides a parameter caching concurrent request management method. When a new customer request is received, it checks whether there are other customer requests identical to the new customer request in the pendingMap. If not, it initializes a corresponding Promise list for the new customer request in the pendingMap and stores the new customer request and its associated cache key in the Promise list. The cache key is generated based on the new customer request. The promiseFn function is executed to process the new customer request, and the corresponding execution result is obtained. The execution result is fed back to each Promise in the Promise list to resolve or reject the customer request corresponding to each Promise. If the new customer request exists, a new Promise is allocated for the new customer request and added to the pending Promise list corresponding to the new customer request. The execution result of the first customer request added to the pending Promise list is fed back to the new Promise to resolve or reject the new customer request. Therefore, the technical solution provided in this application, when a new customer request arrives, can first determine whether another identical customer request already exists. If it does, a new Promise can be allocated for the new customer request, and the new Promise for the new customer request can be stored in the corresponding list of pending Promises for processing, waiting to be processed, thus avoiding the execution of the request processing logic for the new customer request. Only when it is determined that there are no other customer requests identical to the new customer request will the request processing logic for the new customer request be executed. That is, the corresponding Promise list for the new customer request is initialized in the pendingMap, and the new customer request and its associated cache key are stored in the Promise list. Finally, the promiseFn function is executed to process the new customer request. It is not necessary to process every customer request, thereby avoiding the repeated processing of customer requests that request the same data, thus avoiding the waste of server resources and the problems of increased system response time and reduced user experience caused by repeated processing.
[0091] Based on the parameter caching concurrent request management method provided in the above embodiments of this application, correspondingly, the present application embodiments provide a parameter caching concurrent request management system, such as... Figure 5 As shown, the parameter caching concurrent request management system includes:
[0092] The judgment unit 51 is used to determine whether there are other customer requests in the pendingMap that are the same as the new customer request when a new customer request is received.
[0093] The initialization and storage unit 52 is used to initialize the corresponding Promise list for the new customer request in the pendingMap if it does not exist, and to store the new customer request and its associated cache key in the Promise list; wherein the cache key is generated based on the new customer request;
[0094] The execution and feedback unit 53 is used to execute the promiseFn function to process new customer requests, obtain the corresponding execution results, and feed back the execution results to each Promise in the Promise list to resolve or reject the customer requests corresponding to each Promise.
[0095] Allocation unit 54 is used to allocate a new Promise for the new customer request if it exists, and add the new Promise to the list of pending Promises corresponding to the new customer request;
[0096] Feedback unit 55 is used to feed back the execution result of the first customer request added to the list of pending Promises to the new Promise, so as to resolve or reject the new customer request.
[0097] This application provides a parameter caching concurrent request management system. When a new customer request is received, it checks whether there are other customer requests identical to the new customer request in the pendingMap. If not, it initializes a corresponding Promise list for the new customer request in the pendingMap and stores the new customer request and its associated cache key in the Promise list. The cache key is generated based on the new customer request. The promiseFn function is executed to process the new customer request, and the corresponding execution result is obtained. The execution result is fed back to each Promise in the Promise list to resolve or reject the customer request corresponding to each Promise. If the new customer request exists, a new Promise is allocated for the new customer request and added to the pending Promise list corresponding to the new customer request. The execution result of the first customer request added to the pending Promise list is fed back to the new Promise to resolve or reject the new customer request. Therefore, the technical solution provided in this application, when a new customer request arrives, can first determine whether another identical customer request already exists. If it does, a new Promise can be allocated for the new customer request, and the new Promise for the new customer request can be stored in the corresponding list of pending Promises for processing, waiting to be processed, thus avoiding the execution of the request processing logic for the new customer request. Only when it is determined that there are no other customer requests identical to the new customer request will the request processing logic for the new customer request be executed. That is, the corresponding Promise list for the new customer request is initialized in the pendingMap, and the new customer request and its associated cache key are stored in the Promise list. Finally, the promiseFn function is executed to process the new customer request. It is not necessary to process every customer request, thereby avoiding the repeated processing of customer requests that request the same data, thus avoiding the waste of server resources and the problems of increased system response time and reduced user experience caused by repeated processing.
[0098] Optionally, upon receiving a customer request, a judgment unit is added to determine whether a customer request identical to the one already exists in the pendingMap. This unit is specifically used for:
[0099] When a customer request is received, the request parameters are extracted from the new customer request;
[0100] The request parameters are parsed to generate a unique cache key for the new customer request, and it is determined whether there are other customer requests in the pendingMap that have the same cache key as the new customer request.
[0101] If it exists, determine if there are other customer requests in the pendingMap that are identical to the customer request;
[0102] If not, determine that there are no other customer requests identical to the customer request in the pendingMap.
[0103] Optionally, the parameter caching concurrent request management system provided in this application embodiment also includes a deletion unit;
[0104] The deletion unit is used to iterate through the target Promise list after resolving or rejecting the target Promise, and call the function of each target Promise in the target Promise list to delete the corresponding item in the pendingMap; where the target Promise is a Promise or a new Promise, and the target Promise list is a list of Promises or a list of Promises to be processed.
[0105] Optionally, the parameter caching concurrent request management system provided in this application embodiment further includes a rejection unit;
[0106] The rejection unit is used to detect whether an execution error has occurred in the promiseFn function during its execution. If an execution error occurs, the unit captures the error and rejects all Promises in the Promise list.
[0107] This application also provides a storage medium storing program instructions, which, when loaded and executed by a processor, implement any of the above-described parameter cache request concurrency management method embodiments.
[0108] This application also provides an electronic device, such as Figure 6 As shown, the device includes a processor 601 and a memory 602, which are connected via a bus; the memory stores program instructions; the processor calls the program instructions in the memory to execute any of the above-described parameter cache request concurrency management method embodiments.
[0109] The processor mentioned in this article can be the terminal's CPU, an integrated MCU within the terminal, or a combination of a CPU and an MCU. Furthermore, the processor contains a kernel that retrieves the corresponding program from memory; one or more kernels can be configured.
[0110] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.
[0111] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.
[0112] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.
[0113] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
[0114] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.
Claims
1. A method for managing concurrent requests with parameter caching, characterized in that, The method comprises: When a new client request is received, it is determined whether there is another client request identical to the new client request in the pendingMap; If not, a corresponding Promise list is initialized for the new client request in the pendingMap, and the new client request and its associated cache key are stored in the Promise list; wherein the cache key is generated according to the new client request; The promiseFn function is executed to process the new client request, obtain the corresponding execution result, and feed back the execution result to each Promise in the Promise list to resolve or reject the client request corresponding to each Promise; If there is, a new Promise is assigned to the new client request, and the new Promise is added to the pending Promise list corresponding to the new client request; The execution result of the first client request added to the pending Promise list is fed back to the new Promise to resolve or reject the new client request.
2. The method of claim 1, wherein, When a client request is received, it is determined whether there is a client request identical to the client request in the pendingMap, comprising: When a client request is received, extracting request parameters from the new client request; The request parameters are parsed to generate a cache key unique to the new client request, and it is determined whether there is another client request with the same cache key as the new client request in the pendingMap; If there is, it is determined that there is another client request identical to the client request in the pendingMap; If not, it is determined that there is no other client request identical to the client request in the pendingMap.
3. The method of claim 1, wherein, The method further comprises: After resolving or rejecting the target Promise, the target Promise list is traversed to call the function of each target Promise in the target Promise list to delete the corresponding item in the pendingMap; wherein the target Promise is the Promise or the new Promise, and the target Promise list is the Promise list or the pending Promise list.
4. The method of claim 1, wherein, The method further comprises: During execution of the promiseFn function, it is detected in real time whether an execution error of the promiseFn function occurs; If an execution error of the promiseFn function occurs, the execution error of the promiseFn function is captured, and all Promises in the Promise list are rejected.
5. A parameter cache concurrent request management system, characterized by, The system comprises: A judgment unit is configured to determine whether there is another client request identical to the new client request in the pendingMap when a new client request is received. An initialization unit is configured to initialize a corresponding Promise list in the pendingMap for the new client request if the pendingMap does not exist, and store the new client request and its associated cache key to the Promise list, wherein the cache key is generated according to the new client request. An execution and feedback unit is configured to execute the promiseFn function to process the new client request, obtain a corresponding execution result, and feed back the execution result to each Promise in the Promise list to resolve or reject the client request corresponding to each Promise. An allocation unit is configured to allocate a new Promise to the new client request and add the new Promise to the to-be-processed Promise list corresponding to the new client request if the pendingMap exists. A feedback unit is configured to feed back the execution result of the first client request added to the to-be-processed Promise list to the new Promise to resolve or reject the new client request.
6. The system of claim 5, wherein, When receiving a client request, the judging unit judges whether the pendingMap contains a client request identical to the client request, comprising: When receiving a client request, extracting a request parameter from the new client request; Analyzing the request parameter, generating a cache key unique to the new client request, and judging whether the pendingMap contains another client request identical to the cache key of the new client request; If the pendingMap contains another client request identical to the client request, determining that the pendingMap contains another client request identical to the client request; If the pendingMap does not contain another client request identical to the client request, determining that the pendingMap does not contain another client request identical to the client request.
7. The system of claim 5, wherein, The system further comprises a deletion unit; The deletion unit is configured to, after resolving or rejecting a target Promise, traverse the target Promise list to call a function of each target Promise in the target Promise list to delete a corresponding item in the pendingMap, wherein the target Promise is the Promise or the new Promise, and the target Promise list is the Promise list or the to-be-processed Promise list.
8. The system of claim 5, wherein, The system further comprises a rejection unit; The rejection unit is configured to, in the process of executing the promiseFn function, detect whether the promiseFn function has an execution error in real time, capture the execution error of the promiseFn function, and reject all Promises in the Promise list if the promiseFn function has an execution error.
9. An electronic device, comprising: Comprising: A processor and a memory connected through a bus; wherein the processor is configured to call and execute a program stored in the memory. The memory is configured to store a program, and the program is configured to implement the parameter cache concurrent request management method according to any one of claims 1-4.
10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer executable instructions, and the computer executable instructions are configured to execute the parameter cache concurrent request management method according to any one of claims 1-4.