Request result unloading method and device, storage medium and electronic equipment

By receiving task requests and using a caching module to handle timeout tasks, the system instability caused by backend timeouts is resolved, achieving efficient backend response and resource conservation.

CN120803769APending Publication Date: 2025-10-17小芒电子商务有限责任公司
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510976094.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-07-15
Publication Date
2025-10-17

AI Technical Summary

Technical Problem

Existing technologies typically require modifications to Nginx configuration or code when backend processing times out, leading to low efficiency and system instability.

Method used

By receiving task requests, estimating processing time and memory usage, using the caching module to handle timeout tasks, and sending polling instructions to the front end until the task is completed, the result data is stored in the caching module.

Benefits of technology

Without modifying the original business logic code, it efficiently handles backend timeout responses, reduces system and cache pressure, maintains system stability, and saves resources.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120803769A_ABST
    Figure CN120803769A_ABST
Patent Text Reader

Abstract

The invention provides a request result unloading method and device, a storage medium and electronic equipment, and relates to the technical field of computers.The method comprises the steps that a task request sent by a front end is received; determining an estimated processing duration and an estimated memory occupied space of the task request; under the condition that the estimated processing duration is greater than a duration threshold and the estimated memory occupation space is not greater than a memory occupation threshold, processing a request parameter of the task request; under the condition that a result request corresponding to the task request sent by the front end is received, if the task request is not processed, polling indication information is sent to the front end, and the polling indication information is used for indicating the front end to query result data corresponding to the task request from the cache module according to polling interval time; and under the condition that the task request is processed, storing result data of the task request into the cache module. By applying the method provided by the embodiment of the invention, the back-end timeout response can be efficiently realized.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a request result storing method and device, storage medium and electronic equipment. BACKGROUND

[0002] Under the synchronous web framework, the front end sends a task request to the back end, the back end processes the task request, returns a response after processing is completed, and closes the connection between the front end and the back end, and the front end cannot respond if the back end processing time exceeds.

[0003] Currently, for the case of back end processing timeout, the timeout time is generally increased by modifying the Nginx configuration, or a large amount of code modification is required to realize the transformation of the view function by referring to a third-party library, which is low in work efficiency, consumes a large amount of resources, and easily leads to system instability. SUMMARY

[0004] The technical problem to be solved by the present application is to provide a request result storing method, device, storage medium and electronic equipment, which can efficiently realize the back end timeout response. The specific scheme is as follows:

[0005] A request result storing method, comprising:

[0006] receiving a task request sent by a front end;

[0007] determining an estimated processing duration and an estimated memory occupation space of the task request;

[0008] in a case where the estimated processing duration is greater than a duration threshold and the estimated memory occupation space is not greater than a memory occupation threshold, creating a cache in a cache module according to a task identifier in the task request, and processing request parameters of the task request; the memory occupation threshold is determined based on available memory of the cache module;

[0009] in a case where a result request corresponding to the task request sent by the front end is received, if the task request is not processed completely, sending polling indication information to the front end, the polling indication information comprising a polling interval time, and the polling indication information being used to instruct the front end to query result data corresponding to the task request from the cache module at the polling interval time;

[0010] in a case where the task request is processed completely, storing result data of the task request to the cache module according to the task identifier.

[0011] The above method can optionally determine the estimated processing duration of the task request according to the request parameters, and the process comprises:

[0012] acquire a historical average processing duration and a historical request success rate;

[0013] According to the number of request parameters, the historical average processing duration and the historical request success rate, an estimated processing duration of the task request is calculated.

[0014] The method can further include:

[0015] In a case where the estimated processing duration is greater than a duration threshold and the estimated memory occupation space is greater than a memory occupation threshold, the request parameters of the task request are split, and the split request parameters are processed.

[0016] The method can further include:

[0017] According to the number of request parameters, a preset single maximum memory occupation and a preset safety value, a split number of the request parameters is calculated;

[0018] According to the split number, the request parameters of the task request are split.

[0019] The method can further include:

[0020] According to the estimated processing duration and an already waited time corresponding to the task request, a polling interval time of the front end is determined;

[0021] According to the polling interval time, a polling prompt information is generated;

[0022] The polling prompt information is sent to the front end.

[0023] A request result storing device includes:

[0024] A receiving unit is configured to receive a task request sent by a front end;

[0025] A determining unit is configured to determine an estimated processing duration and an estimated memory occupation space of the task request;

