Request message processing method and device, equipment and storage medium

Abstract

The invention relates to the technical field of computers, and discloses a request message processing method and device, equipment and a storage medium, and the method comprises the steps: receiving a first request, and judging whether the first request has a blocking scene or not; if the blocking scene exists, adding a first monitoring instance to a corresponding first target pipeline processor; processing the first request through the first thread, and judging whether a second request is received or not when the first thread executes the first target pipeline processor; if the second request is received, the first target pipeline processor is suspended, and the second request is processed through the first thread; registering an in-execution pipeline processor of the second request into a notification list of the first listening instance; and if the first thread receives a notification message sent by the first monitoring instance through the in-execution pipeline processor of the second request, suspending the in-execution pipeline processor of the second request, and returning to execute the first target pipeline processor. According to the invention, the performance waste of the computing equipment during message processing is reduced.

Description

Technical Field

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

[0002] When writing and executing software programs, the pipeline mode is a variant of the responsibility chain design mode. In the pipeline mode, a program includes multiple pipeline processors, each of which is a piece of code used to handle a specific task. The pipeline processors are connected in sequence and play the role of an assembly line. Computers are often used to process various request messages from external clients. When a request message arrives at a computer device, the task to be performed by the request message is a program task in the pipeline mode. The request is processed by a thread. Starting from the first pipeline processor, the data is passed to a pipeline processor for processing, and then passed to the next pipeline processor for processing until all steps are processed and the processing results are returned to the client. However, if the processing sequence contains blocking operations, such as remote calls, database command execution, etc., it will take up the time of a business processing thread. The thread will wait, occupying computer resources such as physical machine memory in vain, resulting in performance waste. When the computer has many different requests to process, more threads must be created, and the newly created threads are inevitably blocked, resulting in a vicious cycle of performance waste. Summary of the invention

[0003] In view of this, the present invention provides a request message processing method, apparatus, device and storage medium to solve the problem of performance waste.

[0004] In a first aspect, the present invention provides a request message processing method, the method comprising: receiving a first request, and determining whether a pipeline processor in the first request has a blocking scenario; if the blocking scenario exists, adding a first listening instance to the corresponding first target pipeline processor; processing the first request through a first thread, and when the first thread executes to the first target pipeline processor, determining whether a second request is received; if the second request is received, suspending the first target pipeline processor, and processing the second request through the first thread; registering the executing pipeline processor of the second request to the notification list of the first listening instance; if the first thread receives a notification message sent by the first listening instance through the executing pipeline processor of the second request, suspending the executing pipeline processor of the second request, and returning to execute the first target pipeline processor.

[0005] In some optional implementations, the method also includes: if the pipeline processor in the execution of the second request is blocked, suspending the pipeline processor in the execution of the second request, and processing the newly received third request through the first thread; registering the pipeline processor in the execution of the third request to the notification list of the second listening instance and the first listening instance, and adding the second listening instance to the pipeline processor in the execution of the second request.

[0006] In some optional implementations, the method also includes: if the first thread first receives a notification message from the first listening instance through the executing pipeline processor of the third request, suspending the executing pipeline processor of the third request and returning to execute the first target pipeline processor; if the first thread simultaneously receives a notification message from the first listening instance and a notification message from the second listening instance through the executing pipeline processor of the third request, suspending the executing pipeline processor of the third request and returning to execute the first target pipeline processor; if the first thread first receives a notification message from the second listening instance through the executing pipeline processor of the third request, suspending the executing pipeline processor of the third request and returning to execute the executing pipeline processor of the second request.

[0007] In some optional implementations, the method further includes: when the first request is executed, determining whether the remaining requests are completed; if the remaining requests are not completed and the pipeline processors are not blocked during the execution of the remaining requests, executing the requests with an earlier reception time through the first thread; when the second request is executed, determining whether the remaining requests are completed; if the remaining requests are not completed and the pipeline processors are not blocked during the execution of the remaining requests, executing the requests with an earlier reception time through the first thread.

