A request processing method and device

Abstract

The present invention discloses a request processing method and device, and relates to the field of computer technology. A specific implementation of the method includes: receiving a network request, determining an interface for processing the network request according to the parameters carried by the network request, and obtaining the request processing logic of the interface; determining multiple sub-logics contained in the request processing logic, and splitting the network request into multiple sub-tasks through the multiple sub-logics; asynchronously processing each sub-task according to the execution relationship between the sub-logics, obtaining the processing result and returning it through the interface. This implementation method pre-sets the execution relationship between the sub-logics and splits the request into multiple sub-tasks. The sub-tasks do not need to be processed in the existing full serial manner, thereby greatly reducing the time consumption of interface calls and reducing the overall coding complexity.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a request processing method and device. Background Art

[0002] Some core pages or modules in interactive scenarios carry a large amount of traffic, such as the home page, activity page, and order list. These traffic entrances generally obtain data by calling distributed services (such as dubbo, jsf) http interfaces, etc., requiring low time consumption and high availability in high concurrency scenarios.

[0003] The traditional interface call method is synchronous blocking, that is, the business logic behind the request is executed sequentially, so the response time is the sum of the response time of all business logic. When there are many external services and complex processes, it is difficult to meet the performance requirements of the business system. For this scenario, the current mainstream solutions are mainly the following:

[0004] 1. Semi-asynchronous: Through the JDK thread pool, the Future interface uses multi-threading to initiate multiple requests to multiple services at one time;

[0005] 2. Fully asynchronous: Callback mechanism combined with asynchronous thread calling service.

[0006] In the process of implementing the present invention, the inventors found that the prior art has at least the following problems:

[0007] In method 1, waiting for the result of the asynchronous call interface will block the main thread that receives the request. High concurrent requests will lead to too many threads, resulting in a waste of CPU performance. If there is a call sequence dependency in concurrent requests, they must be executed step by step, resulting in complex coding logic and problems such as threads waiting for each other.

[0008] In method 2, when there are two or more dependent services, the return results of different services cannot be processed uniformly, so it is only applicable to simple scenarios; there is a lack of a unified processing mechanism for exceptions, blocking, timeouts, etc. Summary of the invention

[0009] In view of this, an embodiment of the present invention provides a request processing method and device, which can at least solve the problem that there is no standard solution for coordinating and scheduling complex logic to reduce time consumption.

[0010] To achieve the above object, according to one aspect of an embodiment of the present invention, a request processing method is provided, comprising:

[0011] Receive a network request, determine an interface for processing the network request based on parameters carried by the network request, and obtain request processing logic of the interface;

[0012] Determine a plurality of sub-logics included in the request processing logic, and split the network request into a plurality of sub-tasks through the plurality of sub-logics;

[0013] Each subtask is processed asynchronously according to the execution relationship between the sub-logics, and the processing result is obtained and returned through the interface.

[0014] Optionally, before receiving the network request, the method further includes:

[0015] Receiving an arrangement operation of the execution relationship between the plurality of sub-logics; wherein the execution relationship includes an execution order and a strong dependency relationship, the execution order is full parallel, full serial, or a combination of serial and parallel, and the strong dependency relationship exists in the full serial or the combination of serial and parallel;

[0016] The splitting of the network request into multiple subtasks by the multiple sub-logics further includes:

[0017] The execution relationship between the multiple subtasks is added to the task execution information, and then added to the thread pool together with the multiple tasks to wait for execution; wherein the execution relationship between the multiple subtasks is equal to the execution relationship between the multiple sub-logics.

[0018] Optionally, the method includes: adding the first subtask and the task execution information to the thread pool; wherein the first subtask is a task that is first executed among the multiple subtasks, and the number is one or more;

[0019] Then, other tasks associated with the first subtask are added to the thread pool.

[0020] Optionally, the asynchronously processing each subtask according to the execution relationship between the sub-logics, obtaining the processing result and returning it through the interface includes:

[0021] Scheduling a first subtask from a thread pool, and before processing the first subtask, determining whether there is a strong dependency between the next subtask and the first subtask through the execution relationship;