[0026] A first executing unit is configured to, in a case where the estimated processing duration is greater than a duration threshold and the estimated memory occupation space is not greater than a memory occupation threshold, create a cache in a cache module according to a task identifier in the task request, and process request parameters of the task request; the memory occupation threshold is determined based on available memory of the cache module;

[0027] The sending unit is configured to, if the task request is not processed completely, send polling indication information to the front end when receiving a result request corresponding to the task request sent by the front end, the polling indication information including a polling interval time, and the polling indication information being used to instruct the front end to query the result data corresponding to the task request from the cache module at the polling interval time.

[0028] The second execution unit is configured to, if the task request is processed completely, store the result data of the task request into the cache module according to a task identifier.

[0029] The device described above, optionally, the determination unit comprises:

[0030] The obtaining sub-unit is configured to obtain a historical average processing time length and a historical request success rate.

[0031] The calculation sub-unit is configured to calculate the estimated processing time length of the task request according to the number of request parameters, the historical average processing time length and the historical request success rate.

[0032] The device described above, optionally, further comprises:

[0033] The splitting unit is configured to, if the estimated processing time length is greater than a time length threshold value and the estimated memory occupation space is greater than a memory occupation threshold value, split the request parameters of the task request, and process the split request parameters.

[0034] A storage medium comprises stored instructions, wherein the instructions, when executed, control a device in which the storage medium is located to perform the request result storing method described above.

[0035] An electronic device comprises a memory and one or more instructions, wherein the one or more instructions are stored in the memory and are configured to be executed by one or more processors to perform the request result storing method described above.

[0036] The application provides a request result storing method, device, storage medium and electronic device, the method comprising: receiving a task request sent by a front end;

[0037] Determining an estimated processing time length and an estimated memory occupation space of the task request;

[0038] In a case where the estimated processing duration is greater than a duration threshold and the estimated memory occupation space is not greater than a memory occupation threshold, a cache is created in a cache module according to a task identifier in the task request, and a request parameter of the task request is processed; the memory occupation threshold is determined based on available memory of the cache module; in a case where a result request corresponding to the task request is received from the front end, if the task request is not processed completely, polling indication information is sent to the front end, the polling indication information including a polling interval time, and the polling indication information is used to instruct the front end to query result data corresponding to the task request from the cache module at the polling interval time; in a case where the task request is processed completely, result data of the task request is stored into the cache module according to the task identifier. By using the method provided in the application, backend timeout response can be efficiently realized without modifying original business logic code, system pressure and cache pressure can be reduced, system running stability can be maintained, and resources can be saved. BRIEF DESCRIPTION OF DRAWINGS

[0039] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are only embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of the provided drawings.

[0040] Figure 1 A method flowchart of a request result storing method provided by the present application;

[0041] Figure 2 A process flowchart of determining an estimated processing duration of a task request provided by the present application;

[0042] Figure 3 A request processing process flowchart provided by the present application;

[0043] Figure 4 Another request processing process flowchart provided by the present application;

[0044] Figure 5 A structural schematic diagram of a request result storing device provided by the present application;

[0045] Figure 6 A structural schematic diagram of an electronic device provided by the present application. DETAILED DESCRIPTION

[0046] With reference to the drawings of the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments of the present application. Based on the embodiments of the present application, all the other embodiments obtained by a person of ordinary skill in the art without creative effort are within the scope of the present application.

[0047] In the present application, the term “comprising” or “including” or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such a process, method, article or device. Without more limitations, the element defined by the sentence “including a…” does not exclude the presence of other identical elements in the process, method, article or device including the element.

[0048] At present, for the case of backend processing timeout, the timeout time is generally increased by modifying the Nginx configuration, or a large amount of code modification is required to modify the view function by referring to a third-party library, which is low in work efficiency, consumes a large amount of resources, and is easy to cause system instability.

[0049] Based on this, the embodiment of the present application provides a request result storing method, which can be applied to an electronic device, which can be a smart phone, a tablet device, a smart wearable device, etc. The method flowchart of the method is as shown in Figure 1 The specific steps are as follows:

[0050] S101: receiving a task request sent by a front end.

[0051] In the embodiment, a task request carrying a task identifier sent by the front end can be received, the task identifier is generated by the front end based on a universally unique identifier (UUID) and attached to an original business interface route; the task request contains a user identity and a request parameter to be processed. In some embodiments, the task request can include a split processing identifier.

[0052] Optionally, the front end triggers UUID generation and parameter dynamic attachment based on user operation, and sends a task request containing a task identifier and a user identity and a split identifier to the original business route; after receiving the task request, the back end extracts the task identifier and the user identity by analyzing the URL parameter.

