Request processing method and apparatus, and task execution method and apparatus

Abstract

Embodiments of the present disclosure provide a request processing method and apparatus, and a task execution method and apparatus. The request processing method is applied to a target server, and comprises: in response to a service request, calling a link tracking program to extract request path information in the service request, and determining a target derivative task corresponding to the target server; constructing a key-value pair on the basis of a target task identifier of the target derivative task and the request path information, and storing the key-value pair to a data storage structure of the link tracking program; when executing an associated derivative task corresponding to an associated server among at least two derivative tasks, on the basis of a task relationship between the at least two derivative tasks, determining an associated task identifier corresponding to the associated derivate task; and querying the data storage structure on the basis of the associated task identifier, on the basis of the querying result, creating an associated service request carrying associated request path information, and sending the associated service request to the associated server, the key-value pair recorded in the data storage structure being used for constructing distributed link tracking information.

Description

[0001] Request Processing Method and Apparatus, Task Execution Method and Apparatus This disclosure claims priority to Chinese patent application No. 202410112470.0, filed with the Patent Office of China on January 25, 2024, entitled "Request Processing Method and Apparatus, Task Execution Method and Apparatus," the entire contents of which are incorporated herein by reference. Technical Field: Embodiments of the present disclosure relate to the field of distributed system technology, and more particularly to request processing methods and apparatus, and task execution methods and apparatus. Background: With the advancement of computer technology, distributed systems have provided stable computing power support for a wider range of service projects. Due to the high scalability and reliability of distributed systems, more large-scale services are being implemented in distributed systems. However, as distributed systems become more complex, while they can provide higher computing power support, the failure rate of more complex distributed systems also increases. When a distributed system fails, complex service dependencies and exception propagation exist. For example, a server failure may cause other dependent / invoked servers to also fail. Troubleshooting and repairing such distributed systems is extremely difficult. In the prior art, distributed tracing systems are often used to address the aforementioned issues, helping developers and maintenance personnel quickly locate faults. By tracing the request invocation process step by step, the specific request path of user requests within distributed services can be traced, enabling the propagation of distributed system anomalies to be tracked and located. However, while this approach can achieve fault location, it is inefficient and invasive to native distributed systems. Therefore, an effective solution is urgently needed to address the aforementioned issues. In view of this, embodiments of the present disclosure provide a request processing method. One or more embodiments of the present disclosure also relate to a request processing device, a request processing system, a task execution method, a task execution device, a computing device, a computer-readable storage medium, and a computer program product to address the technical deficiencies of the prior art.According to a first aspect of an embodiment of the present disclosure, a request processing method is provided, which is applied to a target server, comprising: calling a link tracking program in response to a service request to extract request path information in the service request, and determining a target derived task corresponding to the target server among at least two derived tasks associated with the service request; constructing a key-value pair according to the target task identifier of the target derived task and the request path information, and storing the key-value pair in a data storage structure of the link tracking program; when executing an associated derived task corresponding to an associated server among the at least two derived tasks, determining an associated task identifier corresponding to the associated derived task according to a task relationship between the at least two derived tasks; querying the data storage structure based on the associated task identifier, creating an associated service request carrying the associated request path information according to the query result, and sending it to the associated server; wherein the key-value pairs recorded in the data storage structure are used to construct distributed link tracking information. According to a second aspect of an embodiment of the present disclosure, a task execution method is provided, which is applied to a target server, and includes: obtaining a request analysis task, and determining at least two derived tasks associated with the request analysis task; sending a tracking information acquisition request to the servers corresponding to the at least two derived tasks according to the request analysis task; receiving link tracking information fed back by the servers corresponding to the at least two derived tasks in response to the tracking information acquisition request, wherein the link tracking information is stored in a data storage structure corresponding to each server; constructing distributed link tracking information according to the link tracking information, and executing the request analysis task. According to a third aspect of an embodiment of the present disclosure, a request processing device is provided, which is applied to a target server and includes: a calling module, configured to call a link tracking program in response to a service request to extract request path information in the service request, and determine a target derived task corresponding to the target server among at least two derived tasks associated with the service request; a storage module, configured to construct a key-value pair based on the target task identifier of the target derived task and the request path information, and store the key-value pair in a data storage structure of the link tracking program; a determining module, configured to determine the associated task identifier corresponding to the associated derived task according to the task relationship between the at least two derived tasks when executing the associated derived task corresponding to the associated server among the at least two derived tasks; a sending module, configured to query the data storage structure based on the associated task identifier, create an associated service request carrying the associated request path information according to the query result, and send it to the associated server; wherein the key-value pairs recorded in the data storage structure are used to construct distributed link tracking information.According to a fourth aspect of an embodiment of the present disclosure, a task execution device is provided, which is applied to a target server and includes: a task acquisition module, configured to acquire a request analysis task and determine at least two derived tasks associated with the request analysis task; a request sending module, configured to send a tracking information acquisition request to the servers corresponding to the at least two derived tasks according to the request analysis task; an information receiving module, configured to receive link tracking information fed back by the servers corresponding to the at least two derived tasks in response to the tracking information acquisition request, wherein the link tracking information is stored in a data storage structure corresponding to each server; and a task execution module, configured to construct distributed link tracking information based on the link tracking information and execute the request analysis task. According to a fifth aspect of an embodiment of the present disclosure, a request processing system is provided, comprising a target server and an associated server, comprising: the target server, for calling a link tracking program in response to a service request to extract request path information in the service request, and determining a target derived task corresponding to the target server among at least two derived tasks associated with the service request; constructing a key-value pair according to a target task identifier of the target derived task and the request path information, and storing the key-value pair in a data storage structure of the link tracking program; when executing an associated derived task corresponding to the associated server among the at least two derived tasks, determining an associated task identifier corresponding to the associated derived task according to a task relationship between the at least two derived tasks; querying the data storage structure based on the associated task identifier, creating an associated service request carrying associated request path information according to the query result, and sending it to the associated server; wherein the key-value pair recorded in the data storage structure is used to construct distributed link tracking information; the associated server, for executing an associated request processing task in response to the associated service request. According to a sixth aspect of an embodiment of the present disclosure, a computing device is provided, comprising: a memory and a processor; the memory is configured to store computer-executable instructions, and the processor is configured to execute the computer-executable instructions, wherein the computer-executable instructions, when executed by the processor, implement the steps of the aforementioned request processing method or task execution method. According to a seventh aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, the medium storing computer-executable instructions, wherein the instructions, when executed by the processor, implement the steps of the aforementioned request processing method or task execution method. According to an eighth aspect of an embodiment of the present disclosure, a computer program product is provided, comprising a computer program or instructions, wherein the computer program or instructions, when executed by the processor, implement the steps of the aforementioned request processing method or task execution method.The request processing method provided in this embodiment enables any server in a distributed system to record tracing information during runtime, enabling direct access to tracing information and the construction of distributed link tracing information during fault location, thereby rapidly and accurately completing fault location analysis. In specific implementations, the target server can, in response to the server invoking the link tracing program, extract request path information from the service request and determine the target derived task corresponding to the target server among the at least two derived tasks associated with the service request. A key-value pair can then be constructed based on the target task identifier and request path information of the target derived task, and stored in the data storage structure of the link tracing program. The request path information associated with the service request is persisted in the data storage structure, completing the recording of tracing information associated with the service request on the target server. Furthermore, by storing the request path information in the data storage structure, the target server can achieve non-intrusiveness to the services provided by the target server, ensuring that the path information is recorded while maintaining service stability. Typically, a request requires the collaborative completion of multiple servers. To ensure that the links associated with the request can be accurately retrieved during the fault location phase, the associated task identifier corresponding to the associated derived task can be determined based on the task relationship between the at least two derived tasks while executing the associated derived task corresponding to the associated server. A data storage structure is then queried based on the associated task identifier to create a related service request carrying the associated request path information based on the query result and send it to the associated server. The request sent to the associated server carries the associated request path information created by the current server, and the associated server then performs the same request path information storage operation as the target server. Consequently, the request path information associated with the request is stored in the data storage structure corresponding to the servers involved in the link. This allows the distributed link tracing information associated with the request to be determined by reading the request path information from the data storage structure during the fault location phase, enabling rapid and accurate fault location and minimizing the impact of the fault on the distributed system.BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic diagram of a request processing method provided by one embodiment of the present disclosure; Figure 2 is a flow chart of a request processing method provided by one embodiment of the present disclosure; Figure 3 is a schematic diagram of a service request structure in a request processing method provided by one embodiment of the present disclosure; Figure 4 is a schematic diagram of transparent transmission of request path information in a request processing method provided by one embodiment of the present disclosure; Figure 5 is a flow chart of the processing process of a request processing method provided by one embodiment of the present disclosure; Figure 6 is a schematic diagram of the structure of a request processing device provided by one embodiment of the present disclosure; Figure 7 is a flow chart of a task execution method provided by one embodiment of the present disclosure; Figure 8 is a schematic diagram of the structure of a task execution device provided by one embodiment of the present disclosure; Figure 9 is a schematic diagram of the structure of a request processing system provided by one embodiment of the present disclosure; and Figure 10 is a block diagram of the structure of a computing device provided by one embodiment of the present disclosure. The following description sets forth numerous specific details to facilitate a thorough understanding of the present disclosure. However, the present disclosure can be implemented in many other ways than those described herein, and those skilled in the art may make similar generalizations without departing from the scope of the present disclosure. Therefore, the present disclosure is not limited to the specific implementations disclosed below. The terminology used in one or more embodiments of the present disclosure is for the purpose of describing specific embodiments only and is not intended to limit the present disclosure. As used in one or more embodiments of the present disclosure and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of the present disclosure refers to and encompasses any and all possible combinations of one or more of the associated listed items. It should be understood that although the terms first, second, etc. may be employed in one or more embodiments of the present disclosure to describe various information, such information should not be limited to these terms. These terms are merely used to distinguish information of the same type from one another. For example, the first could be referred to as the second, and similarly, the second could be referred to as the first, without departing from the scope of one or more embodiments of the present disclosure. Depending on the context, the word "if," as used herein, could be interpreted as "when..." or "when..." or "in response to determining."Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in one or more embodiments of the present disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or deny. First, the terms used in one or more embodiments of the present disclosure are explained. Distributed system: A system consisting of a group of computer nodes that communicate over a network and coordinate to complete a common task. Distributed link tracing system: In a distributed system, a single external request often requires multiple internal modules, multiple middleware, and multiple machines to call each other. When a module experiences a performance bottleneck or fails, other modules with which it has a call relationship may also fail or behave abnormally. This makes fault location and analysis complex and difficult. A distributed tracing system can locate each specific request link, making it easy to trace the request link and, in turn, locate and analyze the performance bottlenecks of each module. Trace: In a distributed link tracing system, a trace represents the request path of a user request. The basic unit in each trace is a span, which may be composed of multiple spans. A span represents an operation completed between requests, such as service A calling service B. The causal relationship between spans is recorded through the parent span. Each trace and span has a unique identifier (ID). eBPF: eBPF allows developers to execute user-defined programs in the Linux kernel, supporting developers to implement extended kernel functionality without intruding on user code. eBPF defines multiple program types. eBPF programs are attached to designated locations (hook points) in the kernel. Whenever a program runs to this location, the attached eBPF program is triggered to execute. eBPF can be used for operations such as filtering traffic, traffic classification, network classification, and modifying socket settings. eBPF programs use eBPF maps to store data status, statistical information, and more. eBPF Maps can be accessed by BPF programs as well as by userspace. Therefore, they can be used to implement information sharing between eBPF programs and between userspace and eBPF programs.Asynchronous thread pool service model: When a server processes a request from the previous hop, it needs to request the next hop to complete the response. In a thread pool scenario, the currently executing task spawns a subtask to send a request to the next hop and then blocks. After the response arrives from the next hop, the subtask completes and then proceeds with its own processing logic. Because tasks are fine-grained scheduling objects abstracted at the user level, created tasks are queued and scheduled to idle threads in the thread pool for execution. After completing the current task, the thread pool thread is recycled back to the thread pool to await the next task scheduling. Different tasks can be scheduled to the same thread.