[0022] If it exists, process the first subtask and use the first processing result as the input parameter of the next subtask; or

[0023] If it does not exist, processing the next subtask while processing the first subtask;

[0024] Before processing the next subtask, judging whether there is a strong dependency relationship between the next subtask and the next subtask through the task execution information;

[0025] Repeat the above steps until all subtasks are processed, and obtain the final processing result and return it through the interface.

[0026] Optionally, before determining whether there is a strong dependency relationship between the next subtask and the first subtask, the method further includes:

[0027] Obtain the time point at which the first subtask joins the thread pool, and determine whether the difference between the time point and the current time point is greater than a preset time difference;

[0028] If it is greater, the first subtask is not processed, and other tasks associated with the first subtask are stopped from being processed, and an execution failure result is generated and returned through the interface; or

[0029] If it is less than or equal to, it is determined whether there is a strong dependency relationship between the next subtask and the first subtask.

[0030] Optionally, it also includes: if an exception occurs during the execution of any subtask, the processing process of any subtask and other subtasks is interrupted, and an execution failure result is generated and returned through the interface.

[0031] To achieve the above object, according to another aspect of an embodiment of the present invention, a request processing device is provided, comprising:

[0032] A request receiving module, used to receive a network request, determine an interface for processing the network request according to parameters carried by the network request, and obtain the request processing logic of the interface;

[0033] A task splitting module, used to determine a plurality of sub-logics included in the request processing logic, and split the network request into a plurality of sub-tasks through the plurality of sub-logics;

[0034] The task processing module is used to asynchronously process each subtask according to the execution relationship between the sub-logics, obtain the processing results and return them through the interface.

[0035] Optionally, a relationship orchestration module is also included to:

[0036] Receiving an arrangement operation of the execution relationship between the plurality of sub-logics; wherein the execution relationship includes an execution order and a strong dependency relationship, the execution order is full parallel, full serial, or a combination of serial and parallel, and the strong dependency relationship exists in the full serial or the combination of serial and parallel;

[0037] The task splitting module is used to:

[0038] The execution relationship between the multiple subtasks is added to the task execution information, and then added to the thread pool together with the multiple tasks to wait for execution; wherein the execution relationship between the multiple subtasks is equal to the execution relationship between the multiple sub-logics.

[0039] Optionally, the task splitting module is used to:

[0040] Adding the first subtask and the task execution information to the thread pool; wherein the first subtask is the task that is first executed among the multiple subtasks, and the number is one or more;

[0041] Then, other tasks associated with the first subtask are added to the thread pool.

[0042] Optionally, the task processing module is used to:

[0043] Scheduling a first subtask from a thread pool, and before processing the first subtask, determining whether there is a strong dependency between the next subtask and the first subtask through the execution relationship;

[0044] If it exists, process the first subtask and use the first processing result as the input parameter of the next subtask; or

[0045] If it does not exist, processing the next subtask while processing the first subtask;

[0046] Before processing the next subtask, judging whether there is a strong dependency relationship between the next subtask and the next subtask through the task execution information;

[0047] Repeat the above steps until all subtasks are processed, and obtain the final processing result and return it through the interface.

[0048] Optionally, the task processing module is further used to:

[0049] Obtain the time point at which the first subtask joins the thread pool, and determine whether the difference between the time point and the current time point is greater than a preset time difference;

[0050] If it is greater, the first subtask is not processed, and other tasks associated with the first subtask are stopped from being processed, and an execution failure result is generated and returned through the interface; or

[0051] If it is less than or equal to, it is determined whether there is a strong dependency relationship between the next subtask and the first subtask.

[0052] Optionally, an exception handling module is also included, which is used to:

[0053] If an exception occurs during the execution of any subtask, the processing of any subtask and other subtasks will be interrupted, and an execution failure result will be generated and returned through the interface.

[0054] To achieve the above objective, according to another aspect of an embodiment of the present invention, a request processing electronic device is provided.

[0055] The electronic device of an embodiment of the present invention includes: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement any of the request processing methods described above.