[0053] S102: determining an estimated processing time and an estimated memory occupation space of the task request.

[0054] In the embodiment, the estimated processing duration can be determined based on the historical average processing duration, the historical request success rate and the current number of processing parameters in the historical request record database.

[0055] Optionally, the estimated memory occupation space can be calculated based on the historical single average memory occupation, the current number of parameters and a memory correction factor.

[0056] In an embodiment provided by the present application, based on the above process, the process of determining the estimated processing duration of the task request according to the request parameters, as shown in Figure 2 , includes the following steps.

[0057] S201: Obtain the historical average processing duration and the historical request success rate.

[0058] In the embodiment, the historical average processing duration, the routing address, the total number of requests, the number of failures, the average memory occupation size and the single maximum memory occupation are stored in the record database, and the historical average processing duration, the total number of requests and the number of failures can be obtained from the record database. The historical request success rate is calculated based on the total number of requests and the number of failures.

[0059] S202: Calculate the estimated processing duration of the task request according to the number of request parameters, the historical average processing duration and the historical request success rate.

[0060] Optionally, the estimated processing duration TTL of the task request is calculated in the following manner:

[0061] TTL

[0062] Wherein, T represents the average request processing duration, is a delay weight coefficient, E represents the request success rate, is an error tolerance coefficient, N is the number of processing parameters, and γ is a load coefficient, which can avoid linear growth.

[0063] In the embodiment, the estimated memory occupation space is calculated in the following manner:

[0064]

[0065] Wherein, N represents the number of request parameters to be processed in the task request, R represents the average memory occupation size, represents a function of the correction factor increasing with N.

[0066] S103: in the case that the estimated processing duration is greater than the duration threshold and the estimated memory occupation space is not greater than the memory occupation threshold, creating a cache in the cache module according to the task identifier in the task request and processing the request parameter of the task request; the memory occupation threshold is determined based on the available memory of the cache module.

[0067] In the embodiment, the memory occupation threshold is generated according to the real-time available memory capacity of the preset cache module multiplied by a safety factor.

[0068] Optionally, the estimated processing duration can be compared with the duration threshold, in the case that the estimated processing duration is greater than the duration threshold, the estimated memory occupation space is compared with the memory occupation threshold, in the case that the estimated memory occupation space is not greater than the memory occupation threshold, the request parameter of the task request is processed, and the cache is created in the cache module according to the task identifier.

[0069] Optionally, in the case that the estimated processing duration is not greater than the duration threshold, the request parameter of the task request can be directly processed.

[0070] In some embodiments, the duration threshold can be dynamically adjusted by a sliding window algorithm based on the historical request success rate and the real-time load state of the system.

[0071] S104: in the case that the result request corresponding to the task request sent by the front end is received, if the task request is not processed completely, sending a polling indication information to the front end, the polling indication information including a polling interval time, the polling indication information being used for instructing the front end to query the result data corresponding to the task request from the cache module according to the polling interval time.

[0072] In the embodiment, the front end can send a result request to the back end according to a preset time interval to query the result data of the task request.

[0073] Optionally, the task identifier is protected in the result request.

[0074] In the embodiment, the polling interval time corresponding to the task request can be determined according to the estimated processing duration.

[0075] S105: in the case that the task request is processed completely, storing the result data of the task request into the cache module according to the task identifier.

[0076] In the embodiment, the result data of the task request is stored in the cache corresponding to the task identifier, so that the front end can query the result data in the cache module.

[0077] By using the method provided in the embodiments of the present application, the backend timeout response can be efficiently realized without modifying the original service logic code, system pressure and cache pressure can be reduced, system running stability can be maintained, and resources can be saved.

[0078] In an embodiment provided in the present application, based on the above process, optionally, the method further comprises:

[0079] In the case that the estimated processing duration is greater than the duration threshold and the estimated memory occupation space is greater than the memory occupation threshold, the request parameters of the task request are split, and the split request parameters are processed.

[0080] In the present embodiment, after the request parameters of the task request are split, the cache can be established according to the task identifier, and the split request parameters are processed.

[0081] In an embodiment provided in the present application, based on the above process, optionally, the splitting of the request parameters of the task request comprises:

[0082] The split quantity of the request parameters is calculated according to the quantity of the request parameters, the preset maximum single memory occupation and a preset safety value;

[0083] The request parameters of the task request are split according to the split quantity.