[0008] In some optional implementations, the first thread is an execution thread in a thread pool, the thread pool includes multiple execution threads, the requests processed by the execution thread are assigned by a scheduling thread, and receiving the first request includes: receiving the first request sent by the target client through the scheduling thread; searching for an execution thread in an idle state from the thread pool through the scheduling thread, the idle state including a state with no execution request and a blocking scenario; and assigning the first request to the first thread in the idle state.

[0009] In some optional implementations, the method further includes: feeding back a processing result of the first request to the scheduling thread through the first thread; and feeding back the processing result to the target client through the scheduling thread.

[0010] In some optional implementations, when the current device has multiple processor cores, the number of the scheduling threads is the same as the number of the processor cores, and each processor core runs a corresponding scheduling thread.

[0011] In a second aspect, the present invention provides a request message processing device, which includes: a request initialization module, which is used to receive a first request and determine whether a pipeline processor in the first request has a blocking scenario; a pipeline configuration module, which is used to add a first listening instance to the corresponding first target pipeline processor if the blocking scenario exists; a blocking judgment module, which is used to process the first request through a first thread, and when the first thread executes to the first target pipeline processor, determine whether a second request is received; a jump execution module, which is used to suspend the first target pipeline processor if the second request is received, and process the second request through the first thread; a registration module, which is used to register the executing pipeline processor of the second request to the notification list of the first listening instance; a return execution module, which is used to suspend the executing pipeline processor of the second request and return to execute the first target pipeline processor if the first thread receives a notification message sent by the first listening instance through the executing pipeline processor of the second request.

[0012] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0013] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to cause a computer to execute the method of the first aspect or any corresponding embodiment thereof.

[0014] The technical solution provided by the present invention has the following advantages:

[0015] The present invention defines that each time a computer device receives a request from an external client, it is necessary to determine in advance whether a pipeline processor in the request has a blocking scenario. If a blocking scenario exists, a first listening instance is added to the corresponding first target pipeline processor. When the request is subsequently processed by the first thread, if the first target pipeline processor is blocked, it is determined whether a new second request is received at the current moment. If the second request is received, the first target pipeline processor is suspended and blocked for execution outside the computer device, so suspending the first target pipeline processor does not affect the external execution of the blocking scenario. At this time, the second request is still processed by the first thread, and the pipeline processor in execution of the second request is registered in the notification list of the first listening instance. If the first thread receives a notification message sent by the first listening instance during the execution of the second request, the second request is suspended, and the first target pipeline processor that has just been suspended is returned to continue to execute the task. Through this scheme, each thread does not have an idle waiting time, and the idle waiting time of a thread is used to briefly process the task of the new thread, which significantly reduces the waste of computer resources and improves the utilization of performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0017] Figure 1 is a flowchart of a request message processing method according to an embodiment of the present invention;

[0018] Figure 2 is another flowchart of a request message processing method according to an embodiment of the present invention;

[0019] Figure 3 is another flowchart of a request message processing method according to an embodiment of the present invention;

[0020] Figure 4 is a structural block diagram of a request message processing device according to an embodiment of the present invention;

[0021] Figure 5 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0023] According to an embodiment of the present invention, an embodiment of a request message processing method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0024] In this embodiment, a request message processing method is provided, which can be used in a computer device. Figure 1 1 is a flowchart of a request message processing method according to an embodiment of the present invention, and the process includes the following steps:

[0025] Step S101, receiving a first request, and determining whether a pipeline processor in the first request has a blocking scenario;

[0026] Step S102: if a blocking scenario exists, a first monitoring instance is added to the corresponding first target pipeline processor, and the first monitoring instance is used to monitor whether the blocking scenario ends;

[0027] Step S103, processing the first request through the first thread, and determining whether the second request is received when the first thread executes to the first target pipeline processor;

[0028] Step S104, if the second request is received, suspending the first target pipeline processor and processing the second request through the first thread;

[0029] Step S105, registering the pipeline processor in execution of the second request into the notification list of the first listening instance;

[0030] Step S106: If the first thread receives a notification message sent by the first listening instance through the executing pipeline processor of the second request, the executing pipeline processor of the second request is suspended, and execution of the first target pipeline processor is returned.