[0056] To achieve the above objective, according to another aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored, and when the program is executed by a processor, any of the above request processing methods is implemented.

[0057] According to the solution provided by the present invention, one embodiment of the above invention has the following advantages or beneficial effects: based on the Completable asynchronous programming technology of JDK itself, combined with the thread pool, by formulating the execution order and strong dependency between sub-logics, the effect of fully asynchronous and non-blocking main thread is achieved in high concurrency scenarios to improve request processing efficiency; in addition, a global timeout is set to uniformly handle timeout tasks and reduce the situation where processing results are invalid.

[0058] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with specific implementation examples. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0060] Figure 1 This is a main flow chart of a request processing method according to an embodiment of the present invention;

[0061] Figure 2 (a) to (d) show the execution logic schematic diagrams of different execution orders;

[0062] Figure 3 is a flowchart of an optional request processing method according to an embodiment of the present invention;

[0063] Figure 4 is a flowchart of another optional request processing method according to an embodiment of the present invention;

[0064] Figure 5 It is a specific process diagram;

[0065] Figure 6 is a schematic diagram of main modules of a request processing device according to an embodiment of the present invention;

[0066] Figure 7 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0067] Figure 8It is a schematic diagram of the structure of a computer system of a mobile device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0068] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0069] The following are the explanations for the terms involved in this plan:

[0070] Dubbo and jsf: Both are mainstream distributed service governance frameworks used to implement high-performance RPC service calls between clusters.

[0071] Callback mechanism (function): A function called through a function pointer. If a function pointer (address) is passed as a parameter to another function, when this pointer is used to call the function it points to, it is called a callback function. The callback function is not called directly by the implementer of the function, but is called by another party when a specific event or condition occurs, in order to respond to the event or condition.

[0072] CompletableFuture asynchronous programming: refers to the newly added CompletableFuture class in Java 8, which gives Java a complete non-blocking programming model. It can execute callbacks in a thread different from the task, and can also use callbacks as synchronous functions to continue execution in the same thread as the task. It avoids the biggest problem of traditional callbacks, which is the ability to separate control flows into different event handlers. CompletableFuture makes up for the shortcomings of the Future model. After the asynchronous task is completed, there is no need to wait when you need to continue the operation with its result. The results of the previous asynchronous processing can be directly handed over to another asynchronous event processing thread for processing through thenAccept, thenApply, thenCompose, etc.

[0073] ThreadPoolExecutor thread pool: The thread pool creates several executable threads and puts them into a pool (container). When there is a task to be processed, it will be submitted to the task queue in the thread pool. After processing, the thread will not be destroyed, but will still wait for the next task in the thread pool. ThreadPoolExecutor is a thread pool implemented by JDK, which can usually provide enhanced performance when executing a large number of asynchronous tasks.

[0074] See also Figure 1 , which shows a main flow chart of a request processing method provided by an embodiment of the present invention, including the following steps:

[0075] S101: receiving a network request, determining an interface for processing the network request according to parameters carried by the network request, and obtaining request processing logic of the interface;

[0076] S102: Determine a plurality of sub-logics included in the request processing logic, and split the network request into a plurality of sub-tasks through the plurality of sub-logics;

[0077] S103: asynchronously process each subtask according to the execution relationship between the sub-logics, obtain the processing result and return it through the interface.

[0078] In the above implementation, for step S101, this solution is applicable to all scenarios that use interfaces to process network requests, such as e-commerce scenarios. Based on the CompletableFuture asynchronous programming technology in JDK1.8, combined with the ThreadPoolExecutor thread pool, the problem of asynchronous non-blocking calls of interfaces in high-concurrency services is solved.

[0079] Different interfaces have different logics for processing requests. Each logic is actually associated with multiple sub-logics. The execution order between these sub-logics needs to be pre-set by business personnel according to specific business scenarios. The following situations are summarized after comprehensive consideration:

[0080] 1. Full parallelism, as shown in Figure 2(a), can be achieved by directly using multi-threaded concurrency