[0002] HTTP Protocol: The HTTP protocol (HyperText Transfer Protocol) is an application layer transport protocol based on the TCP protocol. Simply put, it is a set of rules for data transmission between clients and servers. The data format sent in an HTTP request mainly consists of three parts: a request line, a message header, and a request body. The message header consists of a series of key-value pairs, allowing the client to send additional information or client information to the server. This disclosure provides a request processing method, which also involves a request processing device, a request processing system, a task execution method, a task execution device, a computing device, a computer-readable storage medium, and a computer program product, each of which is described in detail in the following embodiments. Referring to the schematic diagram shown in Figure 1, the request processing method provided in this embodiment is designed to enable any server in a distributed system to record tracing information during operation, so that tracing information can be directly read and distributed link tracing information can be constructed during fault location, thereby quickly and accurately completing fault location analysis. In a specific implementation, the target server can extract the request path information from the service request in response to the server invoking the link tracking program, and determine the target derived task corresponding to the target server among the at least two derived tasks associated with the service request. At this point, a key-value pair can be constructed based on the target task identifier of the target derived task and the request path information, and the key-value pair can be stored in the data storage structure of the link tracking program. This allows the request path information associated with the service request to be persisted in the data storage structure, thereby completing the recording of tracking information associated with the service request on the target server. Furthermore, by storing the request path information in the data storage structure, the service items provided by the target server can be non-intrusive, thereby ensuring that the path information is recorded while maintaining the stability of the service items. Typically, a request needs to rely on multiple servers to complete. To ensure that the link associated with the request can be accurately obtained during the fault location phase, when executing the associated derived task corresponding to the associated server among at least two derived tasks, the associated task identifier corresponding to the associated derived task can be determined based on the task relationship of the at least two derived tasks. Thereafter, the data storage structure is queried based on the associated task identifier to create an associated service request carrying associated request path information based on the query result and send it to the associated server. The request sent to the associated server carries the associated request path information created by the current server, and the associated server will then perform the same request path information storage operation as the target server.This ensures that the request path information associated with the request is stored in the data storage structure corresponding to the servers involved in the link. This allows, during the fault location phase, to determine the distributed link tracing information associated with the request by reading the request path information from the data storage structure, thereby quickly and accurately locating the fault and reducing the impact of the fault on the distributed system. Referring to Figure 2, Figure 2 shows a flowchart of a request processing method provided according to an embodiment of the present disclosure. This method, applied to a target server, specifically includes the following steps: Step S202: In response to a service request, a link tracing program is invoked to extract the request path information from the service request, and a target derived task corresponding to the target server among at least two derived tasks associated with the service request is determined. The request processing method provided in this embodiment can be applied to any server in a distributed system, and such server can be understood as a server employing an asynchronous thread pool service model. Accordingly, a link tracer specifically refers to a tracer program running on each server in a distributed system. This program is used to generate request path information in the server's kernel for request tracing. It can also persist the request path information based on the program's data storage results, allowing it to be read from this structure during troubleshooting. Furthermore, the link tracer program can be attached to network send and receive functions within the server's host kernel, enabling it to run without intruding into the source code. In specific implementations, the link tracer program can be implemented using an eBPF program. Accordingly, a service request specifically refers to a request received by a target server. This request can be sent from an upstream server to the target server or from a downstream server to the target server. This request is used to activate the service function provided by the target server and execute the related service function tasks based on the request, thus serving as a response to the request. It should be noted that in a distributed system, some services require the cooperation of multiple target servers to respond to user requests. Therefore, the target server can be any one of the multiple target servers, and the service request received by the server is a partial operation in response to the user request. Accordingly, request path information specifically refers to the flow information recorded in the service request that describes the responses of each server to the user request. The request path information recorded in the service request received by the target server is generated by the server that sends the service request to the target server. In specific implementation, the request path information can be implemented using a trace mechanism. The trace mechanism can represent the request path corresponding to the user request, thereby recording the link relationship between related target servers in the distributed system for use in the fault location phase.Accordingly, a derived task specifically refers to a task associated with a user request. When a server processes a user request, it typically derives multiple tasks to simultaneously complete the response to the request, such as requesting an upstream service or reading a file. Each derived task is a task that the server must perform to respond to the user request. Different servers can have multiple derived tasks, and each server needs to execute related derived tasks to respond to the user request. Accordingly, a target derived task is the derived task of at least two derived tasks corresponding to the target server. For example, if a user request requires server A to call server B and then jointly complete the corresponding operation, server A and server B will each generate a corresponding derived task during the response process, completing the corresponding operation by executing their respective derived tasks. Based on this, when the server processes a user request, it typically spawns multiple tasks to simultaneously complete the request response. These spawned tasks are placed in the thread pool's task queue, awaiting execution by idle threads in the thread pool. After a thread completes a task, it is recycled back into the thread pool, awaiting the next scheduling opportunity. This reduces the overhead of frequent thread creation and destruction in asynchronous thread scenarios. However, due to thread recycling, tasks corresponding to multiple requests may be scheduled to the same thread. If thread identifiers are used as the basis for transparent transmission between servers in a distributed system, thread identifiers may be passed to unrelated servers, resulting in erroneous request correlation results. Consequently, it is difficult to accurately locate the root cause based on these erroneous request correlation results during troubleshooting. Therefore, in scenarios targeting asynchronous thread pool service models, to ensure correlation accuracy, a link tracer can be used to insert request path information into requests. When any server receives a previous request, it can extract and store the request path information. When sending the next request, it inserts the generated request path information into the request before sending it. This allows request path information to be inserted and transparently transmitted without requiring any source code instrumentation, supporting troubleshooting. Furthermore, when calling the link tracer to extract request path information from a request, to prevent the program from intruding into the target server's source code and thus affecting service stability, the program can be pre-mounted on the kernel network.In this embodiment, the specific implementation is as follows: receiving a service request submitted by a user for a target service; invoking a link tracing program based on the service request, wherein the link tracing program is mounted on a transceiver function associated with a kernel network node of the target server; parsing the service request using the link tracing program, and extracting request path information from the message header of the service request based on the parsing result. Specifically, the user refers to a user using the target service, and the target service refers to a service that relies on multiple servers in a distributed system. Such services may include user data query, payment, shopping, image processing, text processing, etc. This embodiment does not impose any limitations. Accordingly, the kernel network node refers to the kernel network of the host local to the target server. By binding the link tracing program to the transceiver function associated with the kernel network node, the transceiver function can be invoked when the server sends or receives requests from other servers in the distributed system. This in turn activates the link tracing program bound to the transceiver function to record the request path information. A service request specifically refers to a request based on the HTTP protocol. This request consists of a request line, a message header, and a request body. The message header, composed of a series of key-value pairs, allows the client to send additional information or client information to the server. Therefore, adding request path information to the message header enables the transmission of this additional information—the request path information—between different servers in a distributed system. Based on this, when a user receives a service request for a target service, it indicates that the target server needs to respond to the service request to enable the user to utilize the service functionality provided by the target service. In response to the service request, a link tracking program attached to the send / receive function associated with the target server's kernel network node can be invoked. Since the link tracking program is bound to the send / receive function, it can be invoked upon receipt of the service request. After parsing the service request using the link tracking program, the request path information can be extracted from the message header of the service request based on the parsing results. This facilitates the subsequent recording of the request path information, along with the link information corresponding to the request, into the program's corresponding service storage structure for use during troubleshooting. In practical applications, to enable the insertion and parsing of request path information (trace context) between servers in a distributed system, servers can attach a link tracing program (eBPF program) to send and receive-related functions in the host kernel network, such as sock_recvmsg. When receiving a request from the previous hop, the eBPF program extracts and stores the trace context from the request header.When sending a request to the next hop, a sub-trace context is generated and then inserted into the request header before being sent to the next corresponding server. This allows trace context insertion and parsing without requiring any source code instrumentation, and is transparent to the user. As shown in Figure 3, for egress, after submitting a request based on the HTTP protocol, the eBPF program generates the trace context, inserts it into the request message header, and sends it to the target server. For ingress, upon receiving a request carrying a trace context, the eBPF program parses the message header to extract the trace context for subsequent use. The trace context includes the trace ID (16 bytes), the span ID (8 bytes), and the parent ID (8 bytes). oThis embodiment uses an HTTP server implemented in the Golang language net / http as an example to illustrate the request processing method. For other languages, such as Java, C++, and Python, please refer to the same or corresponding descriptions in this embodiment. It should be noted that for Java and Python, the thread pool model uses a task as the scheduling unit, which is equivalent to a Golang coroutine. Their thread pool scheduling model is consistent with Golang, and the relevant descriptions can be found in this embodiment. Specifically, in server A of the distributed system, the Golang program executes in the thread pool model using coroutines as the unit. The schematic diagram shown in Figure 4 shows the coroutines (partial) and their parent-child tree that will be generated by the program's corresponding code. After receiving a user request, the program executes the serveHTTP coroutine to process the request, requesting upstream services. Specifically, the writeloop coroutine performs the request sending operation. On this basis, when server A receives a user request, it is processed by the serveHTTP coroutine and the eBPF program bound to the receive-related function is called to extract the trace context recorded in the message header from the user request. Furthermore, since the user request needs to be processed by the serveHTTP coroutine, the task currently required to be executed by server A is determined to correspond to the serveHTTP coroutine, facilitating the subsequent storage and transparent transmission of the trace context based on this information. In summary, by binding the link tracking program to the host kernel's network-related transceiver functions, the target server can promptly call the link tracking program to extract the request path information from the request after the transceiver function receives the request, allowing the request path information to be used to complete the tracing of the request link during the fault location phase. In step S204, a key-value pair is constructed based on the target task identifier of the target derived task and the request path information, and the key-value pair is stored in the link tracking program's data storage structure. Specifically, after the call link tracking program extracts the request path information from the service request, further, considering that the request path information is descriptive information that records and tracks the flow link of the user request, in order to make the request path information available during the fault location phase and to cope with the situation where one thread corresponds to multiple tasks in the asynchronous thread pool scenario, the target task identifier of the target derived task can be determined first; then, a key-value pair can be constructed using the task identifier as the key and the request path information as the value; and the key-value pair can be stored in the data storage structure of the link tracking program.This implementation uses the target task identifier of the target derived task, which uniquely represents the service request, as the key and the request path information as the value, stored in the link tracing program's data storage structure. This allows, during the fault location phase, the associated derived task to be determined based on the user request being analyzed. Subsequently, based on the derived task identifier, the corresponding request path information can be directly read from the corresponding data storage structure of each server, enabling rapid and accurate identification of the link corresponding to the user request, thereby rapidly completing fault location processing on that link. The target task identifier specifically refers to the unique identifier corresponding to the target derived task, and this task identifier is non-duplicate. Accordingly, the data storage structure specifically refers to a structure that stores information in the form of key-value pairs. This data storage structure can be used to store data status, statistical information, request path information, and more. When the link tracing program is an eBPF program, the data storage structure is the eBPF program's Map. Request path information is stored in the eBPF program's Map and can be directly read and used according to the task identifier during the troubleshooting phase. This ensures that the read request path information is associated with the user request to be analyzed during the troubleshooting phase, avoiding the introduction of redundant request path information that could affect troubleshooting accuracy and efficiency. Specifically, to enable each server to record path information associated with user requests, a key-value pair can be constructed using the task ID of the currently executing task as the key and the trace context extracted from the request as the value. This pair is then stored in the eBPF program's Map. During the troubleshooting phase, the trace context can be read from the Map to determine the path corresponding to the user request, enabling rapid troubleshooting. Continuing with the previous example, after extracting the trace context recorded in the message header from the user request and determining that the task currently being executed by server A corresponds to the serveHTTP coroutine, the serveHTTP coroutine number (the task ID corresponding to the currently executing task) can be used as the key and the trace context as the value to be stored in the eBPF program's Map. During fault location, the trace context can be read from server A's eBPF program Map to determine the path information corresponding to the user request, rapidly completing fault location. Furthermore, once the target server's link tracer completes storing the task identifier and request path information, the request trace information corresponding to the service request has been recorded. The target server can then execute the target derived task to respond to the service request.In this embodiment, the specific implementation is as follows: adding the target derived task to the task queue of the asynchronous thread pool, and selecting a target thread from the asynchronous thread pool for the target derived task; establishing a scheduling relationship between the target thread and the target derived task; and, if the target derived task in the task queue is in the execution state, assigning the target derived task to the target thread based on the scheduling relationship for execution. Specifically, the task queue refers to the queue corresponding to the asynchronous thread pool that stores tasks to be executed from different servers. This queue complies with the first-in, first-out rule, and tasks entering the queue are sorted in the order of entry, so that the asynchronous thread pool can assign threads to sequentially execute the tasks in the task queue. Accordingly, the target thread refers to the thread selected from the asynchronous thread pool to execute the target derived task. Accordingly, the scheduling relationship is the task execution scheduling relationship between the target thread and the target derived task. Based on this scheduling relationship, tasks can be assigned to the target thread during the target derived task execution phase, thereby enabling the target thread to execute the target derived task. Based on this, while storing the request path information, the target derived task is also added to the asynchronous thread pool's task queue to respond to the service request without affecting the server's execution of the target derived task. A target thread is then selected from the asynchronous thread pool for the target derived task. A scheduling relationship is then established between the target thread and the target derived task. If the target derived task in the task queue is in the execution state, the target derived task can be directly assigned to the target thread based on the scheduling relationship for execution, with the task execution result serving as the response to the service request. In specific implementations, each server in the distributed system that responds to a user request will perform the aforementioned operations. Once each server has completed executing the derived task corresponding to its respective service request, the service processing for the user request is complete. For example, if a user needs to query their deposit limit, server A in the distributed system authenticates the user. Once authentication is successful, server B is called to determine the user's information and query the deposit limit. Servers A and B will then use the aforementioned process to complete the target thread's execution of their respective derived tasks and, upon completion, provide the user with information related to the deposit limit. Step S206: When executing the associated derived task corresponding to the associated server among the at least two derived tasks, determine the associated task identifier corresponding to the associated derived task according to the task relationship between the at least two derived tasks.Specifically, after the request path information is stored in the data storage structure corresponding to the link tracking program, the target derived task corresponding to the target server will continue to execute. When the execution reaches the associated derived task corresponding to the associated server among at least two derived tasks, it indicates that a service request for executing the derived task needs to be sent to the associated server. To ensure that the associated server executes the associated derived task upon receiving the service request, the request path information corresponding to the request can also be stored in the associated server's data storage structure, thereby reflecting the flow of the user request. Therefore, it is necessary to create an associated service request carrying the associated request path information and then send it to the associated server. During the creation of the associated service request carrying the associated request path information, to ensure that the created associated request path information accurately records the path information corresponding to the request, the associated task identifier corresponding to the associated derived task can be first determined based on the task relationship between the at least two derived tasks. The data storage structure of the link tracking program can then be queried based on the task identifier. Based on the query result, an associated service request carrying the associated request path information is created and then sent to record the path information corresponding to the request. Here, an associated server specifically refers to a server in the same distributed system as the target server. This server must cooperate with the target server to execute different derived tasks in order to respond to user requests. Accordingly, an associated derived task specifically refers to a derived task from at least two derived tasks that corresponds to the associated server. The execution of this task requires sending a new service request to the associated derived task, so that the associated server can execute the corresponding function based on the new service request to respond to the user request. Accordingly, a task relationship specifically refers to the relationship between the at least two derived tasks. Because servers in a distributed system have a request transitive relationship, the derived tasks can determine the task relationship based on this transitive relationship, thereby creating request path information based on this relationship. During the fault location phase, the request path information can be read to determine the transitive relationship between servers, thereby improving fault location efficiency and accuracy. Furthermore, when determining the associated task identifier, it is considered that the identifier is the basis for generating the associated request path information and can ensure that the associated request path information records the traceability information. Tasks with a parent-child relationship among derived tasks are usually accompanied by a continuous request path. Therefore, the task identifiers of adjacent derived tasks can be determined in combination with the parent-child task relationship. Based on this, the associated task identifier is determined so that the associated request path information can be obtained in subsequent queries of the data storage structure.In this embodiment, the specific implementation is as follows: The link tracing program is used to obtain the task relationship between the at least two derived tasks; based on the task relationship, adjacent derived tasks are determined from the at least two derived tasks that have a parent-child relationship with the associated derived task; and the associated task identifier is determined based on the first task identifier of the associated derived task and the second task identifier of the adjacent derived task. Specifically, a parent-child task relationship refers to a relationship in which the associated derived task has an upper adjacent or lower adjacent execution order. Accordingly, an adjacent derived task refers to a derived task from the at least two derived tasks that has an adjacent task execution relationship with the associated derived task. Accordingly, the first task identifier refers to a unique identifier corresponding to the associated derived task, and the second task identifier refers to a unique identifier corresponding to the adjacent derived task. Based on this, to transparently transmit request path information between servers in a distributed system, the link tracing program can be used to obtain the task relationship between the at least two derived tasks to determine the subordinate relationship between the derived tasks. Then, based on the task relationship, adjacent derived tasks that have a parent-child relationship with the associated derived task can be identified from among the at least two derived tasks. If adjacent derived tasks are identified, this indicates that the request path information can be reflected based on the task relationship. Therefore, to reflect this information in the request path information, the associated task identifier can be first determined based on the first task identifier of the associated derived task and the second task identifier of the adjacent derived task. This can then be used to query the data storage structure based on the associated task identifier to determine the request path information to be sent to the associated derived task. Furthermore, determining the associated task identifier based on the first and second task identifiers effectively checks whether the request path information corresponding to the identifier exists in the data storage structure. If not, a valid task identifier can be selected for subsequent reading of the data storage structure. In this embodiment, the specific implementation is as follows: The first task identifier of the associated derived task is determined, and the data storage structure is queried based on the first task identifier. If, based on the query result, the data storage structure determines that the first request path information associated with the first task identifier does not exist in the data storage structure, the second task identifier is used as the associated task identifier. Based on this, after determining the first task identifier corresponding to the associated derived task and the second task identifier corresponding to the adjacent derived task, the data storage structure can be queried based on the first task identifier. If the query result determines that the first request path information associated with the first task identifier exists in the data storage structure, it means that the request path information required to be carried by the downstream request has been stored in the data storage structure. In this case, the request path information can be directly used to create an associated service request to be sent to the associated server.If the query results determine that the first request path information associated with the first task identifier does not exist in the data storage structure, this indicates that the request path information to be sent to the associated server has not yet been created. Therefore, the second task identifier can be used as the associated task identifier. After querying the data storage structure based on this identifier, the associated request path information for the associated server can be created based on the query results, ensuring that the corresponding request path information is recorded. In actual applications, since the server is configured with an eBPF program, the eBPF program can not only monitor the task creation process in the server, but also obtain the parent-child relationship between tasks during this process. It can also monitor the process of scheduling tasks to threads, and obtain the scheduling relationship between tasks during this process. Based on this, when the target server needs to send a request to an upstream server, it can directly query the eBPF program map based on the task ID of the currently executing derived task and the task ID of the parent derived task corresponding to the derived task. The queried trace context is used as the parent trace context of the parent derived task. A child trace context is then created for the derived task and used as the associated request path information corresponding to the associated server. This is then inserted into the header of the upstream request as a key-value pair. This transparently transmits the trace context, indicating the causal relationship between the two requests, allowing the trace context to be read and used during the troubleshooting phase. In summary, by combining the parent-child task relationship to determine the adjacent derived tasks corresponding to the associated derived task in at least two derived tasks and loading the task identifiers of both tasks, the request flow can be reflected through the task relationship. Furthermore, since the request path information is stored in the data storage structure based on the task identifier, the task relationship can better ensure the accuracy of the associated task identifier, enabling the subsequent creation of associated request path information based on the identifier. Step S208: query the data storage structure based on the associated task identifier, create an associated service request carrying the associated request path information according to the query result, and send it to the associated server; wherein the key-value pairs recorded in the data storage structure are used to construct distributed link tracking information.Specifically, after determining the task identifier corresponding to the associated derived task, in order to create associated request path information for the associated server to record the flow path of the user request, the associated task identifier can be used to query the data storage structure. This allows the creation of an associated service request carrying the associated request path information based on the query result. This request can then be sent to the associated server, allowing the associated server to continue executing the corresponding task in response to the associated service request. The processing of the associated server after receiving the associated service request is similar to the processing logic of the target server in this embodiment. For similar or corresponding descriptions, please refer to the description of this embodiment, and this embodiment will not be elaborated on here. The associated service request and the associated request path information both refer to the service request and request path information corresponding to the associated server. Accordingly, the distributed link tracing information specifically refers to data that reflects the path information corresponding to the user request. During the fault location phase, this information can be used to determine the link corresponding to the user request and identify the faulty node within the link for processing. Furthermore, when creating a correlation service request, the data storage structure is queried and correlation request path information for the corresponding correlation server is constructed based on the query structure. This information also records descriptive information related to the request link. This ensures that each server corresponding to the user request can record this information in its corresponding data storage structure. This allows for access to this information from each server's data storage structure during fault location. In this embodiment, the specific implementation is as follows: the data storage structure is queried based on the correlation task identifier, and the request path information is determined based on the query result; correlation request path information is created based on the request path information; a correlation service request is created corresponding to the correlation server, the correlation request path information is added to the message header of the correlation service request, and the request is sent to the correlation server. The correlation server and the target service belong to a distributed system. Based on this, when creating a service request for a corresponding server, the data storage structure can be queried based on the associated task ID. Since the data storage structure records the request path information corresponding to the task ID, and the request path information to be sent to the associated server must be associated with it, the request path information can be determined based on the query result. Based on the request path information, the associated request path information can be created, along with the associated service request for the associated server. The associated request path information is then added to the message header of the associated service request and sent to the associated server. Continuing with the above example, when the function corresponding to server A reaches a specified stage, a child coroutine is spawned to execute the downstream request. This means that a request needs to be sent to the downstream server.During this process, the upstream request is sent via the WRITELOOP coroutine, and the request needs to have a trace context inserted. Therefore, Server A can query the corresponding coroutine number (task ID) through the WRITELOOP coroutine and, based on this coroutine number, check whether a corresponding trace exists in the eBPF program's map. If so, Server A has already stored the trace context carried by the downstream request in the map. Therefore, Server A can read the trace context from the map and insert it into the upstream request. The upstream request can then be sent via the WRITELOOP coroutine. If not, it indicates that the trace context corresponding to the coroutine number does not exist in the map. Therefore, the parent coroutine, http.Get0, can be queried along the parent-child tree to find the trace context held by the serveHTTP coroutine. Based on this, a child trace context is created and inserted into the message header of the upstream request. The upstream request carrying the child trace context is then sent to Server B via the WRITELOOP coroutine. This enables server B to respond to user-requested operations based on this request. In summary, when creating the associated request path information carried in the associated service request, in order to record the request flow information through the associated path information, the associated task identifier can be used to query the data storage results. The associated request path information can then be created based on the request path information read from the data storage structure. This ensures that the request path information sent to the associated server represents the request path for use during the fault location phase. Furthermore, the task relationship between at least two derived tasks affects the creation of the associated request path information. Therefore, determining the task relationship can be achieved through a benchmark subroutine. In this embodiment, the specific implementation is as follows: a benchmark subroutine is loaded through the link tracking program and mounted to the associated function corresponding to the associated derived task. When the associated derived task is executed and the associated function is called, the benchmark subroutine is launched to obtain the task relationship. Specifically, the benchmark subroutine refers to a subroutine capable of obtaining task relationships, which can be an uprobe program. Correspondingly, the associated function refers to a function that needs to be launched when the associated derived task is executed.Based on this, during the task relationship determination phase, a benchmark subroutine can be loaded through a link tracing program and mounted to the associated function corresponding to the associated derived task. This allows the benchmark subroutine to be launched when the associated derived task is executed and the associated function is called, obtaining the task relationship and performing subsequent processing based on the task relationship. Continuing with the previous example, since the readIoop and writeIoop coroutines are associated with persistent connections (the sending and receiving coroutines corresponding to a connection are fixed), a persistent connection may be used by multiple different http.Get coroutines. To address this issue, to ensure the correct parent-child relationship between coroutines and accurately transmit trace context, an uprobe program can be mounted to the writeIoop and readIoop functions through eBPF. This establishes the ownership relationship between the acquired connection and its writeIoop and readIoop coroutines. Subsequently, the uprobe program is mounted to the roundTrip user function to determine the connection currently used by the http.Get coroutine. Then, based on the ownership relationship, the corresponding writeloop and readloop coroutines can be found, and their parent coroutines can be updated to the current http.Get coroutine, thereby ensuring the correctness of the coroutine parent-child relationship. On this basis, the trace context can be transferred. In summary, by combining the benchmark subroutine to determine the task relationship, the accuracy of the task relationship can be effectively ensured. Based on this, transparent transmission of request path information can avoid inaccurate fault location caused by information errors. In addition, during the request analysis phase, link tracking information can be read from the data storage structure corresponding to each server. In this embodiment, the specific implementation method is as follows: obtaining a request analysis task, and sending a tracking information acquisition request to the servers corresponding to the at least two derived tasks based on the request analysis task; receiving link tracking information fed back by the servers corresponding to the at least two derived tasks in response to the tracking information acquisition request, wherein the link tracking information is stored in the data storage structure corresponding to each server; constructing the distributed link tracking information based on the link tracking information, and executing the request analysis task. Specifically, the request analysis task refers to the task of tracking user requests during the fault location phase, which is used to quickly locate the fault location after determining the path corresponding to the user request, so as to resolve the fault and reduce the impact.Accordingly, the tracing information acquisition request specifically refers to a request sent to the servers corresponding to at least two derived tasks to obtain request path information stored in the data storage structure. Based on this, during the fault location phase, to quickly locate the fault, a request analysis task can be first acquired and, based on the request analysis task, a tracing information acquisition request can be sent to the servers corresponding to at least two derived tasks. Link tracing information, which is fed back by the servers corresponding to the at least two derived tasks in response to the tracing information acquisition request, can then be received and stored in the data storage structure corresponding to each server. Distributed link tracing information can then be constructed based on the link tracing information. The request analysis task can then be executed based on this information to determine the fault location based on the distributed link tracing information. For example, if a distributed system fault occurs and operations personnel need to perform request-level root cause location, a root cause location request can be created and sent to each server in the distributed system. The trace context stored in the eBPF program map for each server can then be received. The path information of the user request at the request level to be located can be determined by analyzing the trace context. Based on this path information, the faulty node causing the problem can be quickly identified, alerting operations and maintenance personnel to quickly resolve the problem, minimizing the impact on the distributed system's operations. The request processing method provided in this embodiment enables any server in the distributed system to record tracking information during operation, enabling direct access to this information during the fault location phase to construct distributed link tracking information, thereby rapidly and accurately completing fault location analysis. In specific implementations, the target server can, in response to the server invoking the link tracking program, extract the request path information from the service request and determine the target derived task corresponding to the target server among the at least two derived tasks associated with the service request. A key-value pair can then be constructed based on the target task identifier and the request path information of the target derived task, and stored in the link tracking program's data storage structure. The request path information associated with the service request is persisted in the data storage structure, completing the recording of tracking information associated with the service request on the target server. Furthermore, by storing the request path information in the data storage structure, the target server can achieve non-intrusive access to the services provided by the target server, ensuring that the path information is recorded while maintaining service stability.Typically, a request requires the collaborative completion of multiple servers. To ensure that the link associated with the request can be accurately retrieved during the fault location phase, the associated task identifier corresponding to the associated derived task can be determined based on the task relationship between the at least two derived tasks, while executing the associated derived task corresponding to the associated server. The associated task identifier is then queried in a data storage structure based on the query result to create an associated service request carrying associated request path information and send it to the associated server. The request sent to the associated server carries the associated request path information created by the current server, and the associated server then performs the same request path information storage operation as the target server. Consequently, the request path information associated with the request is stored in the data storage structure corresponding to the servers involved in the link. During the fault location phase, the request path information in the data storage structure can be read to determine the distributed link tracing information associated with the request, enabling rapid and accurate fault location and reducing the impact of the fault on the distributed system. The request processing method provided by the present disclosure will be further described below, using the application of the request processing method in a distributed system as an example, with reference to FIG5 . FIG5 shows a flowchart of a request processing method provided by one embodiment of the present disclosure, specifically including the following steps. Step S502: Receive a service request submitted by a user for a target service. Step S504: Invoke a link tracking program based on the service request. The link tracking program is installed on the transceiver function associated with the kernel network node of the target server. Step S506: Analyze the service request using the link tracking program and extract request path information from the message header of the service request based on the analysis results. Step S508: Determine, in response to the service request, the target derived task corresponding to the target server among the at least two derived tasks associated with the service request. This embodiment uses an HTTP server implemented in the Golang language net / http as an example to illustrate the request processing method. For other languages, such as Java, C++, and Python, please refer to the same or corresponding descriptions in this embodiment. It should be noted that for Java and Python, the scheduling unit of the thread pool model is a task, which is equivalent to a Golang coroutine. Their thread pool scheduling model is consistent with Golang, and the relevant descriptions can be found in this embodiment. Specifically, on server A in the distributed system, the Golang program executes in thread pool mode, using coroutines as units. Figure 4 shows the coroutines (parts) and their parent-child tree that are actually generated by the program's corresponding code.After receiving a user request, the program executes the s (serveHTTP) coroutine to process the request. This processing function can be function 1 (e.g., BackgroundReader), function 2, ..., function n (e.g., http.Get()), which is used to request the upstream service. Based on processing function n, the w (writeloop) coroutine is called to send the request. Upon receiving the user request, server A processes it through the serveHTTP coroutine, invoking the eBPF program bound to the receiving function to extract the trace context recorded in the message header from the user request. Furthermore, since the user request must be processed by the serveHTTP coroutine, the task currently executed by server A is determined to correspond to the serveHTTP coroutine, facilitating subsequent storage and transparent transmission of the trace context based on this information. Step S510: Determine the target task identifier of the target derived task; construct a key-value pair using the task identifier as the key and the request path information as the value. Step S512: Store the key-value pair in the link tracking program's data storage structure. Continuing with the above example, if the trace context recorded in the message header is extracted from the user request and it is determined that the task currently executed by server A corresponds to the serveHTTP coroutine, the serveHTTP coroutine number (the task ID corresponding to the currently executed task) can be used as the key and the trace context as the value to be stored in the eBPF program's Map. During fault location, the trace context can be read from server A's eBPF program Map to determine the path information corresponding to the user request, quickly completing the fault location process. In step S514, when executing the associated derived task corresponding to the associated server among the at least two derived tasks, the link tracing program is used to obtain the task relationship between the at least two derived tasks. In step S516, based on the task relationship, adjacent derived tasks that have a parent-child relationship with the associated derived task are determined in the at least two derived tasks. In step S518, the associated task identifier is determined based on the first task identifier of the associated derived task and the second task identifier of the adjacent derived task. In step S520, the data storage structure is queried based on the associated task identifier, and the request path information is determined based on the query result. Step S522: Create association request path information based on the request path information. Step S524: Create an association service request corresponding to the association server, add the association request path information to the message header of the association service request, and send it to the association server.The associated server and target service belong to a distributed system, and the key-value pairs recorded in the data storage structure are used to construct distributed link tracing information. Continuing with the above example, when the function corresponding to server A reaches a specified stage, a child coroutine is derived to execute a downstream request. This means that a request needs to be sent to the downstream server. During this process, the upstream request is sent via the WRITELOOP coroutine, and the sent request requires the insertion of a trace context. Therefore, server A can query the corresponding coroutine number (task ID) through the WRITELOOP coroutine and, based on this coroutine number, query the eBPF program's map for a corresponding trace. If so, server A has stored the trace context carried by the downstream request in the map. Therefore, server A can read the trace context from the map and insert it into the upstream request. Finally, the WRITELOOP coroutine can execute the upstream request. If it does not exist, it means that there is no trace context corresponding to the coroutine number in the Map. Therefore, you can query its parent coroutine http.Get 0 along the parent-child tree, and then query the trace context held by the serveHTTP coroutine. On this basis, create a child trace context, then insert the child trace context into the message header of the upstream request, and send the upstream request carrying the child trace context to the B server through the write loop coroutine. This allows the B server to respond to the user's request-related operations based on the request. The request processing method provided in this embodiment is designed to support any server in a distributed system to record trace information during the running phase, to support direct reading of trace information during the fault location phase to construct distributed link trace information, thereby quickly and accurately completing fault location analysis and processing. In a specific implementation, the target server can extract the request path information from the service request in response to the server invoking the link tracking program, and determine the target derived task corresponding to the target server among the at least two derived tasks associated with the service request. At this point, a key-value pair can be constructed based on the target task identifier of the target derived task and the request path information, and the key-value pair can be stored in the data storage structure of the link tracking program. This ensures that the request path information associated with the service request is persisted in the data storage structure, thereby completing the recording of tracking information associated with the service request on the target server. Furthermore, by storing the request path information in the data storage structure, the service items provided by the target server can be non-intrusive, thereby ensuring that the path information is recorded while maintaining the stability of the service items.Typically, a request requires the collaborative completion of multiple servers. To ensure that the link associated with the request can be accurately retrieved during the fault location phase, when executing the associated derived task corresponding to the associated server among at least two derived tasks, the associated task identifier corresponding to the associated derived task can be determined based on the task relationship between the at least two derived tasks. A data storage structure is then queried based on the associated task identifier to create an associated service request carrying associated request path information based on the query result and send it to the associated server. The request sent to the associated server carries the associated request path information created by the current server, and the associated server then performs the same request path information storage operation as the target server. Consequently, the request path information associated with the request is stored in the data storage structure corresponding to the servers involved in the link. This allows for the distributed link tracing information associated with the request to be determined during the fault location phase by reading the request path information from the data storage structure, enabling rapid and accurate fault location and reducing the impact of the fault on the distributed system. Corresponding to the aforementioned method embodiments, the present disclosure also provides an embodiment of a request processing device. Figure 6 shows a schematic structural diagram of a request processing device provided by one embodiment of the present disclosure. As shown in FIG6 , the apparatus is applied to a target server and includes: a calling module 602 configured to call a link tracking program in response to a service request to extract request path information from the service request, and determine a target derived task corresponding to the target server among at least two derived tasks associated with the service request; a storage module 604 configured to construct a key-value pair based on a target task identifier of the target derived task and the request path information, and store the key-value pair in a data storage structure of the link tracking program; a determining module 606 configured to determine an associated task identifier corresponding to the associated derived task according to a task relationship between the at least two derived tasks when executing an associated derived task corresponding to an associated server among the at least two derived tasks; a sending module 608 configured to query the data storage structure based on the associated task identifier, create an associated service request carrying the associated request path information according to the query result, and send the result to the associated server; wherein the key-value pair recorded in the data storage structure is used to construct distributed link tracking information. In an optional embodiment, the calling module 602 is further configured to: receive a service request submitted by a user for a target service; call a link tracking program according to the service request, wherein the link tracking program is mounted on a transceiver function associated with a kernel network node of the target server; parse the service request using the link tracking program, and extract the request path information from the message header of the service request according to the parsing result.In an optional embodiment, the determination module 606 is further configured to: utilize the link tracing program to obtain the task relationship corresponding to the at least two derived tasks; determine, based on the task relationship, an adjacent derived task in the at least two derived tasks that has a parent-child task relationship with the associated derived task; and determine the associated task identifier based on the first task identifier of the associated derived task and the second task identifier of the adjacent derived task. In an optional embodiment, the determination module 606 is further configured to: determine the first task identifier of the associated derived task, query the data storage structure based on the first task identifier; and if it is determined from the query result that the first request path information associated with the first task identifier does not exist in the data storage structure, use the second task identifier as the associated task identifier. In an optional embodiment, the sending module 608 is further configured to: query the data storage structure based on the associated task identifier, determine the request path information based on the query result; create associated request path information based on the request path information; create an associated service request corresponding to the associated server, add the associated request path information to a message header of the associated service request, and send the associated service request to the associated server; wherein the associated server and the target service belong to a distributed system. In an optional embodiment, the apparatus further includes: an adding module configured to add the target derived task to a task queue of an asynchronous thread pool, select a target thread in the asynchronous thread pool for the target derived task; establish a scheduling relationship between the target thread and the target derived task; and, if the target derived task in the task queue is in an execution state, assign the target derived task to the target thread based on the scheduling relationship for execution. In an optional embodiment, the device further includes: a task acquisition module configured to acquire a request analysis task and, based on the request analysis task, send a tracking information acquisition request to the servers corresponding to the at least two derived tasks; receive link tracking information fed back by the servers corresponding to the at least two derived tasks in response to the tracking information acquisition request, wherein the link tracking information is stored in a data storage structure corresponding to each server; construct the distributed link tracking information based on the link tracking information, and execute the request analysis task. In an optional embodiment, the device further includes: a task relationship acquisition module configured to load a benchmark subroutine through the link tracking program and mount the benchmark subroutine to the associated function corresponding to the associated derived task; when the associated derived task is executed and the associated function is called, start the benchmark subroutine to acquire the task relationship.The request processing device provided in this embodiment enables any server in a distributed system to record tracing information during runtime, enabling direct access to tracing information and the construction of distributed link tracing information during fault location, thereby rapidly and accurately completing fault location analysis. In specific implementations, the target server can, in response to the server invoking the link tracing program, extract request path information from the service request and determine the target derived task corresponding to the target server among the at least two derived tasks associated with the service request. A key-value pair can then be constructed based on the target task identifier and request path information of the target derived task, and stored in the data storage structure of the link tracing program. The request path information associated with the service request is persisted in the data storage structure, completing the recording of tracing information associated with the service request on the target server. Furthermore, by storing the request path information in the data storage structure, the target server can achieve non-intrusiveness to the services provided by the target server, thereby ensuring that the path information is recorded while maintaining the stability of the service. Typically, a request requires the collaborative completion of multiple servers. To ensure that the links associated with the request can be accurately retrieved during the fault location phase, the associated task identifier corresponding to the associated derived task can be determined based on the task relationship between the at least two derived tasks while executing the associated derived task corresponding to the associated server. The associated task identifier is then queried in a data storage structure based on the query result to create a related service request carrying the associated request path information and send it to the associated server. The request sent to the associated server carries the associated request path information created by the current server, and the associated server then performs the same request path information storage operation as the target server. Consequently, the request path information associated with the request is stored in the data storage structure corresponding to the servers involved in the link. During the fault location phase, the request path information in the data storage structure can be read to determine the distributed link tracing information associated with the request, enabling rapid and accurate fault location and minimizing the impact of the fault on the distributed system. The above is an illustrative solution for a request processing device according to this embodiment. It should be noted that the technical solution of the request processing device and the technical solution of the aforementioned request processing method share the same concept. For details not described in detail in the technical solution of the request processing device, please refer to the description of the technical solution of the aforementioned request processing method. Corresponding to the aforementioned method embodiments, the present disclosure also provides a task execution method embodiment. FIG7 shows a flowchart of a task execution method provided in one embodiment of the present disclosure.As shown in Figure 7, the method, applied to a target server, includes: Step S702: obtaining a request analysis task and determining at least two derived tasks associated with the request analysis task; Step S704: sending a tracking information acquisition request to the servers corresponding to the at least two derived tasks, based on the request analysis task; Step S706: receiving link tracking information fed back by the servers corresponding to the at least two derived tasks in response to the tracking information acquisition request, wherein the link tracking information is stored in a data storage structure corresponding to each server; Step S708: constructing distributed link tracking information based on the link tracking information and executing the request analysis task. The task execution method provided in this embodiment can be found in the description of the request processing method in the above embodiment, and this embodiment will not be elaborated on here. Corresponding to the above method embodiment, the present disclosure also provides an embodiment of a task execution device. Figure 8 shows a schematic structural diagram of a task execution device provided in one embodiment of the present disclosure. As shown in Figure 8 , the device is applied to a target server and includes: a task acquisition module 802 configured to acquire a request analysis task and determine at least two derived tasks associated with the request analysis task; a request sending module 804 configured to send a tracking information acquisition request to the servers corresponding to the at least two derived tasks, based on the request analysis task; an information receiving module 806 configured to receive link tracking information fed back by the servers corresponding to the at least two derived tasks in response to the tracking information acquisition request, wherein the link tracking information is stored in a data storage structure corresponding to each server; and a task execution module 808 configured to construct distributed link tracking information based on the link tracking information and execute the request analysis task. The above is a schematic diagram of a task execution device according to this embodiment. It should be noted that the technical solution of this task execution device and the technical solution of the aforementioned task execution method share the same concept. For details not described in detail in the technical solution of the task execution device, please refer to the description of the technical solution of the aforementioned task execution method. Corresponding to the above method embodiments, the present disclosure also provides a request processing system embodiment. FIG9 shows a schematic structural diagram of a request processing system provided by an embodiment of the present disclosure.As shown in FIG9 , a request processing system 900 includes a target server 910 and an associated server 920 , including: the target server 910, in response to a service request, invoking a link tracking program to extract request path information from the service request and determine a target derived task corresponding to the target server among at least two derived tasks associated with the service request; constructing a key-value pair based on the target task identifier of the target derived task and the request path information, and storing the key-value pair in a data storage structure of the link tracking program; when executing an associated derived task corresponding to the associated server among the at least two derived tasks, determining an associated task identifier corresponding to the associated derived task based on the task relationship between the at least two derived tasks; querying the data storage structure based on the associated task identifier, creating an associated service request carrying associated request path information based on the query result, and sending the request to the associated server; wherein the key-value pair recorded in the data storage structure is used to construct distributed link tracking information; and the associated server 920, in response to the associated service request, executing an associated request processing task. The associated request processing task is the request processing process executed by the corresponding target server. The above is a schematic diagram of a request processing system according to this embodiment. It should be noted that the technical solution of this request processing system shares the same concept as the technical solution of the request processing method described above. For details not described in detail in the technical solution of the request processing system, please refer to the description of the technical solution of the request processing system described above. Figure 10 shows a block diagram of a computing device 1000 according to one embodiment of the present disclosure. The components of computing device 1000 include, but are not limited to, a memory 1010 and a processor 1020. Processor 1020 is connected to memory 1010 via a bus 1030, and a database 1050 is used to store data. Computing device 1000 also includes an access device 1040, which enables computing device 1000 to communicate via one or more networks 1060. Examples of these networks include the Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet.The access device 1040 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, or a near field communication (NFC) interface. In one embodiment of the present disclosure, the aforementioned components of the computing device 1000 and other components not shown in FIG. 10 may also be connected to each other, for example, via a bus. It should be understood that the computing device structure block diagram shown in FIG. 10 is for illustrative purposes only and does not limit the scope of the present disclosure. Those skilled in the art may add or replace other components as needed. Computing device 1000 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., tablet computer, personal digital assistant, laptop computer, notebook computer, netbook, etc.), a mobile phone (e.g., smartphone), a wearable computing device (e.g., smartwatch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or personal computer (PC). Computing device 1000 can also be a mobile or stationary server. Processor 1020 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the aforementioned request processing method or task execution method. The above is a schematic diagram of a computing device in this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the aforementioned request processing method or task execution method are based on the same concept. For details not described in the technical solution of the computing device, please refer to the description of the technical solution of the aforementioned request processing method or task execution method. An embodiment of the present disclosure further provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the steps of the above-mentioned request processing method or task execution method.The above is a schematic diagram of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium is based on the same concept as the technical solution of the request processing method or task execution method described above. Any details not described in detail in the technical solution of the storage medium can be found in the description of the technical solution of the request processing method or task execution method described above. An embodiment of the present disclosure also provides a computer program product, including a computer program or instructions. When executed by a processor, the computer program or instructions implement the steps of the request processing method or task execution method described above. The above is a schematic diagram of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product is based on the same concept as the technical solution of the request processing method or task execution method described above. Any details not described in detail in the technical solution of the computer program product can be found in the description of the technical solution of the request processing method or task execution method described above. The above describes specific embodiments of the present disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the figures do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous. The computer instructions include computer program code, which may be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, removable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signals, telecommunication signals, and software distribution media. It should be noted that the content of the computer-readable medium may be appropriately increased or decreased based on the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media does not include electric carrier signals and telecommunication signals. It should be noted that for ease of description, the aforementioned method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present disclosure are not limited by the order of the actions described, as certain steps may be performed in other orders or simultaneously according to the embodiments of the present disclosure. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required for the embodiments of the present disclosure.In the above embodiments, the description of each embodiment has its own emphasis. For portions not described in detail in a particular embodiment, reference should be made to the relevant descriptions of other embodiments. The preferred embodiments disclosed above are merely intended to illustrate the present disclosure. The alternative embodiments do not describe all details in detail, nor do they limit the invention to the specific implementations described. Obviously, many modifications and variations are possible based on the content of the embodiments disclosed. These embodiments are selected and described in detail in this disclosure to better explain the principles and practical applications of the embodiments of the present disclosure, thereby enabling those skilled in the art to better understand and utilize the present disclosure. The present disclosure is limited only by the claims and their full scope and equivalents.

Claims

Claims 1. A request processing method, applied to a target server, includes: In response to a service request, call a link tracing program to extract request path information in the service request, and determine a target derivative task corresponding to the target server among at least two derivative tasks associated with the service request; Construct key-value pairs based on the target task identifier of the target derivative task and the request path information, and store the key-value pairs in the data storage structure of the link tracing program; when executing an associated derivative task corresponding to an associated server among the at least two derivative tasks, determine an associated task identifier corresponding to the associated derivative task according to the task relationship among the at least two derivative tasks; Query the data storage structure based on the associated task identifier, create an associated service request carrying associated request path information according to the query result, and send it to the associated server; Wherein, the key-value pairs recorded in the data storage structure are used to construct distributed link tracing information.

2. The method according to claim 1, wherein the step of invoking a link tracing program in response to a service request to extract request path information in the service request comprises: Receive a service request submitted by a user for a target service; Call a link tracing program according to the service request, wherein the link tracing program is mounted on a transceiver function associated with a kernel network node of the target server; use the link tracing program to parse the service request, and extract request path information from the message header of the service request according to the parsing result.

3. According to the method described in any one of claims 1-2, determining the associated task identifier corresponding to the associated derived task according to the task relationship of the at least two derived tasks includes: Use the link tracing program to obtain the task relationship corresponding to the at least two derivative tasks; Determine adjacent derivative tasks having a parent-child task relationship with the associated derivative task among the at least two derivative tasks according to the task relationship; based on a first task identifier of the associated derivative task and a second task identifier of the adjacent derivative task, determine an associated task identifier.

4. The method according to claim 3, wherein determining the associated task identifier based on the first task identifier of the associated derived task and the second task identifier of the adjacent derived task comprises: Determine a first task identifier of the associated derivative task, and query the data storage structure based on the first task identifier; If it is determined that there is no first request path information associated with the first task identifier in the data storage structure according to the query result, use the second task identifier as the associated task identifier.

5. According to the method described in any one of claims 1-4, querying the data storage structure based on the associated task identifier, creating an associated service request carrying associated request path information according to the query result, and sending it to the associated server, including: Query the data storage structure based on the associated task identifier, determine the request path information according to the query result; create associated request path information according to the request path information; Create an associated service request corresponding to the associated server, add the associated request path information to the message header of the associated service request, and send it to the associated server; Wherein, the associated server and the target service belong to a distributed system.

6. According to the method described in any one of claims 1-5, after the step of storing the key-value pair into the data storage structure of the link tracing program, the method further includes: Add the target derivative task to the task queue of the asynchronous thread pool, and select a target thread in the asynchronous thread pool for the target derivative task; construct a scheduling relationship between the target thread and the target derivative task; When the target derivative task in the task queue is in an execution state, allocate the target derivative task to the target thread and execute it based on the scheduling relationship. ​ 7. After the step of creating an associated service request carrying associated request path information according to the query result and sending it to the associated server in the method according to any one of claims 1-6, the method further includes: Obtain a request analysis task, and send a tracking information acquisition request to the servers corresponding to the at least two derived tasks respectively according to the request analysis task; receive the link tracking information fed back by the servers corresponding to the at least two derived tasks respectively for the tracking information acquisition request, wherein the link tracking information is stored in the data storage structures corresponding to the respective servers; construct the distributed link tracking information according to the link tracking information, and execute the request analysis task.

8. For the method according to any one of claims 1-6, before the step of determining the associated task identifier corresponding to the associated derived task according to the task relationship of the at least two derived tasks, the method further includes: Load a reference subroutine through the link tracking program, and mount the reference subroutine to the associated function corresponding to the associated derived task; When the associated derived task is executed and the associated function is called, start the reference subroutine to obtain the task relationship.

9. A task execution method, applied to a target server, includes: Obtain a request analysis task, and determine at least two derived tasks associated with the request analysis task; Send a tracking information acquisition request to the servers corresponding to the at least two derived tasks respectively according to the request analysis task; receive the link tracking information fed back by the servers corresponding to the at least two derived tasks respectively for the tracking information acquisition request, wherein the link tracking information is stored in the data storage structures corresponding to the respective servers; construct the distributed link tracking information according to the link tracking information, and execute the request analysis task.

10. A request processing device, applied to a target server, comprising: A calling module, configured to, in response to a service request, call a link tracking program to extract request path information in the service request, and determine a target derived task corresponding to a target server among at least two derived tasks associated with the service request; A storage module, configured to construct a key-value pair according to a target task identifier of the target derived task and the request path information, and store the key-value pair in the data storage structure of the link tracking program; A determination module, configured to, when an associated derived task corresponding to an associated server among the at least two derived tasks is executed, determine an associated task identifier corresponding to the associated derived task according to the task relationship of the at least two derived tasks; A sending module, configured to query the data storage structure based on the associated task identifier, create an associated service request carrying associated request path information according to the query result, and send it to the associated server; Wherein, the key-value pairs recorded in the data storage structure are used to construct distributed link tracking information.

11. A task execution device, applied to a target server, comprising: A task acquisition module, configured to obtain a request analysis task, and determine at least two derived tasks associated with the request analysis task; A request sending module, configured to send a tracking information acquisition request to the servers corresponding to the at least two derived tasks respectively according to the request analysis task; an information receiving module, configured to receive the link tracking information fed back by the servers corresponding to the at least two derived tasks respectively for the tracking information acquisition request, wherein the link tracking information is stored in the data storage structures corresponding to the respective servers; The task execution module is configured to construct distributed link tracing information based on the link tracing information and execute the request analysis task.

12. A request processing system, including a target server and an associated server, comprising: The target server is used to call a link tracing program in response to a service request to extract request path information in the service request and determine a target derived task corresponding to the target server among at least two derived tasks associated with the service request. Construct a key-value pair according to the target task identifier of the target derived task and the request path information, and store the key-value pair in the data storage structure of the link tracing program; when executing the associated derived task of the associated server corresponding to the at least two derived tasks, determine the associated task identifier corresponding to the associated derived task according to the task relationship of the at least two derived tasks. Query the data storage structure based on the associated task identifier, create an associated service request carrying associated request path information according to the query result, and send it to the associated server; wherein, the key-value pairs recorded in the data storage structure are used to construct distributed link tracing information. The associated server is used to execute an associated request processing task in response to the associated service request.

13. A computing device, comprising: A memory and a processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the method according to any one of claims 1 to 9 are implemented.

14. A computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

15. A computer program product includes a computer program or instructions, and when the computer program or instructions are executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

Images