[0084] In the present embodiment, the split quantity of the request parameters is calculated as follows:

[0085]

[0086] In the present embodiment, the safety value can be set according to actual needs.

[0087] In an embodiment provided in the present application, based on the above process, optionally, the sending of the polling indication information to the front end comprises:

[0088] The polling interval time of the front end is determined according to the estimated processing duration and the waiting time corresponding to the task request;

[0089] The polling prompt information is generated according to the polling interval time;

[0090] The polling indication information is sent to the front end.

[0091] In the present embodiment, the polling interval time of the front end can be determined according to the estimated processing duration and the waiting time corresponding to the task request.

[0092] Optionally, the polling interval time is calculated as follows:

[0093]

[0094] wherein, The minimum interval, such as 1s, can prevent DDOS and invalid requests, and the minimum time interval can be determined according to the estimated processing time, The maximum interval, such as 20s, ensures user experience. The weight coefficient is, Indicates the waiting time. The front end polls the calling through the returned polling interval time, reduces invalid requests and relieves server pressure, and returns the result to the user after the front end gets the result.

[0095] Referring to Figure 3 A flowchart of a request processing process provided in the present application, wherein the front end creates a task ID using UUID, and appends the task ID to the original route as a parameter when requesting. After the backend route reaches the corresponding view function, the corresponding task ID is received, the estimated return time of this request is calculated through the weight and multiple dimensions, to judge whether to go through the cache module, and the uniqueness is ensured through the task ID and user ID, and is used as the key, and the estimated occupied memory size is used to judge whether to go through the split request module. After confirming that this request may be timed out, the result is stored in the result cache module after the original view function is processed. The front end requests the original route, and if it is not timed out, the original route result is continuously obtained, and if it is timed out, the task ID is used to call the result storage route general api interface, the polling interval time is obtained, and the result storage route is requested according to the obtained polling interval time to obtain the corresponding result.

[0096] In the embodiment, the front end can send a task request to the back end, the task request carrying a task identifier, the back end can detect whether the split processing identifier exists in the task request, if not, determine the estimated processing time length of the task request, in the case where the estimated processing time length is greater than the time length threshold, determine the estimated memory occupation space, in the case where the estimated memory occupation space is not greater than the memory occupation threshold, create a cache in the cache module according to the task identifier in the task request, and process the request parameters of the task request. In the case where the result request corresponding to the task request sent by the front end is received, if the task request is not processed completely, a polling indication information is sent to the front end, the polling indication information including a polling interval time, so that the front end queries the result data from the cache module according to the polling indication information; in the case where the back end processes the task request completely, the result data of the task request is stored into the cache module according to the task identifier. In the case where the estimated processing time length is greater than the time length threshold, and the estimated memory occupation space is greater than the memory occupation threshold, the request parameters of the task request are split, and the split request parameters are processed. Specifically, the original request parameters can be split, the identifier can be written on the original request parameters, and the original route can be called again. The original route reads the identifier and directly stores the result into the cache queue, which is convenient for reading. The method can effectively reduce the system memory pressure and cache pressure of the request, reduce the memory / caching expenditure of about 20% at a time, and ensure the stability of the system.

[0097] Referring to Figure 4 Another flowchart of a request processing process provided by the embodiment of the application is provided, and the specific implementation steps are as follows:

[0098] Step one: when a user operates, the front end generates a task ID through UUID.

[0099] Step two: after the front end obtains the task ID in step one, the front end continues to request the original business interface route to append the parameter g_task_id=task ID. The parameter name is only for example.

[0100] Step three: the original business interface route accepts the request signal in step two, judges whether the split identifier data exists, if the identifier data exists, directly enters step five, if the identifier data does not exist, the corresponding view function will first call the request time length estimation module to calculate the estimated time length of the request, if the estimated time length exceeds the timeout threshold, needs to enter the cache module, if the estimated time length does not exceed the timeout threshold, normally returns and ends the request.

[0101] Step four: the memory estimation module is called, and it is checked whether the memory occupied by the request exceeds the threshold, if the memory exceeds the threshold, the execution is discarded, the request parameters in step two are split according to the algorithm and are marked with an identifier, the original business route interface is called in turn using the split request parameters, and step three is re-executed.