[0081] 2. Full serial, as shown in Figure 2(b), the execution order needs to be considered. Referring to the linked list structure task1>task2>task3, the tasks can be encapsulated into a single task node, connected end to end. The encapsulated object of the Task task contains the next Task task to be executed, and the execution order is also specified when defining the node.

[0082] 3. Serial and parallel combination:

[0083] ① Parallel first and then serial, as shown in Figure 2(c), different situations will occur at this time: Task3 will be executed after both Task1 and Task2 are completed, or Task3 can be executed after either Task1 or Task2 is completed.

[0084] ② Serial first and then parallel. As shown in Figure 2(d), the next node of Task1 has multiple nodes, Task2 and Task3. After the execution is completed, Task2 and Task3 can be directly scheduled for execution at the same time.

[0085] According to the above description, there is a certain strong dependency on the execution order of a serial structure. For example, in "parallel first, then serial", because the next task node of Task1 and Task2 is Task3, a Boolean attribute needs to be added to the Task3 task object (Boolean attributes mainly appear on form elements and control a certain state of the element) to identify whether the current task execution is strongly dependent on the completion of the previous node Task1 and Task2.

[0086] In summary, no matter how complex asynchronous task scheduling is, it is a combination of the above situations. Users can abstract these basic processes and make them into technical middleware so that they can arbitrarily arrange the order according to the business scenarios they need to implement. The scheduling and execution processes of all subtasks are no longer related, thus freeing them from tedious coding and completing the core logic design of task execution scheduling.

[0087] Web services receive network requests sent by users through clients. They can determine the processing scenario based on the parameters of the network request, and then use the interface corresponding to the scenario to process the network request. Web service refers to the type of system, which is a general term that includes commonly understood PC web pages, mobile browsers, and mobile apps. Network request refers to the process by which a browser or app application obtains information from a server through the http / tcp protocol. The information carried in the request includes but is not limited to text, pictures, audio, and video, all of which are byte stream information. This information exchange process is the request.

[0088] For step S102, in actual operation, a request also requires multiple steps to be completed in coordination, so after the request processing logic of the interface is split into multiple sub-logics, the network request can be split according to the sub-logics to obtain multiple sub-tasks.

[0089] For example, receiving a meal order request, according to the self-service order processing logic, it is divided into: Task 1 - notify the kitchen to prepare the food according to the order menu; Task 2 - calculate the buying and selling prices, collect money and settle the bill; Task 3 - pack the food and give it to the user. For example, a warehouse item processing request is divided into: Task 1 - locate the storage area and storage location according to the item identification; Task 2 - issue a picking task and pick the goods from the storage area and storage location; Task 3 - pack and ship out after picking.

[0090] As for step S103, according to the above step description, there is a certain execution order between sub-logics, and some sub-logics have strong dependencies. For example, Task3 in the order request can only be executed after Task1 is processed. Therefore, when the sub-logics are used to process the subtasks in the future, they must be strictly followed in accordance with the execution order and strong dependencies.

[0091] Taking the above ordering request as an example, the existing traditional method is completely synchronous, that is, Task2 is executed after Task1 is completed, and Task3 is executed after Task2 is completed. Since Task1 takes the longest time and is the first subtask, it needs to be executed first, but Task2 does not depend on the execution result of Task1 and can be executed in parallel with Task1. Therefore, the existing method has the problem of low efficiency because there is a lot of meaningless waiting time between Task1 and Task2. This solution pre-sets the execution order between sub-logics. At this time, Task1 will be executed first, and Task2 will be started immediately for settlement. After Task1 is completed, it will be handed over to Task3 for processing, which improves the efficiency of the entire ordering service processing.

[0092] In addition, it should be noted that no matter what kind of request is made, there is only one final processing result. Therefore, for scenarios with parallel sub-logics, although there are multiple processing results, they still need to be integrated in the end.

[0093] The method provided in the above embodiment pre-sets the execution relationship between sub-logics and splits the request into multiple sub-tasks. The sub-tasks do not need to be processed in the existing full serial manner, thereby greatly reducing the time consumption of interface calls and reducing the overall coding complexity.

[0094] See also Figure 3 , shows a schematic flow chart of an optional request processing method according to an embodiment of the present invention, comprising the following steps:

