Processing method of repeated request, electronic device, and storage medium
By receiving and processing frontend request information, identifying business types, and employing targeted deduplication methods, the performance issues caused by duplicate requests are resolved, achieving more efficient request control and response optimization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHENZHEN LANYOU TECHNOLOGY CO LTD
- Filing Date
- 2025-09-12
- Publication Date
- 2026-07-28
AI Technical Summary
In front-end development, excessive HTTP requests caused by repeated component calls, frequent user input, and multiple pages repeatedly calling the same interface can negatively impact page performance and user experience.
By receiving request information, the business type is determined, and different strategies are adopted to handle duplicate requests based on the type. These strategies include treating the last request of a query request as a valid request, merging parameters for duplicate component requests, caching page request responses, and reducing invalid requests.
It significantly reduced the number of duplicate requests, optimized performance, and improved user experience and system stability.
Smart Images
Figure CN121125844B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technology, and more specifically, to a method for processing repeated requests, an electronic device, and a storage medium. Background Technology
[0002] Front-end development has far surpassed the simple combination of HyperText Markup Language (HTML), Cascading Style Sheets (CSS), and programming languages (JavaScript, JS), forming a vast and mature technology ecosystem. For example, front-end architecture provides structured solutions and best practices for designing and building front-end applications. As projects grow in scale, modularization and componentization are widely used in the development process, business components are reused across different parts, and performance optimization becomes increasingly important.
[0003] In front-end development, scenarios such as repeated component calls, frequent user input, and multiple pages repeatedly calling the same interface result in a large number of repeated HyperText Transfer Protocol (HTTP) requests, which affect page performance and user experience. Summary of the Invention
[0004] The purpose of this application is to address the shortcomings of the prior art by providing a method, electronic device, and storage medium for handling duplicate requests, thereby reducing duplicate requests, shortening page rendering time, and reducing server load.
[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:
[0006] In a first aspect, embodiments of this application provide a method for processing duplicate requests, the method comprising: receiving request information for multiple requests, wherein the request information includes: a request interface, request parameters, and request time;
[0007] The business type corresponding to the multiple requests is determined based on the request information of the multiple requests, and the business type includes: query request business or non-query request business;
[0008] If the business type is a query request business, the request results of the multiple requests are obtained based on the target strategy, wherein the target strategy is used to indicate that the last request among the multiple requests is a valid request;
[0009] If the business type is a non-query request business, then the request type of the multiple requests is determined according to the request information of the multiple requests, and the request result of the multiple requests is obtained according to the request type. The request type includes: first component duplicate request, second component duplicate request, and page request. The first component duplicate request comes from a component and is a request with the same interface and the same parameters within a short period of time. The second component duplicate request comes from a component and is a request with the same interface but different parameters within a short period of time. The page request comes from a page and is a request with the same interface and the same parameters not within a short period of time.
[0010] Optionally, obtaining the request results of the multiple requests based on the target strategy includes:
[0011] Each request message is added to a preset array library in sequence according to the request time in each request message;
[0012] The request corresponding to the last request information in the preset array library within a preset time period is taken as the target request, and the target request is sent to the server to obtain the request result of the target request, and the request result of the target request is taken as the request result of the multiple requests.
[0013] Optionally, determining the request type of the plurality of requests based on the request information of the plurality of requests includes:
[0014] Based on the request parameters in each of the request information, determine whether the plurality of requests are component requests;
[0015] If so, the request type of the multiple requests is determined based on the request parameters and request time in each of the request information.
[0016] If not, then the request type of the multiple requests is determined to be the page request.
[0017] Optionally, determining the request type of the plurality of requests based on the request parameters and request time in each of the request information includes:
[0018] Determine whether the request parameters are the same for each request;
[0019] If all the request parameters are the same, then each of the requests within a preset time interval is treated as a repeated request of the first component based on the request time of each request.
[0020] If the request parameters are different, then each request within a preset time interval will be treated as a repeated request of the second component based on the request time of each request.
[0021] Optionally, obtaining the request results corresponding to the plurality of requests according to the request type includes:
[0022] If the request type is a repeated request of the first component, then a unique identifier for each request is generated based on the address of the request interface and the request parameters of each request.
[0023] The target request is determined based on the unique identifiers and the preset object library.
[0024] Obtain the request result of the target request, and use the request result of the target request as the request result of each of the plurality of requests.
[0025] Optionally, determining the target request based on each unique identifier and a preset object library includes:
[0026] If the unique identifier exists in the preset object library, then the unique identifier of the request and the return method are added to the preset object library;
[0027] If the unique identifier does not exist in the preset object library, the request is sent to the server as the target request, and the unique identifier of the request and the return method are added to the preset object library.
[0028] Optionally, obtaining the request results of the plurality of requests according to the request type further includes:
[0029] If the request type is a repeated request of the second component, then the request parameters in each of the request information are combined to obtain the combined parameters;
[0030] The combined parameters are sent to the server as the request parameters for the target request;
[0031] Obtain the request result of the target request, and parse the request result of the target request to obtain the request result of each request parameter. The request result includes the request result corresponding to each request parameter.
[0032] Optionally, obtaining the request results of the plurality of requests according to the request type further includes:
[0033] If the request type is a page request, then based on the request parameters and the request interface, determine whether there is a historical request in the cache library that is the same as the request.
[0034] If it exists, the request result of the historical request is obtained from the cache library as the request result of each of the multiple requests;
[0035] If it does not exist, the request is sent to the server as the target request, the request result of the target request is obtained, and the request result is stored in the cache library according to the request interface and request parameters of the request.
[0036] Secondly, embodiments of this application also provide a processing apparatus for duplicate requests, the apparatus comprising:
[0037] The receiving module is used to receive request information from multiple requests, the request information including: request interface, request parameters and request time;
[0038] The determining module is used to determine the business type corresponding to the multiple requests based on the request information of the multiple requests, wherein the business type includes: query request business or non-query request business;
[0039] The acquisition module is used to acquire the request results of the multiple requests based on a target strategy if the business type is a query request business, wherein the target strategy is used to indicate that the last request among the multiple requests is a valid request.
[0040] The determination module is used to determine the request type of the multiple requests based on the request information of the multiple requests if the business type is a non-query request business, and to obtain the request result of the multiple requests based on the request type. The request type includes: a first component duplicate request, a second component duplicate request, and a page request. The first component duplicate request comes from a component and is a request with the same interface and the same parameters within a short period of time. The second component duplicate request comes from a component and is a request with the same interface but different parameters within a short period of time. The page request comes from a page and is a request with the same interface and the same parameters not within a short period of time.
[0041] Optionally, the acquisition module is specifically used for:
[0042] Each request message is added to a preset array library in sequence according to the request time in each request message;
[0043] The request corresponding to the last request information in the preset array library within a preset time period is taken as the target request, and the target request is sent to the server to obtain the request result of the target request, and the request result of the target request is taken as the request result of the multiple requests.
[0044] Optionally, the determining module is specifically used for:
[0045] Based on the request parameters in each of the request information, determine whether the plurality of requests are component requests;
[0046] If so, the request type of the multiple requests is determined based on the request parameters and request time in each of the request information.
[0047] If not, then the request type of the multiple requests is determined to be the page request.
[0048] Optionally, the determining module is specifically used for:
[0049] Determine whether the request parameters are the same for each request;
[0050] If all the request parameters are the same, then each of the requests within a preset time interval is treated as a repeated request of the first component based on the request time of each request.
[0051] If the request parameters are different, then each request within a preset time interval will be treated as a repeated request of the second component based on the request time of each request.
[0052] Optionally, the acquisition module is specifically used for:
[0053] If the request type is a repeated request of the first component, then a unique identifier for each request is generated based on the address of the request interface and the request parameters of each request.
[0054] The target request is determined based on the unique identifiers and the preset object library.
[0055] Obtain the request result of the target request, and use the request result of the target request as the request result of each of the plurality of requests.
[0056] Optionally, the determining module is specifically used for:
[0057] If the unique identifier exists in the preset object library, then the unique identifier of the request and the return method are added to the preset object library;
[0058] If the unique identifier does not exist in the preset object library, the request is sent to the server as the target request, and the unique identifier of the request and the return method are added to the preset object library.
[0059] Optionally, the determining module is specifically used for:
[0060] If the request type is a repeated request of the second component, then the request parameters in each of the request information are combined to obtain the combined parameters;
[0061] The combined parameters are sent to the server as the request parameters for the target request;
[0062] Obtain the request result of the target request, and parse the request result of the target request to obtain the request result of each request parameter. The request result includes the request result corresponding to each request parameter.
[0063] Optionally, the determining module is specifically used for:
[0064] If the request type is a page request, then based on the request parameters and the request interface, determine whether there is a historical request in the cache library that is the same as the request.
[0065] If it exists, the request result of the historical request is obtained from the cache library as the request result of each of the multiple requests;
[0066] If it does not exist, the request is sent to the server as the target request, the request result of the target request is obtained, and the request result is stored in the cache library according to the request interface and request parameters of the request.
[0067] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores program instructions executable by the processor, and when the application runs, the processor communicates with the storage medium via the bus, and the processor executes the program instructions to perform the steps of the recurring request processing method described in the first aspect above.
[0068] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which is read and executes the steps of the duplicate request processing method described in the first aspect.
[0069] The beneficial effects of this application are:
[0070] This application provides a method, apparatus, electronic device, and storage medium for processing duplicate requests. For duplicate requests of the query request business type, the last request among multiple requests is considered the valid request, thus obtaining the results of multiple requests. This is because each change in user input during the query process may trigger a request, resulting in multiple requests in a short period. When the user finishes inputting, the request corresponding to the last input is the user's actual request. Therefore, considering the last request as the valid request significantly reduces the number of requests, avoiding frequent requests from the front end and increasing network load, and eliminating the need for a complete request response operation for each input change. For other requests besides query requests, the request type of each request is determined based on the request information, and a deduplication method is determined based on the request type to obtain the results of multiple requests. By setting targeted request deduplication methods for different types of requests, fine-grained and scenario-differentiated request control can be achieved, thereby maximizing the reduction of invalid requests, optimizing performance, improving user experience, and enhancing system stability in different scenarios of duplicate requests. Attached Figure Description
[0071] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0072] Figure 1 A flowchart illustrating a method for handling duplicate requests provided in an embodiment of this application;
[0073] Figure 2 A flowchart illustrating another method for handling duplicate requests provided in an embodiment of this application;
[0074] Figure 3 A schematic diagram illustrating the process of handling duplicate query requests provided in an embodiment of this application;
[0075] Figure 4 A flowchart illustrating another method for handling duplicate requests provided in an embodiment of this application;
[0076] Figure 5 This is a schematic diagram illustrating the process of handling repeated requests by a component, as provided in this application.
[0077] Figure 6 A flowchart illustrating another method for processing duplicate requests provided in an embodiment of this application;
[0078] Figure 7This is a schematic diagram illustrating another component's process for handling repeated requests, as provided in this application.
[0079] Figure 8 This is a schematic diagram illustrating a process for handling duplicate page requests provided in this application;
[0080] Figure 9 A schematic diagram of an apparatus for processing a duplicate request, provided in an embodiment of this application;
[0081] Figure 10 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0082] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.
[0083] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0084] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.
[0085] Optionally, the method for handling duplicate requests provided in this application embodiment is applied to a request processing unit in an electronic device, such as a mobile phone, tablet computer, laptop computer, PDA, desktop computer, or other terminal device with computing power and display function. Specifically, it can be applied to applications in the terminal device, such as mobile phone applications (APP) and computer application systems.
[0086] The following section will explain in detail the specific implementation process of handling duplicate requests provided in the embodiments of this application.
[0087] Figure 1 This is a flowchart illustrating a method for handling duplicate requests provided in an embodiment of this application. The execution entity of this method is as described above: the request processing unit in the electronic device. Figure 1 As shown, the method includes:
[0088] S101, Receive request information for multiple requests.
[0089] The request information may include: the request interface, request parameters, and request time.
[0090] Optionally, the request can be an HTTP request. An HTTP request is the process by which a client sends data to a server based on the HTTP protocol, and its core function is to transmit resource operation instructions and parameters. These multiple requests can be sent at different times within a very short period of time, or they can be sent at different times within a longer period of time. The request interfaces and request parameters of these multiple requests can be the same or different.
[0091] For example, if the received multiple requests can be: request 1, request 2, request 3 and request 4, where request 1 is a request sent at time t1 for request interface A with request parameter 1; request 2 is a request sent at time t2 for request interface A with request parameter 2; the request information of request 3 is a request sent at time t3 for request interface A with request parameter 4; and the request information of request 4 is a request sent at time t4 for request interface A with request parameter 4.
[0092] S102. Determine the business type corresponding to multiple requests based on the request information of multiple requests.
[0093] This business type can include query request business or non-query request business.
[0094] Specifically, the business type corresponding to each request can be determined based on the request interface in the request information of each request.
[0095] When a user sends a query request—that is, when the user is typing and searching on the request page—multiple API requests will be generated within a short period of time, and each request will have different parameters. The API used to request a request can be used to determine whether it belongs to the query category.
[0096] S103. If the business type is a query request business, then obtain the request results of multiple requests based on the target strategy.
[0097] The target strategy here refers to treating the last request out of multiple requests as the valid request. In other words, for scenarios where users are typing and searching simultaneously, only the last request is valid; requests generated during the intermediate processes are invalid.
[0098] S104. If the business type is a non-query request business, then determine the request type of multiple requests based on the request information of multiple requests, and obtain the request results of multiple requests based on the request type.
[0099] Among them, the first component's repeated requests come from the component, and the first component's repeated requests are requests with the same interface and the same parameters within a short period of time; the second component's repeated requests come from the component, and the second component's repeated requests are requests with the same interface and different parameters within a short period of time; the page requests come from the page, and the page requests are requests with the same interface and the same parameters not within a short period of time.
[0100] A page can include at least one component, through which users can send requests, either directly or through the page itself. Different methods can be used to deduplicate requests of different types, thereby obtaining the request types of multiple requests.
[0101] For duplicate requests in the first component, users can send requests with the same request parameters to the same interface through different components on a page. For example, at time t5, a request for interface A with request parameter 1 is sent through component 1; at time t6, a request for interface A with request parameter 1 is sent through component 2; and at time t7, a request for interface A with request parameter 1 is sent through component 3.
[0102] For duplicate requests in the second component, users can also send requests with different parameters to the same interface through different components on a page. For example, at time t8, a request for interface A with parameter 1 is sent through component 1; at time t9, a request for interface A with parameter 2 is sent through component 2; and at time t10, a request for interface A with parameter 3 is sent through component 3.
[0103] For page requests, users can send requests with the same parameters to the same interface through different pages. For example, at time t11, a request for interface A with parameter 1 is sent through page 1, and at time t12, a request for interface A with parameter 1 is sent through page 2.
[0104] In this embodiment, for duplicate requests of the query request business type, the last request among multiple requests is taken as the valid request, thus obtaining the request results of multiple requests. This is because each change in user input during the query process may trigger a request, resulting in multiple requests in a short period of time. When the user finishes inputting, the request corresponding to the last input is the user's real request. Therefore, taking the last request as the valid request significantly reduces the number of requests, avoiding frequent requests from the front end and increasing network load, and eliminating the need for a complete request response operation for each input change. For other requests that are not query requests, the request type of each request is determined based on the request information, and the deduplication method for multiple requests is determined based on the request type, thereby obtaining the request results of multiple requests. By setting targeted request deduplication methods for different types of requests, fine-grained and scenario-differentiated request control can be achieved, thereby maximizing the reduction of invalid requests in different scenarios of duplicate requests, optimizing performance, improving user experience, and enhancing system stability.
[0105] Figure 2 A flowchart illustrating another method for handling duplicate requests provided in this application embodiment is shown below. Figure 2 As shown, obtaining the request results of multiple requests based on the target strategy in S103 above may include:
[0106] S201. Add each request information to the preset array library in sequence according to the request time in each request information.
[0107] Optionally, in a scenario where input is performed while querying, the user input is a continuously changing process. The request information for each request added to the preset array library consists of the request information for each request generated by the user from the start to the end of the input process.
[0108] For example, if a user enters "abc" in the search box, and initially enters "a", the first request will be initiated after the user enters "a". Then, if the user enters "b", the second request will be initiated when the user enters "ab". Finally, if the user enters "c", the third request will be initiated when the user enters "abc", and the user will end the search after entering "c". The first, second, and third requests can then be added to a preset array library sequentially according to their request time.
[0109] S202. Take the request corresponding to the last request information in the preset array library within the preset time as the target request, send the target request to the server to obtain the request result of the target request, and use the request result of the target request as the request result of multiple requests.
[0110] The preset time refers to the time from the start to the end of a user's input for a single query.
[0111] Specifically, when the user finishes inputting, that is, no new requests are added to the preset array library, the request corresponding to the last request information in the preset array library is taken as the target request, and other requests before the last request are taken as invalid requests.
[0112] For example, if "first request, second request, and third request" are added sequentially to the aforementioned preset array library, and no new request is added after "third request", then "third request" is the last request in the preset array library. The "third request" is then sent to the server as the target request, and the server will return the request result of the "third request", which is the user input "abc", and use the request result of "abc" as the request result of the first request, the second request, and the third request.
[0113] Figure 3 This is a schematic diagram illustrating the process of handling duplicate query requests provided in an embodiment of this application, as shown below. Figure 3 As shown, when a user enters query content on the page, the first request is initiated at 500ms, which is then canceled. The second request is initiated at 1s, which is also canceled. The third request is initiated at 1.5s, which is the last request. The third request is then sent to the server as the target request through the request processing unit, and the server returns the request result of the third request.
[0114] In this embodiment, the strategy of retaining the last request is not simply to use debouncing or throttling techniques, but to combine request type identification and request queue management mechanism to form a structured and configurable request control strategy. When the business type of the request is identified as a query request, a preset array library, i.e. a temporary request queue, is maintained for the query business. Only the last request is retained within a set time window, thereby achieving more intelligent and efficient request control and realizing multi-dimensional optimization such as deduplication, caching, and batch processing.
[0115] Optionally, S102 above, determining the service type corresponding to multiple requests based on the request information of multiple requests, may include:
[0116] Specifically, the request parameters in each request message can be used to determine whether multiple requests are component requests. A page request refers to a user requesting a complete page, usually initiated by the browser, triggering the loading of the entire page. For example, when a user enters "http: / / example.com / home" in the browser address bar, the browser requests the " / home" page from the server. A component request refers to a request for the content of a specific component or module within a page, used to dynamically load or update parts of the page. For example, in a single-page application, clicking a button can request data or a rendering template for a specific component.
[0117] Specifically, the request parameters in a component request differ from those in a page request. Component requests carry specific parameters, and their presence can be used to determine if a request is a component request. Other methods can also be used to determine if a request is a component request, such as using request headers, request paths, or other methods; no restrictions are placed here.
[0118] If multiple requests are component requests, their request types are determined based on the request parameters and request times in each request information. If multiple requests are not component requests, their request types are determined to be page requests.
[0119] Optionally, determining the request type of multiple requests based on the request parameters and request time in each request information may include:
[0120] Determine if all request parameters are the same. If all request parameters are the same, then each request within a preset time interval is treated as a first component and repeated as a second component, based on the request time of each request. If all request parameters are different, then each request within a preset time interval is treated as a second component and repeated as a second component, based on the request time of each request.
[0121] Figure 4 A flowchart illustrating another method for handling duplicate requests provided in this application embodiment is shown below. Figure 4 As shown, obtaining the request results corresponding to multiple requests based on the request type can include:
[0122] S301. If the request type is a repeated request for the first component, then generate a unique identifier for each request based on the address of the request interface and the request parameters.
[0123] The unique identifier is composed of the address of the requested interface and the request parameters.
[0124] Specifically, if it is determined that the request interfaces and request parameters of the multiple requests are all the same, then the request interface addresses and request parameters of each request are combined into a unique identifier for that request.
[0125] S302. Determine the target request based on each unique identifier and the preset object library.
[0126] The preset object library can maintain a unique identifier for each request within a preset time interval.
[0127] Specifically, when a request from a component is received, a unique identifier is generated for that component's request. The system then checks if this unique identifier exists in a pre-defined object library. If it exists, it means the same request is already being processed, and the request is not reissued; instead, the asynchronous return method of that request is added to the unique identifier of that request. If the unique identifier of that request does not exist in the pre-defined object library, the request is treated as the target request, and the request is sent to the server. The unique identifier containing the asynchronous return method of that request is also added to the pre-defined object library.
[0128] S303. Obtain the request result of the target request and use the request result of the target request as the request result of each request in the multiple requests.
[0129] Optionally, after the request processing unit receives the request result of the target request returned by the server, it checks the return methods of each request in the preset object library after a preset time interval. If there are multiple return methods, it means that multiple components are waiting for the request result of the target request. Then, the request result of the target request is used as the request result of each of the multiple requests.
[0130] like Figure 5 As shown, Figure 5 This is a schematic diagram illustrating a component's process for handling repeated requests, as provided in this application. Figure 5 As shown, if the request processing unit receives a request from component 1 and determines from the preset object library that there is no unique identifier for component 1, then it sends the request from component 1 to the server. The server returns the request result of component 1. If a request from component 2 is received within a preset time interval, and the request interface and request parameters of component 2 are the same as those of component 1, and a unique identifier identical to that of component 2 is found in the preset object library, then the request from component 2 is a duplicate request of the request from component 1, and the request from component 2 is not initiated. Similarly, the request from component 3 is also a duplicate request of the request from component 1, so the request from component 3 is not sent. After the preset time interval, the request result of component 1 is returned to component 2 and component 3 as the request result of component 2 and component 3, respectively.
[0131] In this embodiment, a preset object library is maintained, and duplicate requests are identified and intercepted within a certain period of time based on the unique identifier of the interface address and request parameters. No external system is required, making it suitable for performance-sensitive scenarios. It also features fast response speed, almost no delay, simple implementation, and easy maintenance, enabling the filtering of duplicate requests within a short period of time.
[0132] Optionally, the above determination of the target request based on each unique identifier and a preset object library includes:
[0133] If the unique identifier exists in the preset object library, then the unique identifier of the request and the return method will be added to the preset object library.
[0134] If the unique identifier does not exist in the preset object library, the request will be sent to the server as the target request, and the unique identifier of the request and the return method will be added to the preset object library.
[0135] Figure 6 A flowchart illustrating another method for handling duplicate requests provided in this application embodiment is shown below. Figure 6 As shown, the above method of obtaining request results corresponding to multiple requests based on request type may also include:
[0136] S401. If the request type is a repeat request for the second component, the request parameters in each request information are combined to obtain the combined parameters.
[0137] Because the client sends a large number of requests to the backend interface, if multiple components request the same interface, each request has different parameters, and these multiple requests are received within a very short period of time, it would be wasteful of resources to execute a database query or calculation task separately for each request. Therefore, the request processing unit first intercepts these multiple requests, combines the different request parameters of these requests according to preset rules, and obtains the combined parameters, which include the request parameters of each of the multiple requests.
[0138] S402. Send the combined parameters to the server as the request parameters for the target request.
[0139] Specifically, since the request interfaces of the multiple requests are the same, the request interface of the target request is also the request interface of all the other requests, and the request parameters of the target request are the combined parameters. Therefore, only one request is sent to the server.
[0140] S403. Obtain the request result of the target request, and parse the request result of the target request to obtain the request result of each request parameter.
[0141] The request result includes the request result corresponding to each request parameter.
[0142] Specifically, upon receiving the result of the target request, since the target request result is a batch result set—meaning it contains the results of multiple requests—the result is parsed to obtain the request results for each request's parameters. Then, the request results for each parameter are returned to the request corresponding to that parameter. For example, such as... Figure 7 As shown, Figure 7 This is a schematic diagram illustrating another component's process for handling repeated requests, as provided in this application.
[0143] In this embodiment, multiple requests with the same interface parameters but different parameters are merged and processed into a single request, which can significantly reduce the pressure on database access. Furthermore, batch processing can avoid concurrency conflicts.
[0144] Optionally, the above-mentioned method of obtaining request results corresponding to multiple requests based on request type may further include:
[0145] If the request type is a page request, then based on the request parameters and the request interface, determine whether there is a historical request in the cache that is the same as the request.
[0146] If a historical request identical to this request exists in the cache, the result of the historical request is retrieved from the cache as the result of multiple requests.
[0147] If no historical request identical to the previous request exists in the cache, the previous request is sent to the server as the target request, the result of the target request is obtained, and the result is stored in the cache according to the request interface and request parameters.
[0148] For example Figure 8 As shown, for request interface 1 and request parameter 1, when page 1 is loaded for the first time and requests request interface 1 and request parameter 1, if the cache does not contain the request for request interface 1 and request parameter 1, then the request for page 1 is sent to the server, the request result is obtained, and the request result is cached in the cache. The cache key consists of request interface 1 and request parameter 1. If page 2 and page 3 are requests for interface 1 and request parameter 1 initiated after page 1, then the request result of page 1 is obtained from the cache as the request result of page 2 and the request result of page 3, respectively.
[0149] In this embodiment, the response results of repeated page requests are cached to avoid accessing the database or server with each page request, thereby improving response speed and reducing resource consumption.
[0150] Figure 9 A schematic diagram of an apparatus for processing a duplicate request, provided in an embodiment of this application, is shown below. Figure 9 As shown, the device includes:
[0151] The receiving module 501 is used to receive request information for multiple requests, wherein the request information includes: request interface, request parameters and request time;
[0152] The determining module 502 is used to determine the service type corresponding to the multiple requests based on the request information of the multiple requests, wherein the service type includes: query request service or non-query request service;
[0153] The acquisition module 503 is used to acquire the request results of the multiple requests based on a target strategy if the business type is a query request business, wherein the target strategy is used to indicate that the last request among the multiple requests is a valid request.
[0154] The determining module 502 is used to determine the request type of the multiple requests based on the request information of the multiple requests if the business type is a non-query request business, and to obtain the request result of the multiple requests based on the request type. The request type includes: a first component duplicate request, a second component duplicate request, and a page request. The first component duplicate request comes from a component and is a request with the same interface and the same parameters within a short period of time. The second component duplicate request comes from a component and is a request with the same interface but different parameters within a short period of time. The page request comes from a page and is a request with the same interface and the same parameters not within a short period of time.
[0155] Optionally, the acquisition module 503 is specifically used for:
[0156] Each request message is added to a preset array library in sequence according to the request time in each request message;
[0157] The request corresponding to the last request information in the preset array library within a preset time period is taken as the target request, and the target request is sent to the server to obtain the request result of the target request, and the request result of the target request is taken as the request result of the multiple requests.
[0158] Optionally, the determining module 502 is specifically used for:
[0159] Based on the request parameters in each of the request information, determine whether the plurality of requests are component requests;
[0160] If so, the request type of the multiple requests is determined based on the request parameters and request time in each of the request information.
[0161] If not, then the request type of the multiple requests is determined to be the page request.
[0162] Optionally, the determining module 502 is specifically used for:
[0163] Determine whether the request parameters are the same for each request;
[0164] If all the request parameters are the same, then each of the requests within a preset time interval is treated as a repeated request of the first component based on the request time of each request.
[0165] If the request parameters are different, then each request within a preset time interval will be treated as a repeated request of the second component based on the request time of each request.
[0166] Optionally, the acquisition module 503 is specifically used for:
[0167] If the request type is a repeated request of the first component, then a unique identifier for each request is generated based on the address of the request interface and the request parameters of each request.
[0168] The target request is determined based on the unique identifiers and the preset object library.
[0169] Obtain the request result of the target request, and use the request result of the target request as the request result of each of the plurality of requests.
[0170] Optionally, the determining module 502 is specifically used for:
[0171] If the unique identifier exists in the preset object library, then the unique identifier of the request and the return method are added to the preset object library;
[0172] If the unique identifier does not exist in the preset object library, the request is sent to the server as the target request, and the unique identifier of the request and the return method are added to the preset object library.
[0173] Optionally, the determining module 502 is specifically used for:
[0174] If the request type is a repeated request of the second component, then the request parameters in each of the request information are combined to obtain the combined parameters;
[0175] The combined parameters are sent to the server as the request parameters for the target request;
[0176] Obtain the request result of the target request, and parse the request result of the target request to obtain the request result of each request parameter. The request result includes the request result corresponding to each request parameter.
[0177] Optionally, the determining module 502 is specifically used for:
[0178] If the request type is a page request, then based on the request parameters and the request interface, determine whether there is a historical request in the cache library that is the same as the request.
[0179] If it exists, the request result of the historical request is obtained from the cache library as the request result of each of the multiple requests;
[0180] If it does not exist, the request is sent to the server as the target request, the request result of the target request is obtained, and the request result is stored in the cache library according to the request interface and request parameters of the request.
[0181] Figure 10 This is a structural block diagram of an electronic device 600 provided in an embodiment of this application. This electronic device can, for example, be the request processing unit described in the foregoing embodiments. Figure 10 As shown, the electronic device may include: a processor 601 and a memory 602.
[0182] Optionally, a bus 603 may also be included, wherein the memory 602 is used to store machine-readable instructions executable by the processor 601. When the electronic device 600 is running, the processor 601 and the memory 602 communicate via the bus 603. When the machine-readable instructions are executed by the processor 601, the method steps in the above method embodiments are performed.
[0183] This application also provides a computer-readable storage medium storing a computer program, which, when run by a processor, executes the method steps in the above-described embodiments of the method for processing repeated requests.
[0184] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.
[0185] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. If the functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.
[0186] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.
Claims
1. A method for handling duplicate requests, characterized in that, The method includes: Receive request information for multiple requests, the request information including: request interface, request parameters, and request time; The business type corresponding to the multiple requests is determined based on the request information of the multiple requests, and the business type includes: query request business or non-query request business; If the business type is a query request business, the request results of the multiple requests are obtained based on the target strategy, wherein the target strategy is used to indicate that the last request among the multiple requests is a valid request; If the business type is a non-query request business, then the request type of the multiple requests is determined according to the request information of the multiple requests, and the request result of the multiple requests is obtained according to the request type. The request type includes: first component duplicate request, second component duplicate request, and page request. The first component duplicate request comes from a component and is a request with the same interface and the same parameters within a short period of time. The second component duplicate request comes from a component and is a request with the same interface but different parameters within a short period of time. The page request comes from a page and is a request with the same interface and the same parameters not within a short period of time.
2. The method for processing duplicate requests according to claim 1, characterized in that, The step of obtaining the request results of the multiple requests based on the target strategy includes: Each request message is added to a preset array library in sequence according to the request time in each request message; The request corresponding to the last request information in the preset array library within a preset time period is taken as the target request, and the target request is sent to the server to obtain the request result of the target request, and the request result of the target request is taken as the request result of the multiple requests.
3. The method for processing duplicate requests according to claim 1, characterized in that, Determining the request type of the multiple requests based on the request information of the multiple requests includes: Based on the request parameters in each of the request information, determine whether the plurality of requests are component requests; If so, the request type of the multiple requests is determined based on the request parameters and request time in each of the request information. If not, then the request type of the multiple requests is determined to be the page request.
4. The method for processing duplicate requests according to claim 3, characterized in that, Determining the request type of the multiple requests based on the request parameters and request time in each of the request information includes: Determine whether the request parameters are the same for each request; If all the request parameters are the same, then each of the requests within a preset time interval is treated as a repeated request of the first component based on the request time of each request. If the request parameters are different, then each request within a preset time interval will be treated as a repeated request of the second component based on the request time of each request.
5. The method for processing duplicate requests according to claim 1, characterized in that, The step of obtaining the request results corresponding to the multiple requests according to the request type includes: If the request type is a repeated request of the first component, then a unique identifier for each request is generated based on the address of the request interface and the request parameters of each request. The target request is determined based on the unique identifiers and the preset object library. Obtain the request result of the target request, and use the request result of the target request as the request result of each of the plurality of requests.
6. The method for processing duplicate requests according to claim 5, characterized in that, The step of determining the target request based on each unique identifier and a preset object library includes: If the unique identifier exists in the preset object library, then the unique identifier of the request and the return method are added to the preset object library; If the unique identifier does not exist in the preset object library, the request is sent to the server as the target request, and the unique identifier of the request and the return method are added to the preset object library.
7. The method for processing duplicate requests according to claim 1, characterized in that, The step of obtaining the request results of the multiple requests according to the request type further includes: If the request type is a repeated request of the second component, then the request parameters in each of the request information are combined to obtain the combined parameters; The combined parameters are sent to the server as the request parameters for the target request; Obtain the request result of the target request, and parse the request result of the target request to obtain the request result of each request parameter. The request result includes the request result corresponding to each request parameter.
8. The method for processing duplicate requests according to claim 1, characterized in that, The step of obtaining the request results of the multiple requests according to the request type further includes: If the request type is a page request, then based on the request parameters and the request interface, determine whether there is a historical request in the cache library that is the same as the request. If it exists, the request result of the historical request is obtained from the cache library as the request result of each of the multiple requests; If it does not exist, the request is sent to the server as the target request, the request result of the target request is obtained, and the request result is stored in the cache library according to the request interface and request parameters of the request.
9. An electronic device, characterized in that, The device includes a memory and a processor, the memory storing a computer program executable by the processor, wherein the processor executes the computer program to implement the steps of the method for processing repeated requests as described in any one of claims 1-8.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the method for processing repeated requests as described in any one of claims 1-8.