[0102] Step five: after receiving the call in step three, the cache module generates a unique key as the KEY setting cache through the task ID and user ID, calculates the front-end polling interval time through the estimated request length, and stores the value {'status': 201,'msg': 'executing', 'data': {'interval: 20}}. The purpose of the value is to identify the start of the response processing.

[0103] Step six: the view function continues to execute the original service business logic, database interaction and data processing in step three, and then calls the cache module to store the result data again after the execution is completed, and saves the parameter quantity, processing time, route address, execution state, and occupied memory size of this time, and updates the average processing time, route address, request total quantity, failure quantity, average occupied memory size, and single maximum occupied memory size in the request record database.

[0104] Step seven: the front-end calls the general result storage routing API interface, and the interface returns non-existent. If the 201 result is obtained, the returned result of step three is discarded directly, and the task ID and the obtained polling interval time are used to poll the result storage routing module again.

[0105] Step eight: the result storage routing module reads the corresponding value in the cache module to give the user the corresponding result data after receiving the request signal in step seven.

[0106] By applying the method provided in the application, the original business interface view function does not need to be modified too much, and only needs to call the encapsulated memory estimation, request length estimation and cache module to take effect, without changing the overall business logic for adaptation, and can automatically optimize the system memory and cache pressure, improve the system stability, and the front-end only needs to be simply adapted to realize the asynchronous request, greatly reduce the development cost and maintenance cost.

[0107] Corresponding to the method of Figure 1 , the application also provides a request result storage device for the specific implementation of the method in Figure 1 , a structure diagram is shown in Figure 5 , which comprises:

[0108] The receiving unit 501 is configured to receive the task request sent by the front-end.

[0109] The determining unit 502 is configured to determine the estimated processing time and the estimated memory occupation space of the task request.

[0110] The first execution unit 503 is configured to, when the estimated processing duration is greater than the duration threshold and the estimated memory occupation space is not greater than the memory occupation threshold, create a cache according to a task identifier in the task request in a cache module, and process request parameters of the task request, wherein the memory occupation threshold is determined based on available memory of the cache module.

[0111] The sending unit 504 is configured to, when receiving a result request corresponding to the task request sent by the front end, if the processing of the task request is not completed, send polling indication information to the front end, the polling indication information including a polling interval time, and the polling indication information being used to instruct the front end to query result data corresponding to the task request from the cache module at the polling interval time.

[0112] The second execution unit 505 is configured to, when the processing of the task request is completed, store result data of the task request into the cache module according to the task identifier.

[0113] In an embodiment provided in the present application, based on the above scheme, optionally, the determining unit comprises:

[0114] The obtaining sub-unit is configured to obtain a historical average processing duration and a historical request success rate.

[0115] The calculating sub-unit is configured to calculate the estimated processing duration of the task request according to the number of request parameters, the historical average processing duration and the historical request success rate.

[0116] In an embodiment provided in the present application, based on the above scheme, optionally, the method further comprises:

[0117] The splitting unit is configured to, when the estimated processing duration is greater than the duration threshold and the estimated memory occupation space is greater than the memory occupation threshold, split the request parameters of the task request, and process the split request parameters.

[0118] In an embodiment provided in the present application, based on the above scheme, optionally, the splitting unit comprises:

[0119] The calculating sub-unit is configured to calculate the split number of the request parameters according to the number of request parameters, a preset single maximum occupation memory and a preset safety value.

[0120] The splitting sub-unit is configured to split the request parameters of the task request according to the split number.

[0121] In an embodiment provided in the present application, based on the above scheme, optionally, the sending unit comprises:

[0122] determining a polling interval time of the front end according to the estimated processing time and the waiting time corresponding to the task request;

[0123] generating a polling prompt information according to the polling interval time;

[0124] sending a polling indication information to the front end.

[0125] The specific principles and execution processes of each unit and module in the request result storing device disclosed by the embodiments of the present application are the same as those of the request result storing method disclosed by the embodiments of the present application, and can be referred to the corresponding parts of the request result storing method provided by the embodiments of the present application, which will not be repeated here.

[0126] The embodiments of the present application further provide a storage medium, which comprises stored instructions, wherein when the instructions are executed, the device where the storage medium is located performs the request result storing method.

[0127] The embodiments of the present application further provide an electronic device, a structural schematic diagram of which is shown in Figure 6 The electronic device specifically comprises a memory 601 and one or more than one instruction 602, wherein the one or more than one instruction 602 is stored in the memory 601 and is configured to be executed by one or more than one processor 603 to execute the request result storing method.

[0128] It should be noted that each embodiment in the present specification adopts a progressive manner for description, and each embodiment mainly describes the difference from other embodiments, and the same and similar parts between each embodiment can be referred to each other. For the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant part can be referred to the part of the method embodiment.

[0129] Finally, it should be noted that in this paper, the relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between the entities or operations.

[0130] For the convenience of description, the above device is described as various units respectively described in function. Of course, in the implementation of the present application, the functions of each unit can be implemented in the same or more than one software and / or hardware.

[0131] Those skilled in the art can clearly understand the application by the description of the above embodiments that the application can be implemented by means of software and the necessary universal hardware platform. Based on such an understanding, the technical solutions of the application can be embodied in the form of a software product in essence or in the part of the prior art that makes a contribution. The computer software product can be stored in a storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, etc., and includes a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the method described in each embodiment or some part of the embodiments of the application.

[0132] The above describes in detail the method for requesting a result to be stored according to the application, and the principle and implementation of the application are described by using specific examples. The above embodiment is only used to help understand the method and the core idea of the application. Meanwhile, for those skilled in the art, the specific implementation and application range can be changed according to the idea of the application. In summary, the content of the specification should not be understood as a limitation of the application.

Claims

1. A request result transfer method, characterized in that: include: Receive task requests sent by the front end; Determining an estimated processing time and an estimated memory footprint of the task request; When the estimated processing time is greater than the time threshold and the estimated memory usage is not greater than the memory usage threshold, creating a cache in a cache module according to the task identifier in the task request and processing request parameters of the task request; The memory occupancy threshold is determined based on the available memory of the cache module; Upon receiving a result request corresponding to the task request sent by the front end, if the task request has not been processed, sending polling instruction information to the front end, the polling instruction information including a polling interval, the polling instruction information being used to instruct the front end to query the cache module for result data corresponding to the task request according to the polling interval; When the task request is processed completely, the result data of the task request is stored in the cache module according to the task identifier.

2. The method according to claim 1, characterized in that The process of determining the estimated processing time of the task request according to the request parameters includes: Get the historical average processing time and historical request success rate; The estimated processing time of the task request is calculated based on the number of the request parameters, the historical average processing time, and the historical request success rate.

3. The method according to claim 1, characterized in that Also includes: When the estimated processing time is greater than a time threshold and the estimated memory occupation space is greater than a memory occupation threshold, the request parameters of the task request are split and the split request parameters are processed.

4. The method according to claim 3, characterized in that The splitting of the request parameters of the task request includes: The number of splits of the request parameter is calculated based on the number of the request parameters, the preset single maximum occupied memory, and the preset safety value; The request parameters of the task request are split according to the split quantity.

5. The method according to claim 1, wherein The sending of polling indication information to the front end includes: Determining a polling interval of the front end according to the estimated processing time and the waiting time corresponding to the task request; Generate polling prompt information according to the polling interval; Sending polling indication information to the front end.

6. A request result transfer device, characterized in that: include: A receiving unit, used for receiving task requests sent by the front end; a determination unit, configured to determine an estimated processing time and an estimated memory footprint of the task request; a first execution unit, configured to, if the estimated processing time is greater than a time threshold and the estimated memory usage is not greater than a memory usage threshold, create a cache in a cache module according to the task identifier in the task request and process request parameters of the task request; The memory occupancy threshold is determined based on the available memory of the cache module; a sending unit, configured to, upon receiving a result request corresponding to the task request sent by the front end, send polling instruction information to the front end if processing of the task request has not been completed, wherein the polling instruction information includes a polling interval, and the polling instruction information is used to instruct the front end to query the cache module for result data corresponding to the task request according to the polling interval; The second execution unit is configured to store result data of the task request in the cache module according to the task identifier when processing of the task request is completed.

7. The device according to claim 6, characterized in that The determining unit includes: The acquisition subunit is used to obtain the historical average processing time and historical request success rate; The calculation subunit is used to calculate the estimated processing time of the task request according to the number of the request parameters, the historical average processing time and the historical request success rate.

8. The device according to claim 6, characterized in that Also includes: The splitting unit is used to split the request parameters of the task request and process the split request parameters when the estimated processing time is greater than the time threshold and the estimated memory occupancy space is greater than the memory occupancy threshold.

9. A storage medium, characterized in that: The storage medium includes a storage instruction, wherein when the instruction is executed, the device where the storage medium is located is controlled to execute the request result transfer method according to any one of claims 1 to 5.

10. An electronic device, characterized in that: The system comprises a memory and one or more instructions, wherein the one or more instructions are stored in the memory and configured to execute the request result transfer method according to any one of claims 1 to 5 by one or more processors.