[0095] S301: receiving a network request, determining an interface for processing the network request according to parameters carried by the network request, and obtaining request processing logic of the interface;

[0096] S302: Determine a plurality of sub-logics included in the request processing logic, and split the network request into a plurality of sub-tasks through the plurality of sub-logics;

[0097] S303: adding the execution relationship between the multiple subtasks to the task execution information; wherein the execution relationship between the multiple subtasks is equal to the execution relationship between the multiple sub-logics;

[0098] S304: adding the first subtask and the task execution information to the first subtask in the thread pool, and then adding other tasks associated with the first subtask to the thread pool; wherein the first subtask is the task that is executed first among the multiple subtasks, and the number is one or more first subtasks;

[0099] S305: Scheduling the first subtask from the thread pool, and before processing the first subtask, determining whether there is a strong dependency between the next subtask and the first subtask through the execution relationship;

[0100] S306: If it exists, process the first subtask and use the first processing result as the input parameter of the next subtask;

[0101] S307: If not, processing the next subtask while processing the first subtask;

[0102] S308: Before processing the next subtask, determine, through the task execution information, whether there is a strong dependency relationship between the next subtask and the next subtask;

[0103] S309: Repeat the above steps until all subtasks are processed, and obtain the final processing result and return it through the interface.

[0104] In the above embodiment, for steps S301 and S302, see Figure 1 The description of steps S101 and S102 is not repeated here.

[0105] In the above implementation, for steps S303 to S304, based on the CompleteFuture asynchronous programming technology in JDK1.8, combined with the ThreadPoolExecutor thread pool, the problem of asynchronous non-blocking call of interfaces in high-concurrency services is solved.

[0106] All subtasks need to be submitted to the thread pool for asynchronous scheduling. The key code is as follows:

[0107]

[0108]

[0109] Although the thread pool stores multiple tasks, the execution order and strong dependencies between these tasks are uncertain, so it is necessary to build a task execution information to store the execution relationship (execution order and strong dependencies) between multiple tasks. In the end, the thread pool stores multiple tasks and the corresponding task execution information.

[0110] In addition, the first subtask and the task execution information can be stored in the thread pool first, and then other subtasks can be stored in the thread pool to improve the task storage efficiency, which provides a basis for the subsequent priority execution of the first subtask and the improvement of task processing efficiency. It should be noted that the number of first subtasks can be multiple, such as the first subtasks Task1, Task2 and T ask3 in Figure 2 (a), or it can be one, such as the first subtask Task1 in Figure 2 (b).

[0111] For steps S305 to S307, the first subtask in the thread pool is processed first to avoid the need to determine whether it is the first subtask in subsequent processing, thereby further improving task processing efficiency.

[0112] Before executing the first subtask, it is necessary to determine whether the next task has a strong dependency with this task. If there is no strong dependency, Task2 will be executed immediately when Task1 is executed, such as Task1 and Task2 in the order request. Otherwise, Task2 will be executed only after Task1 is completed, such as Task1 and Task2 in the warehouse item processing request.

[0113] For the next subtask that is located after the first subtask and has a strong dependency on the first subtask, the execution result of the first subtask needs to be used as the input parameter of the current Task. The next subtask needs to add a Map attribute, the key is the task id, the value is the strongly dependent upstream task, and the previous task node information is put in before the upstream task is executed. When using it, just get it. The pseudo code is as follows:

[0114]

[0115] In addition, each subtask needs to implement the TaskCallBack interface. After the task is completed, the complete method of the interface will be called back to return the result and input parameters. The pseudo code is as follows:

[0116]

[0117] All tasks need to implement the TaskHandle interface. The handle method is the actual business logic implementation and the actual content executed by the asynchronous thread.

[0118]

[0119]

[0120] For steps S308 to S309, when processing the next subtask, it is also necessary to determine whether there is a strong dependency between the next subtask and the next subtask. If there is a strong dependency, Task3 must be executed after Task2 is executed, and the execution result of Task2 is used as the input parameter of Task3, such as Task2 and Task3 in the warehouse item processing request. Otherwise, Task3 can be executed immediately while Task2 is being executed, such as Task2 and Task3 in the meal ordering request.