[0031] Specifically, Figure 2As shown, the technical solution provided by the embodiment of the present invention, when receiving a request message sent by any client (this embodiment refers to the request message received at the current moment as the first request, and does not limit the first request to be the first request received. Before the first request, the computer device may have received other request messages), first determines whether the pipeline processor in the request message has a blocking scenario. In the embodiment of the present invention, the blocking scenario includes but is not limited to remote calls, database command execution, etc. If it is found that any pipeline processor in the first request includes a blocking scenario, a first listening instance is added to the first target pipeline processor including the blocking scenario. In the embodiment of the present invention, the listening instance is implemented by the Promise mechanism, which is a programming mode for processing asynchronous operations. It represents the final completion (or failure) of the asynchronous operation and its result value. It is an abstraction of a future value, indicating a result that will be generated at a certain point in time in the future. In other words, the listening instance created based on the Promise mechanism can monitor whether the blocking scenario returns the corresponding result, for example, it can monitor whether the remote call returns the result, whether the database command is executed, etc. Regardless of whether the result of the blocking scenario execution is failure or success, as long as the blocking scenario ends, the listening instance will return the corresponding notification message. Among them, the listening instances added by different blocking types are slightly different, and need to match the specific blocking scenario, converting the result of synchronous IO waiting for response into returning CompletableFuture <resulttype>And packaged as a Promise object.

[0032] Afterwards, this embodiment creates a first thread to process the task of the first request, and executes in sequence according to the order of the pipeline processors in the first request. When the first target pipeline processor is executed, the first request is blocked. If the first thread continues to execute the first request, it needs to wait, and the computer resources applied by the first thread will be wasted because they remain occupied. At this time, the computer will determine whether it has received a new second request sent by an external client. If there is no new second request, and the first thread has no older request to end the blocking, the first thread still needs to wait for the first request to end the blocking. If the second request newly sent by the external client is received, the first thread will suspend the first target pipeline processor at this time, and turn to process the second request. Then, in the process of executing the second request, each pipeline processor being executed is registered in the notification list of the first listening instance, so that the first thread can receive the notification message of the first listening instance.

[0033] If the first thread receives a notification message sent by the first listening instance through a certain executing pipeline processor during the execution of the second request, the first thread suspends the executing pipeline processor of the second request and returns to the first target pipeline processor that was just blocked, giving priority to continuing the execution of the first request.

[0034] The above embodiment only describes the process of one thread processing a client request. In actual application scenarios, multiple threads are often created in a computer device, so that each thread is applicable to the processing logic of the above message request.

[0035] Through this solution, each thread has no idle waiting time. The idle waiting time of a thread processing the current task is used to briefly process new requests, which significantly reduces the waste of computer resources and improves performance utilization.

[0036] In some optional implementation manners, the request message processing method provided by the present invention further includes:

[0037] Step a1: if the pipeline processor is blocked during the execution of the second request, suspend the pipeline processor during the execution of the second request, and process the newly received third request through the first thread;

[0038] Step a2: register the executing pipeline processor of the third request into the notification lists of the second listening instance and the first listening instance, and add the second listening instance into the executing pipeline processor of the second request.

[0039] Specifically, when the first thread processes the second request, assuming that there is also a blocking scenario in the second request, and when the second request is processed to the executing pipeline processor corresponding to the blocking scenario, the blocking of the first request has not been completed. This embodiment defines that the first thread continues to suspend the executing pipeline processor of the second request, and turns to process the third request newly received by the computer device, and adds a second monitoring instance to the pipeline processor where the second request is blocked, so as to monitor whether the blocking of the second request is completed.

[0040] In the process of processing the third request, the first thread registers each executing pipeline processor to the notification list of the second listening instance and the first listening instance respectively. Once any one of the second listening instance and the first listening instance sends a notification message to notify the first thread that the first request or the second request has ended blocking, the first thread immediately suspends the executing pipeline processor of the third request, returns to the pipeline processor just executed by the first request or the pipeline processor just executed by the second request, and continues to process the first request or the second request with a higher priority.