[0121] Repeat the above steps until all subtasks corresponding to this network request are processed, and return the final processing result to the client through the interface.

[0122] Furthermore, you can also specify a global timeout and a unified exception handling mechanism. For details, see Figure 4 As shown:

[0123] Each task object has a timeout attribute. When starting the first subtask, a global timeout is also specified. The pseudo code initialization method is as follows:

[0124] TaskNode taskNode=new TaskNode.Builder<String,String> ()

[0125] .id("task1").next(t2).timeout(500L).build();

[0126] Tasks.start(10000L,taskNode);

[0127] If the time difference between the time when the first subtask joins the thread pool and the current time exceeds the preset time difference, it means that the processing of the first subtask has timed out, that is, there is no need to continue processing, and the corresponding subsequent subtasks are also terminated, and finally the execution failure result is returned to the client.

[0128] Furthermore, for exceptions during the execution of subtasks, you can use the TaskException class to customize exception information to facilitate unified processing by the caller:

[0129]

[0130] During the processing of the first subtask and any subsequent subtasks, if an exception occurs during execution, the processing will be stopped directly and the execution failure result will be returned to the client.

[0131] The method provided in the above embodiment, based on the Completable asynchronous programming technology of JDK itself, combined with the thread pool, achieves a fully asynchronous and non-blocking effect in a high-concurrency scenario by formulating the execution order and strong dependencies between sub-logics, so as to improve the request processing efficiency; in addition, a global timeout is set to uniformly process timed tasks and reduce the situation where the processing results are invalid.

[0132] See also Figure 5 As shown, this is a schematic diagram of the overall process:

[0133] 1. The Web service receives the network request transmitted by the client, determines the interface for processing the network request, and obtains the request processing logic in the interface;

[0134] 2. According to the multiple sub-logics in the request processing logic, the network request is split into multiple sub-tasks, and the execution relationship between the sub-tasks is determined according to the execution relationship between the sub-logics;

[0135] 3. Store multiple subtasks and task execution information storing their execution relationships together in the thread pool; preferably, store the first subtask and task execution information first;

[0136] 4. First, pull the first subtask from the thread pool, determine from the task execution information whether it has a strong dependency relationship with the next subtask, and perform corresponding operations based on the judgment result;

[0137] 5. Continue to process the next subtask, and then the next subtask, until all subtasks are processed and the processing result is obtained;

[0138] 6. Return the final processing result to the client through the interface.

[0139] See also Figure 6 , which shows a schematic diagram of main modules of a request processing device 600 provided in an embodiment of the present invention, including:

[0140] The request receiving module 601 is used to receive a network request, determine an interface for processing the network request according to parameters carried by the network request, and obtain the request processing logic of the interface;

[0141] A task splitting module 602 is used to determine a plurality of sub-logics included in the request processing logic, and split the network request into a plurality of sub-tasks through the plurality of sub-logics;

[0142] The task processing module 603 is used to asynchronously process each subtask according to the execution relationship between the sub-logics, obtain the processing result and return it through the interface.

[0143] The implementation device of the present invention further includes a relationship arrangement module 604 (not shown in the figure), which is used to:

[0144] Receiving an arrangement operation of the execution relationship between the plurality of sub-logics; wherein the execution relationship includes an execution order and a strong dependency relationship, the execution order is full parallel, full serial, or a combination of serial and parallel, and the strong dependency relationship exists in the full serial or the combination of serial and parallel;

[0145] The task splitting module 603 is used to:

[0146] The execution relationship between the multiple subtasks is added to the task execution information, and then added to the thread pool together with the multiple tasks to wait for execution; wherein the execution relationship between the multiple subtasks is equal to the execution relationship between the multiple sub-logics.

[0147] In the implementation device of the present invention, the task splitting module 602 is used to:

[0148] Adding the first subtask and the task execution information to the thread pool; wherein the first subtask is the task that is first executed among the multiple subtasks, and the number is one or more;

[0149] Then, other tasks associated with the first subtask are added to the thread pool.

[0150] In the implementation device of the present invention, the task processing module 603 is used to:

[0151] Scheduling a first subtask from a thread pool, and before processing the first subtask, determining whether there is a strong dependency between the next subtask and the first subtask through the execution relationship;

[0152] If it exists, process the first subtask and use the first processing result as the input parameter of the next subtask; or

[0153] If it does not exist, processing the next subtask while processing the first subtask;

[0154] Before processing the next subtask, judging whether there is a strong dependency relationship between the next subtask and the next subtask through the task execution information;

[0155] Repeat the above steps until all subtasks are processed, and obtain the final processing result and return it through the interface.

[0156] In the implementation device of the present invention, the task processing module 603 is also used for:

[0157] Obtain the time point at which the first subtask joins the thread pool, and determine whether the difference between the time point and the current time point is greater than a preset time difference;

[0158] If it is greater, the first subtask is not processed, and other tasks associated with the first subtask are stopped from being processed, and an execution failure result is generated and returned through the interface; or

[0159] If it is less than or equal to, it is determined whether there is a strong dependency relationship between the next subtask and the first subtask.

[0160] The implementation device of the present invention further includes an exception handling module 605 (not shown in the figure), which is used to:

[0161] If an exception occurs during the execution of any subtask, the processing of any subtask and other subtasks will be interrupted, and an execution failure result will be generated and returned through the interface.

[0162] In addition, the specific implementation content of the device described in the embodiment of the present invention has been described in detail in the method described above, so the repeated content will not be described again here.

[0163] Figure 7 An exemplary system architecture 700 is shown in which embodiments of the present invention may be applied.

[0164] like Figure 7 As shown, system architecture 700 may include terminal devices 701, 702, 703, network 704 and server 705 (just an example). Network 704 is used to provide a medium for communication links between terminal devices 701, 702, 703 and server 705. Network 704 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0165] The user can use the terminal devices 701, 702, 703 to interact with the server 705 through the network 704 to receive or send messages, etc. The terminal devices 701, 702, 703 can be installed with various communication client applications.

[0166] The terminal devices 701, 702, and 703 may be various electronic devices having display screens and supporting web browsing, and the server 705 may be a server providing various services.

[0167] It should be noted that the method provided in the embodiment of the present invention is generally executed by the server 705 , and accordingly, the device is generally set in the server 705 .

[0168] It should be understood that Figure 7 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0169] Reference below Figure 8, which shows a schematic diagram of the structure of a computer system 800 of a terminal device suitable for implementing an embodiment of the present invention. Figure 8 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0170] like Figure 8 As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage part 808 to a random access memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the system 800 are also stored. The CPU 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0171] The following components are connected to the I / O interface 805: an input section 806 including a keyboard, a mouse, etc.; an output section 807 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, a modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. A removable medium 811, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 810 as needed, so that a computer program read therefrom is installed into the storage section 808 as needed.

[0172] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 809, and / or installed from the removable medium 811. When the computer program is executed by the central processing unit (CPU) 801, the above-mentioned functions defined in the system of the present invention are executed.

[0173] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0174] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0175] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The modules described may also be set in a processor, for example, it may be described as: a processor includes a request receiving module, a task splitting module, and a task processing module. The names of these modules do not constitute a limitation on the modules themselves in some cases, for example, the request receiving module may also be described as a "network request receiving module".

[0176] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes:

[0177] Receive a network request, determine an interface for processing the network request based on parameters carried by the network request, and obtain request processing logic of the interface;

[0178] Determine a plurality of sub-logics included in the request processing logic, and split the network request into a plurality of sub-tasks through the plurality of sub-logics;

[0179] Each subtask is processed asynchronously according to the execution relationship between the sub-logics, and the processing result is obtained and returned through the interface.

[0180] According to the technical solution of the embodiment of the present invention, based on the Completable asynchronous programming technology of JDK itself and combined with the thread pool, a full asynchronous and non-blocking effect is achieved in a high-concurrency scenario by formulating the execution order and strong dependencies between sub-logics to improve the request processing efficiency. In addition, a global timeout is set to uniformly handle timeout tasks and reduce the situation where the processing results are invalid.