[0041] The first request, the second request and the third request are proposed in the embodiment of the present invention only to describe the processing logic of the first thread when more than two requests are blocked, and the first request, the second request and the third request are not used to limit the scenario that the first thread can only process three requests. The technical solution provided in the embodiment of the present invention is intended to describe that the first thread can process more client requests at the same time. For example, before the first request, the first thread may have received more other old requests that are blocked, and they are all waiting, so the first thread currently receives the first request for processing. Similarly, if the first thread will be blocked every time it receives a request, and no notification message of the old request is received when the blocking occurs, the first thread will continue to use the idle time of waiting to continuously turn to process new requests, thereby adding the fourth request, the fifth request, etc., and increasing in sequence. In other words, for other requests after the third request, if the other requests being executed by the first thread are blocked again, the same operation is performed on the other requests according to the aforementioned steps of suspending the second request and turning to process the third request.

[0042] The technical solution provided by the embodiment of the present invention can further improve the degree of asynchronization of each thread, and make full use of the fragmented waiting time of each request to process new requests. Compared with the solution of creating a thread for each request in the related art, the technical solution provided by the present invention can significantly reduce the number of threads, reduce the occupancy of physical machine memory, reduce the context switching of threads, and reduce the performance waste of computer equipment.

[0043] In some optional implementation manners, the request message processing method provided by the present invention further includes:

[0044] Step b1: if the first thread first receives the notification message of the first monitoring instance through the pipeline processor in execution of the third request, the pipeline processor in execution of the third request is suspended, and the execution of the first target pipeline processor is returned;

[0045] Step b2: if the first thread simultaneously receives the notification message of the first listening instance and the notification message of the second listening instance through the executing pipeline processor of the third request, the executing pipeline processor of the third request is suspended, and execution of the first target pipeline processor is returned;

[0046] Step b3: If the first thread first receives the notification message of the second monitoring instance through the executing pipeline processor of the third request, the executing pipeline processor of the third request is suspended, and the executing pipeline processor of the second request is returned to execute.

[0047] Specifically, in an embodiment of the present invention, if the first thread receives a notification message from either the first listening instance or the second listening instance during the execution of the third request, the first thread suspends the third request and gives priority to processing the first request or the second request that arrives earlier. If the first thread receives notification messages from both the first listening instance and the second listening instance during the execution of the third request, the first thread needs to select the request that arrives earlier for limited processing according to the time when the request arrives, that is, give priority to executing the first target pipeline processor in the first request.

[0048] The embodiment of the present invention only describes the processing logic of the first thread when more than two requests complete blocking and send out notification messages using the first request, the second request and the third request, and does not limit the scenario in which the first thread can only process three requests using the number of the first request, the second request and the third request. The technical solution provided by the embodiment of the present invention is intended to describe that the first thread can process more client requests at the same time.

[0049] In other words, during the process of the first thread executing the current request, if any request that arrives earlier than the current request sends a notification message through the listening instance, the first thread suspends the current request and transfers the processing to the corresponding request that sends the current notification message; if any multiple requests that arrive earlier than the current request send notification messages through their respective listening instances, the first thread suspends the current request, determines the target request with the earliest arrival time from the corresponding requests that send the notification messages, and then transfers the processing to the target request.

[0050] Through the technical solution provided by the embodiment of the present invention, when multiple old requests are blocked, whichever old request ends the blocking first, the first thread will jump to the old request that ends the blocking first for priority processing; if multiple old requests end the blocking at the same time, the old request that jumps to the earliest time will be given priority processing; thereby taking into account the speed of the entire processing of each request in more request scenarios, avoiding a certain request from being delayed for too long, thereby avoiding affecting the usage perception of the client user.

[0051] In some optional implementation manners, the request message processing method provided by the present invention further includes:

[0052] Step c1, when the first request is executed, determine whether the remaining requests are completed;

[0053] Step c2: if the remaining requests have not been completed and the pipeline processors are not blocked during the execution of the remaining requests, the requests with an earlier reception time are executed through the first thread;

[0054] Step c3, when the second request is executed, determine whether the remaining requests are completed;

[0055] Step c4: If the remaining requests have not been completed and the pipeline processors are not blocked during the execution of the remaining requests, the requests with an earlier reception time are executed by the first thread.