[0181] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A request processing method, characterized in that: include: Receive a network request, determine an interface for processing the network request based on parameters carried by the network request, and obtain request processing logic of the interface; Determining multiple sub-logics included in the request processing logic, and splitting the network request into multiple sub-tasks through the multiple sub-logics, including: adding the execution relationship between the multiple sub-tasks to the task execution information, and then adding them together with the multiple sub-tasks to the thread pool to wait for execution; wherein the execution relationship includes the execution order and the strong dependency relationship; Adding the plurality of tasks to the thread pool together includes: adding the first subtask and the task execution information to the thread pool; wherein the first subtask is the task that is first executed among the plurality of subtasks, and the number is one or more; and then adding other tasks associated with the first subtask to the thread pool; Asynchronously process each subtask according to the execution relationship between the sub-logics, obtain the processing result and return it through the interface, including: Scheduling a first subtask from a thread pool, and before processing the first subtask, determining whether there is a strong dependency between the next subtask and the first subtask through the execution relationship; If it exists, process the first subtask and use the first processing result as the input parameter of the next subtask; If it does not exist, processing the next subtask while processing the first subtask; Before processing the next subtask, judging whether there is a strong dependency relationship between the next subtask and the next subtask through the task execution information; Repeat the above steps until all subtasks are processed, and obtain the final processing result and return it through the interface.

2. The method according to claim 1, characterized in that Before receiving the network request, the method further includes: Receive an orchestration operation on the execution relationship between the multiple sub-logics; wherein the execution order is full parallel, full serial, or a combination of serial and parallel, and a strong dependency exists in the full serial or the combination of serial and parallel; and the execution relationship between the multiple subtasks is equal to the execution relationship between the multiple sub-logics.

3. The method according to claim 1, characterized in that Before determining whether there is a strong dependency relationship between the next subtask and the first subtask, the method further includes: Obtain the time point at which the first subtask joins the thread pool, and determine whether the difference between the time point and the current time point is greater than a preset time difference; If it is greater, the first subtask is not processed, and other tasks associated with the first subtask are stopped from being processed, and an execution failure result is generated and returned through the interface; or If it is less than or equal to, it is determined whether there is a strong dependency relationship between the next subtask and the first subtask.

4. The method according to claim 1, characterized in that: Also includes: If an exception occurs during the execution of any subtask, the processing of any subtask and other subtasks will be interrupted, and an execution failure result will be generated and returned through the interface.

5. A request processing device, characterized in that: include: A request receiving module, used to receive a network request, determine an interface for processing the network request according to parameters carried by the network request, and obtain the request processing logic of the interface; A task splitting module, used to determine a plurality of sub-logics included in the request processing logic, and split the network request into a plurality of sub-tasks through the plurality of sub-logics, including: adding the execution relationship between the plurality of sub-tasks to the task execution information, and then adding the plurality of sub-tasks together with the plurality of sub-tasks to the thread pool to wait for execution; wherein the execution relationship includes the execution order and the strong dependency relationship; Adding the plurality of tasks to the thread pool together includes: adding the first subtask and the task execution information to the thread pool; wherein the first subtask is the task that is first executed among the plurality of subtasks, and the number is one or more; and then adding other tasks associated with the first subtask to the thread pool; The task processing module is used to asynchronously process each subtask according to the execution relationship between the sub-logics, obtain the processing results and return them through the interface, including: Scheduling a first subtask from a thread pool, and before processing the first subtask, determining whether there is a strong dependency between the next subtask and the first subtask through the execution relationship; If it exists, process the first subtask and use the first processing result as the input parameter of the next subtask; If it does not exist, processing the next subtask while processing the first subtask; Before processing the next subtask, judging whether there is a strong dependency relationship between the next subtask and the next subtask through the task execution information; Repeat the above steps until all subtasks are processed, and obtain the final processing result and return it through the interface.

6. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 4.

7. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 4 is implemented.

Images