[0056] Specifically, when the first thread receives a notification message and returns from the third request to execute the first request or the second request, if the first request or the second request is executed normally, the remaining requests have not been completed and the pipeline processors in the execution of the multiple remaining requests are not blocked, the first thread will give priority to executing the request with an earlier reception time. For example, assuming that the first thread returns from the third request to execute the first request, after the execution is completed, the second request and the third request are not completed and are not blocked, the first thread will give priority to executing the second request with an earlier reception time. The embodiment of the present invention only describes the processing logic of the first thread when more than two requests complete the blocking and send a notification message with the first request, the second request and the third request, and does not limit the scenario that the first thread can only process three requests with the number of the first request, the second request and the third request. The technical solution provided by the embodiment of the present invention is intended to describe that the first thread can process more client requests at the same time. Through this solution, the speed of the entire processing of each request is taken into account in more request scenarios, avoiding a certain request from being delayed for too long, thereby avoiding affecting the user perception of the client.

[0057] In some optional implementations, the first thread is an execution thread in a thread pool, the thread pool includes multiple execution threads, and the requests processed by the execution threads are allocated by the scheduling thread. The above step S101 includes:

[0058] Step d1, receiving a first request sent by a target client through a scheduling thread;

[0059] Step d2, searching for an idle execution thread from the thread pool by scheduling the thread, where the idle state includes a state where no request is executed and a blocking scenario;

[0060] Step d3: assigning the first request to the first thread in an idle state.

[0061] In some optional embodiments, the method further comprises:

[0062] Step e1, feeding back the processing result of the first request to the scheduling thread through the first thread;

[0063] Step e2, feeding back the processing result to the target client through the scheduling thread.

[0064] Specifically, the embodiment of the present invention defines two types of threads: execution threads and scheduling threads, wherein execution threads are only used to execute specific program tasks, and scheduling threads are used to assign tasks to each execution thread, thereby realizing the processing of client requests based on the response mode. The response mode is a design mode based on event-driven. The external client serves as one or more concurrent input sources, and the scheduling thread will synchronously distribute the input requests to the corresponding execution threads in a multiplexed manner. In some optional implementations, the Vertx-Web tool can be used to provide a response mode Web service to handle high-traffic client requests. Vertx-Web is a support tool for responsive Web applications. Based on the principles of responsive programming, it can effectively handle high concurrency and asynchronous notification callback operations, use non-blocking I / O for traffic processing, and has better performance scalability than the synchronous I / O model.

[0065] Among them, Figure 3 As shown, several clients generate request messages and add them to the request queue. Each client has a corresponding file descriptor. The scheduling thread monitors the file descriptors of each client through a multiplexing mechanism to determine whether a request message has arrived from the client. After the scheduling thread knows that a new client request has been received, it will search for a suitable execution thread from the thread pool and send the data and callback function included in the client request to the appropriate execution thread for processing. Among them, the suitable execution thread refers to an execution thread in an idle state. The idle state includes the state of not executing requests and the blocking scenario. In other words, the idle state refers to a thread that has not processed any request, or a thread that is processing a request but is in a blocking scenario and is waiting idle.

[0066] Finally, when the execution thread in the thread pool completes a request, the execution thread will feed back the processing results of each request to the scheduling thread, and then feed back the processing results to the target client through the scheduling thread.

[0067] The technical solution provided by the embodiment of the present invention provides a fully asynchronous message processing method, which is mainly reflected in two aspects:

[0068] First, the request is received by the scheduling thread, and the request is assigned to the appropriate execution thread in the thread pool for processing according to the idle state of each execution thread.

[0069] Second, when each execution thread is processing a task, if there is a blocking wait, the idle time of waiting can be used to process other new requests.

[0070] The common solution of the related art is to create a separate thread for each client request to handle multiple high-concurrency requests. Alternatively, a thread is created and used to queue multiple requests. When a request of a certain thread is blocked, it is necessary to wait for the blockage to end and continue to process the request being processed. Therefore, the technical solution of the related art not only has the problem of performance waste, but also when a thread processes a request, other requests must wait, resulting in low processing efficiency.

[0071] The technical solution provided by the embodiment of the present invention can, on the one hand, allocate client requests to idle execution threads for processing by scheduling threads, thereby reducing thread queuing time. On the other hand, each execution thread uses the idle time of the blocking scene to accept new requests for processing, thereby reducing the waiting time of fragmented time. The fully asynchronous operation in the request scheduling and request processing process reduces the performance waste of computer resources and significantly improves the efficiency of request processing.

[0072] In some optional implementations, when the current device has multiple processor cores, the number of scheduling threads is the same as the number of processor cores, and each processor core runs a corresponding scheduling thread.

[0073] Specifically, the embodiment of the present invention uses the CPU thread binding technology to bind a scheduling thread to each processor core, which can avoid the overhead caused by switching back and forth threads on a single core and improve computing efficiency.

[0074] In the present embodiment, a request message processing device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0075] This embodiment provides a request message processing device, such as Figure 4 As shown, including:

[0076] The request initialization module 401 is used to receive a first request and determine whether a pipeline processor in the first request has a blocking scenario;

[0077] The pipeline configuration module 402 is used to add a first monitoring instance to the corresponding first target pipeline processor if a blocking scenario exists, and the first monitoring instance is used to monitor whether the blocking scenario ends;

[0078] The blocking determination module 403 is used to process the first request through the first thread, and determine whether the second request is received when the first thread executes to the first target pipeline processor;

[0079] The jump execution module 404 is used to suspend the first target pipeline processor and process the second request through the first thread if the second request is received;

[0080] A registration module 405, configured to register the executing pipeline processor of the second request into the notification list of the first monitoring instance;

[0081] The return execution module 406 is used to suspend the executing pipeline processor of the second request and return to execute the first target pipeline processor if the first thread receives the notification message sent by the first listening instance through the executing pipeline processor of the second request.

[0082] In some optional embodiments, the device further comprises:

[0083] A second jump module is used for suspending the pipeline processor in execution of the second request if there is a blockage in the pipeline processor in execution of the second request, and processing the newly received third request through the first thread;

[0084] The second registration module is used to register the executing pipeline processor of the third request into the notification lists of the second listening instance and the first listening instance, and the second listening instance is added to the executing pipeline processor of the second request.

[0085] In some optional embodiments, the device further comprises:

[0086] A first priority execution module, configured to suspend the executing pipeline processor of the third request and return to execute the first target pipeline processor if the first thread first receives the notification message of the first monitoring instance through the executing pipeline processor of the third request;

[0087] A second priority execution module, configured to suspend the executing pipeline processor of the third request and return to execute the first target pipeline processor if the first thread simultaneously receives the notification message of the first listening instance and the notification message of the second listening instance through the executing pipeline processor of the third request;

[0088] The third priority execution module is used to suspend the executing pipeline processor of the third request and return to the executing pipeline processor of the second request if the first thread first receives the notification message of the second monitoring instance through the executing pipeline processor of the third request.

[0089] In some optional embodiments, the device further comprises:

[0090] A first remaining judgment module, used to judge whether the remaining requests are completed when the first request is executed;

[0091] A first earliest priority module is used to execute the request with an earlier reception time through the first thread if the remaining requests have not been completed and the pipeline processors are not blocked during the execution of the remaining requests;

[0092] A second remaining judgment module, used to judge whether the remaining requests are completed when the second request is executed;

[0093] The second earliest priority module is used to execute the request with an earlier reception time through the first thread if the remaining requests have not been completed and the pipeline processors are not blocked during the execution of the remaining requests.

[0094] In some optional implementations, the first thread is an execution thread in a thread pool, the thread pool includes multiple execution threads, and the request processed by the execution thread is allocated by a scheduling thread. The request initialization module 401 includes:

[0095] A receiving unit, configured to receive a first request sent by a target client through a scheduling thread;

[0096] An idle search unit is used to search for an idle execution thread from a thread pool by scheduling threads. The idle state includes a state where no request is executed and a blocking scenario.

[0097] The allocation unit is used to allocate the first request to a first thread in an idle state.

[0098] In some optional embodiments, the device further comprises:

[0099] A first feedback unit, configured to feed back a processing result of the first request to the scheduling thread through the first thread;

[0100] The second feedback unit is used to feed back the processing result to the target client through the scheduling thread.

[0101] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0102] The embodiment of the present invention also provides a computer device having the above Figure 4 The request message processing device shown.

[0103] See also Figure 5 , Figure 5 A schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention is as follows: Figure 5 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 5 A processor 10 is taken as an example.

[0104] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0105] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0106] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0107] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0108] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0109] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0110] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

[0111] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.< / resulttype>

Claims

1. A request message processing method, characterized in that: The method comprises: Receive a first request, and determine whether a pipeline processor in the first request has a blocking scenario; If the blocking scenario exists, adding a first monitoring instance for the corresponding first target pipeline processor, wherein the first monitoring instance is used to monitor whether the blocking scenario ends; Processing the first request through a first thread, and determining whether a second request is received when the first thread executes to the first target pipeline processor; If the second request is received, suspending the first target pipeline processor and processing the second request through the first thread; Registering the executing pipeline processor of the second request into the notification list of the first listening instance; If the first thread receives the notification message sent by the first listening instance through the executing pipeline processor of the second request, the executing pipeline processor of the second request is suspended, and execution of the first target pipeline processor is returned.

2. The method according to claim 1, characterized in that: The method further comprises: If the pipeline processor is blocked during the execution of the second request, suspend the pipeline processor during the execution of the second request, and process the newly received third request through the first thread; The executing pipeline processor of the third request is registered in the notification lists of the second listening instance and the first listening instance, and the second listening instance is added to the executing pipeline processor of the second request.

3. The method according to claim 2, characterized in that The method further comprises: If the first thread first receives the notification message of the first listening instance through the pipeline processor in execution of the third request, the pipeline processor in execution of the third request is suspended, and execution of the first target pipeline processor is returned; If the first thread simultaneously receives the notification message of the first listening instance and the notification message of the second listening instance through the executing pipeline processor of the third request, suspending the executing pipeline processor of the third request and returning to execute the first target pipeline processor; If the first thread first receives the notification message of the second listening instance through the executing pipeline processor of the third request, the executing pipeline processor of the third request is suspended, and the executing pipeline processor of the second request is returned to execute.

4. The method according to claim 3, characterized in that The method further comprises: When the first request is executed, determining whether the remaining requests are completed; If the remaining requests have not been completed, and the pipeline processors are not blocked during the execution of the remaining requests, the first thread executes the requests received earlier; When the second request is executed, determining whether the remaining requests are completed; If the remaining requests have not been completed and the pipeline processors are not blocked during the execution of the remaining requests, the requests with an earlier reception time are executed by the first thread.

5. The method according to claim 1, characterized in that The first thread is an execution thread in a thread pool, the thread pool includes multiple execution threads, the request processed by the execution thread is allocated by a scheduling thread, and receiving the first request includes: Receiving the first request sent by the target client through the scheduling thread; Searching for an execution thread in an idle state from the thread pool through the scheduling thread, where the idle state includes a state where no execution request is made and a blocking scenario; The first request is assigned to the first thread in the idle state.

6. The method according to claim 5, characterized in that The method further comprises: Feedback the processing result of the first request to the scheduling thread through the first thread; The processing result is fed back to the target client through the scheduling thread.

7. The method according to claim 5, characterized in that When the current device has multiple processor cores, the number of the scheduling threads is the same as the number of the processor cores, and each processor core runs a corresponding scheduling thread.

8. A request message processing device, characterized in that: The device comprises: A request initialization module, configured to receive a first request and determine whether a pipeline processor in the first request has a blocking scenario; A pipeline configuration module, configured to add a first monitoring instance to the corresponding first target pipeline processor if the blocking scenario exists, wherein the first monitoring instance is used to monitor whether the blocking scenario ends; a blocking determination module, configured to process the first request through a first thread, and determine whether a second request is received when the first thread executes to the first target pipeline processor; a jump execution module, configured to suspend the first target pipeline processor and process the second request through the first thread if the second request is received; A registration module, used to register the executing pipeline processor of the second request into the notification list of the first listening instance; The return execution module is used to suspend the executing pipeline processor of the second request and return to execute the first target pipeline processor if the first thread receives the notification message sent by the first listening instance through the executing pipeline processor of the second request.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images