Air product query method, system, device and medium

Abstract

The application discloses an aviation product query method, system, device and medium, relates to the technical field of distributed computing architecture, and aims to solve the problems of serious response time consumption and low fault tolerance when a large number of aviation products are queried. The aviation product query method is applied to a request scheduling node and includes the following steps: splitting a source query request to obtain a plurality of sub-requests, wherein the source query request comprises a plurality of groups of query parameters used for representing aviation product attributes; sending a subscription sub-node table request containing a performance configuration weight determined by the request scheduling node according to the business type of the source query request to a node registration center; distributing the plurality of sub-requests to a plurality of sub-execution nodes in a sub-node table returned by the node registration center; the priority of each sub-execution node in the sub-node table is determined based on the performance configuration weight and a performance index; and receiving aviation query response results returned by the plurality of sub-execution nodes in parallel execution of the sub-requests distributed respectively by the sub-execution nodes, and generating a target response result.

Description

Technical Field

[0001] This application relates to the field of distributed computing architecture technology, and in particular to a method, system, device and medium for querying aviation products. Background Technology

[0002] In recent years, with the rapid development of the industrial internet in the aviation industry, the civil aviation industry is accelerating its transformation towards digitalization and intelligence. Business scenarios are becoming increasingly complex, and the supporting capabilities of its underlying IT architecture are facing unprecedented challenges.

[0003] As the mainstream distributed architecture in the current civil aviation industry, microservices can break down an application into a set of independent small services, each of which can be developed and deployed independently on different nodes. The introduction of containerization technology provides an ideal running and deployment environment for microservices, achieving true service isolation, efficient deployment and expansion, and simplified operation and maintenance.

[0004] However, when facing high-concurrency scenarios in the aviation industry's industrial internet, such as querying a large number of flights and related products at once, the microservice architecture's granular service structure, where each small service focuses only on itself, makes it unable to handle highly complex requests and lacks global coordination, easily leading to uneven request distribution. This results in serious response time and low fault tolerance when querying a large number of products. Summary of the Invention

[0005] The purpose of this application is to provide a method, system, device and medium for querying aviation products, which aims to solve the problems of long response time and low fault tolerance when querying large quantities of aviation products.

[0006] To achieve the above objectives, this application adopts the following technical solution: Firstly, this application provides an aviation product query method applied to a request scheduling node, comprising: splitting a received source query request into multiple sub-requests; the source query request includes multiple sets of query parameters arranged according to a preset uniform structure; the query parameters are used to characterize the product attributes of the aviation product; sending a request to subscribe to a sub-node table to a node registration center; the request to subscribe to a sub-node table includes a performance configuration weight determined by the request scheduling node based on the business type of the source query request; distributing multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registration center, so that the multiple sub-execution nodes execute their respective distributed sub-requests in parallel; the sub-node table includes the priority of each sub-execution node determined by the node registration center, the priority being determined based on the performance configuration weight and the performance indicators of the sub-execution nodes; the performance indicators are used to characterize the load status of the sub-execution nodes; receiving aviation query response results returned by some or all of the multiple sub-execution nodes; and sending a target response result to the aviation query requester of the source query request based on the aviation query response results returned by some or all of the multiple sub-execution nodes.

[0007] The aviation product query method provided in this application splits the received source query request into multiple sub-requests by a request scheduling node. This reduces the pressure on a single backend server when dealing with large-volume aviation product queries. The request scheduling node sends a request to the node registry center to subscribe to a sub-node table, carrying performance configuration weights determined based on the business type of the source query request. This provides an effective quantitative standard for prioritizing sub-execution nodes, helping to select a more suitable execution node for the current query request while ensuring that the returned sub-node table accurately reflects the optimal node scheduling order that meets the current request's business requirements. The request scheduling node then processes the sub-node table returned by the node registry center... Multiple sub-execution nodes in the node table distribute multiple sub-requests and aggregate the aviation query response results returned by the parallel execution of their respective sub-requests. This effectively improves the request processing efficiency and reduces query response time in scenarios involving large-volume aviation product queries. The priority of each sub-execution node in the sub-node table, determined by the node registry center, is based on performance configuration weights and performance indicators used to characterize the load status of the sub-execution nodes. This avoids distributing requests to already overloaded nodes, achieving load balancing, improving resource utilization, and reducing request response latency. At the same time, it prevents sub-execution nodes from crashing due to sudden traffic surges, thereby significantly improving the efficiency and fault tolerance of the query service.

[0008] In some embodiments, the service type includes at least one of computing power sensitive class, capacity sensitive class and mixed load class, and different service types correspond to different performance configuration weights.

[0009] In some embodiments, distributing multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registry center includes: distributing multiple sub-requests in descending order of priority according to the sub-execution nodes in the sub-node table, provided that the number of sub-requests does not exceed the number of nodes in the sub-node table.

[0010] In some embodiments, distributing multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registration center further includes: if the number of sub-requests exceeds the number of nodes in the sub-node table, distributing the multiple sub-requests in multiple rounds according to the number of nodes in the sub-node table, and distributing the sub-requests in the last round according to the priority of the sub-execution nodes in the sub-node table from high to low.

[0011] In some embodiments, receiving aviation query response results returned by some or all of the multiple sub-execution nodes includes: when the processing time of the source query request reaches a preset timeout threshold, identifying at least one incomplete first target sub-request among the multiple sub-requests, and actively giving up waiting for the aviation query response result of the first target sub-request.

[0012] In some embodiments, after receiving the aviation query response results returned by some or all of the multiple sub-execution nodes, the method further includes: determining at least one second target sub-request among the multiple sub-requests that has an execution error, and removing the aviation query response result corresponding to the second target sub-request.

[0013] In some embodiments, sending a target response result to the aviation query requester of the source query request based on the aviation query response results returned by some or all of the multiple sub-execution nodes includes: generating a target response result based on the aviation query response results obtained, excluding the aviation query response results of the first target sub-request and the aviation query response results of the second target sub-request, and sending it to the aviation query requester of the source query request.

[0014] Secondly, this application provides a product query system applied to a request scheduling node, comprising: a request splitting module for splitting a received source query request into multiple sub-requests; the source query request includes multiple sets of query parameters arranged according to a preset uniform structure; the query parameters are used to characterize the product attributes of aviation products; a request distribution module for sending a subscription sub-node table request to a node registration center; the subscription sub-node table request includes performance configuration weights determined by the request scheduling node based on the business type of the source query request; the request distribution module is further configured to distribute multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registration center, so that multiple sub-execution nodes execute their respective distributed sub-requests in parallel; the sub-node table includes the priority of each sub-execution node determined by the node registration center, the priority being determined based on the performance configuration weights and the performance indicators of the sub-execution nodes; the performance indicators are used to characterize the load status of the sub-execution nodes; a request response module for receiving aviation query response results returned by some or all of the multiple sub-execution nodes; the request response module is further configured to send a target response result to the aviation query requester of the source query request based on the aviation query response results returned by some or all of the multiple sub-execution nodes.

[0015] Thirdly, a computer device is provided, including a processor and a memory, the processor being coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computer device to implement the aviation product query method of the first aspect.

[0016] Fourthly, a computer-readable storage medium is provided, comprising computer-executable instructions that, when executed on a computer, cause the computer to perform the aviation product query method of the first aspect. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic diagram illustrating the application environment of an aviation product query method provided as an exemplary embodiment; Figure 2 A schematic diagram of distributed request routing and distribution provided as an exemplary embodiment; Figure 3 A schematic diagram of a request-response aggregation process is provided as an exemplary embodiment; Figure 4A schematic diagram illustrating a subscription node sub-table request processing as an exemplary embodiment; Figure 5 A schematic diagram of a child node table construction process is provided as an exemplary embodiment; Figure 6 A schematic diagram of an aviation product query process is provided as an exemplary embodiment; Figure 7 A flowchart illustrating an exemplary embodiment of an aviation product query method; Figure 8 A schematic diagram of the structure of an aviation product query system provided as an exemplary embodiment; Figure 9 A schematic diagram of the structure of a computer device provided for an exemplary embodiment. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] In the description of this application, it should be understood that the terms "upper," "lower," "left," "right," "front," "rear," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or relative positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and for simplification, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Unless otherwise specified, the above-mentioned orientational descriptions can be flexibly set in practical applications, provided that the relative positional relationships shown in the accompanying drawings are satisfied.

[0021] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0022] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," and "communication" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection. They can refer to a direct connection or an indirect connection through an intermediate medium, or a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0023] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, article, or apparatus that includes that element.

[0024] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0025] In the description of this specification, specific features, structures, materials, or characteristics may be combined in any suitable manner in one or more embodiments or examples.

[0026] In recent years, with the rapid development of the industrial internet in the aviation industry, the civil aviation industry is accelerating its transformation towards digitalization and intelligence. Business scenarios are becoming increasingly complex, and the supporting capabilities of its underlying IT architecture are facing unprecedented challenges.

[0027] The core idea of ​​distributed computing is to break down a large task into multiple smaller tasks, execute them in parallel on different nodes, and finally aggregate the results from each node to form the final answer. This computing method can save overall computation time, greatly improve computational efficiency, and has the characteristics of flexible scalability and tolerance for partial node failures.

[0028] As the mainstream distributed architecture in the current civil aviation industry, microservices can break down an application into a set of independent small services. Each service can be developed independently and deployed on different nodes. The introduction of containerization technologies (such as Docker and Kubernetes) provides an ideal running and deployment environment for microservices, enabling true service isolation, efficient deployment and expansion, and simplified operation and maintenance.

[0029] However, when facing high-concurrency scenarios in the aviation industry's industrial internet, such as querying numerous flights and related products at once, the microservice architecture's granular service structure, where each small service focuses only on itself, cannot handle highly complex requests. The microservice architecture itself does not provide a solution to break down large services into sub-services and merge sub-results into a total result. It also cannot perform validity checks and exception isolation for each sub-result, and the lack of global coordination makes it easy for requests to be unevenly distributed. As a result, when querying a large number of products, there will be serious problems such as long response times and low fault tolerance.

[0030] Based on this, this application provides an aviation product query method applied to a request scheduling node, comprising: splitting a received source query request into multiple sub-requests; sending a request to subscribe to a sub-node table to a node registration center; the sub-node table subscription request including a performance configuration weight determined by the request scheduling node based on the business type of the source query request; distributing multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registration center, so that the multiple sub-execution nodes execute their respective distributed sub-requests in parallel; the sub-node table including the priority of each sub-execution node determined by the node registration center, the priority being determined based on the performance configuration weight and the performance indicators of the sub-execution nodes; the performance indicators being used to characterize the load status of the sub-execution nodes; receiving aviation query response results returned by some or all of the multiple sub-execution nodes; and sending a target response result to the aviation query requester of the source query request based on the aviation query response results returned by some or all of the multiple sub-execution nodes.

[0031] The aviation product query method provided in this application splits the received source query request into multiple sub-requests by a request scheduling node. This reduces the pressure on a single backend server when dealing with large-volume aviation product queries. The request scheduling node sends a request to the node registry center to subscribe to a sub-node table, carrying performance configuration weights determined based on the business type of the source query request. This provides an effective quantitative standard for prioritizing sub-execution nodes, helping to select a more suitable execution node for the current query request while ensuring that the returned sub-node table accurately reflects the optimal node scheduling order that meets the current request's business requirements. The request scheduling node then processes the sub-node table returned by the node registry center... Multiple sub-execution nodes in the node table distribute multiple sub-requests and aggregate the aviation query response results returned by the parallel execution of their respective sub-requests. This effectively improves the request processing efficiency and reduces query response time in scenarios involving large-volume aviation product queries. The priority of each sub-execution node in the sub-node table, determined by the node registry center, is based on performance configuration weights and performance indicators used to characterize the load status of the sub-execution nodes. This avoids distributing requests to already overloaded nodes, achieving load balancing, improving resource utilization, and reducing request response latency. At the same time, it prevents sub-execution nodes from crashing due to sudden traffic surges, thereby significantly improving the efficiency and fault tolerance of the query service.

[0032] The solution provided in this application can be applied to, for example... Figure 1 The application environment 100 is shown. Figure 1 This diagram illustrates an application environment 100 for an aviation product query method, provided as an exemplary embodiment. The application environment 100 includes: an aviation query request initiator 101, a request scheduling node 102, a node registration center 103, and a sub-execution node 104. Specifically, the aviation query request initiator 101 communicates with the request scheduling node 102; the request scheduling node 102 communicates with the node registration center 103; the node registration center 103 communicates with the sub-execution node 104; and the request scheduling node 102 communicates with the sub-execution node 104.

[0033] In some embodiments, the aviation query request initiator 101 is used to send a source query request, i.e., an aviation query request, to the request scheduling node 102.

[0034] The request scheduling node 102 receives the aviation query request sent by the aviation query request initiator 101, breaks it down into multiple independent sub-requests, distributes them according to the priority of the sub-execution nodes 104, executes the queries in parallel, and reassembles the response results of all sub-requests according to the input parameter order to generate complete output parameters. This generates a complete query response result and returns it to the aviation query request initiator 101, ensuring the efficiency of the query service. The input parameter order is the arrangement order of the sub-request data in the original aviation query request data; the complete output parameter is the final data packet generated after reassembling the aviation route query response results of each sub-request, with a complete structure and a strict order corresponding to the original aviation query request.

[0035] The interface parameters corresponding to the flight query request are multiple sets of parameters with the same structure. When splitting, the parameters are grouped according to the number of groups set in the configuration file, and each set of parameters is used as the sub-request parameters.

[0036] The configuration file can be a pre-configured backend settings file used to control the aviation query service, including but not limited to the number of request split groups, the corresponding preset timeout threshold for query request processing time, and the entry IP of the current node cluster. The node cluster is a collection composed of multiple sub-execution nodes 104.

[0037] The interface parameters corresponding to the flight query request are all the input data sent by the flight query requester to the gateway or request scheduling node 102. The interface parameters can be a collection of data with the same structure (such as an array or list).

[0038] The sub-request input parameters are local data slices allocated to each sub-execution node 104 after the interface input parameters are split, that is, a portion of the data extracted from the interface input parameters.

[0039] For example, the request scheduling node 102 can be a pre-developed aggregation application, which is often referred to as API orchestration or interface aggregation service in distributed system design. It is responsible for coordinating multiple backend services to transform complex query requests into a series of ordered and efficient sub-requests. The core workflow includes query request splitting, intelligent routing and distribution (mapping each split sub-request to the best available sub-execution node for execution) and result aggregation (integrating the output of all or some sub-execution nodes into a coherent final response and returning it to the aviation query request initiator 101).

[0040] For example, such as Figure 2 As shown, Figure 2 This is a schematic diagram of a distributed request routing distribution provided as an exemplary embodiment. Figure 2In the process, the original input parameters of the source query request include input parameter group 1 to input parameter group 500. After the original input parameters are input into the aggregation application, the source query request is split and grouped with the original input parameters to obtain 25 sub-requests (i.e., sub-request 1 to sub-request 25). Then, the 25 sub-requests are distributed to 10 sub-execution nodes (i.e., sub-execution nodes 1 to 10) for processing.

[0041] Each sub-request contains several input parameter groups, and the sub-requests distributed by each sub-execution node are different. For example... Figure 2 As shown, sub-request 1 and sub-request 2 are distributed to sub-execution node 1 for processing, wherein sub-request 1 contains input parameter groups 1-20 and sub-request 2 contains input parameter groups 21-40; sub-request 3, sub-request 4 and sub-request 5 are distributed to sub-execution node 2 for processing, wherein sub-request 3 contains input parameter groups 41-60, sub-request 4 contains input parameter groups 61-80 and sub-request 5 contains input parameter groups 81-100; sub-request 25 is distributed to sub-execution node 10 for processing, wherein sub-request 25 contains input parameter groups 481-500.

[0042] For example, such as Figure 3 As shown, Figure 3 This is a schematic diagram of a request-response aggregation process provided as an exemplary embodiment. Figure 3 In the process, sub-execution nodes 1 to 10 return the response results for their respective distributed sub-requests to the aggregation application, and generate the summary results in order, which is to generate the final complete query response results.

[0043] Specifically, sub-execution node 1 returns sub-result 1 and sub-result 2 to the aggregation application. Sub-result 1 includes parameter groups 1-20, and sub-result 2 includes parameter groups 21-40. Sub-execution node 10 returns sub-result 25 to the aggregation application. Sub-result 25 includes parameter groups 481-500. Sub-execution node 2 returns sub-result 3, sub-result 4, and sub-result 5 to the aggregation application. Sub-result 4 includes parameter groups 61-80, sub-result 5 includes parameter groups 81-100, and sub-result 3 of the sub-execution node is either timed out or has an abnormal result.

[0044] Therefore, by supporting the function of receiving and outputting large messages at once, when facing scenarios that require real-time processing of large amounts of data, the input parameters can be split into several sub-input parameters for subsequent transmission to sub-execution nodes. This can significantly reduce the pressure on a single backend server to process messages, ensuring efficiency and accuracy when processing large-scale data, significantly improving the overall performance and user experience of the system. The response results returned by each sub-execution node are summarized in order, which can ensure the efficiency of the query service. In particular, by adopting parallel processing technology, the query request is decomposed into multiple sub-query requests and executed simultaneously by backend sub-nodes, which can significantly shorten the processing time of complex queries and significantly improve query processing efficiency.

[0045] The request scheduling node 102 can periodically send a subscription request for the node sub-table to the node registration center 103 at preset time intervals. The subscription parameters of the subscription request for the node sub-table include, but are not limited to, the interface IDs of all source query requests and the required performance configuration weights; wherein, the interface ID of the source query request can be used to identify the query business category of the current request (e.g., flight query, historical order query) and route distribution.

[0046] For example, the preset time interval can be preset by those skilled in the art based on factors such as query service response delay, changes in aviation product data, and the balance between network and resource consumption, for example, 5 minutes.

[0047] The performance configuration weights are provided to the node registration center 103 to assign weights to the performance metrics of each node in the node sub-table, so as to obtain the priority of each node in the node sub-table.

[0048] For example, such as Figure 4 As shown, Figure 4 This is a schematic diagram illustrating a subscription node sub-table request processing method as provided in an exemplary embodiment. Figure 4 It includes an aggregation application 401, a node registration center 103, and multiple sub-execution nodes 104 (such as sub-execution nodes 104-1, 104-2 to 104-n).

[0049] In this process, the aggregation application 401 is considered as the request scheduling node 102, which sends a request to subscribe to the sub-table of nodes to the node registration center 103. The node registration center 103 registers n sub-execution nodes 104. The subscription parameters of this request to subscribe to the sub-table of nodes include the interface ID of the source query request and the required performance configuration weights. Specifically, if the interface ID of the source query request is I1, the corresponding performance configuration weights are a CPU weight coefficient of 0.5 and a memory weight coefficient of 0.5; if the interface ID of the source query request is I2, the corresponding performance configuration weights are a CPU weight coefficient of 0.7 and a memory weight coefficient of 0.3.

[0050] For example, the request scheduling node 102 can be configured with exception isolation logic. This exception isolation logic means that when some sub-requests fail to execute, the overall query process does not need to be terminated. Instead, the aviation query response results corresponding to the sub-requests that failed to execute (i.e., the exception sub-results) are filtered and the aviation query response results of the remaining normal sub-requests are assembled and returned, thereby effectively improving query fault tolerance.

[0051] For example, the request scheduling node 102 can also be configured with a time limit mechanism. This time limit mechanism proactively discards sub-requests that have not yet obtained aviation query response results when the total time spent on aviation query requests reaches a preset threshold, that is, proactively discards timed-out sub-requests, in order to complete result assembly in a timely manner and ensure query speed. The time limit can be set in the configuration file according to the specific current aviation product query business scenario.

[0052] In some embodiments, the node registration center 103 is used to generate a node master table based on the node registration information of the sub-execution nodes, and after receiving a request to subscribe to the sub-node table sent by the request scheduling node 102, it filters nodes from the node master table and constructs a sub-node table sorted according to node priority.

[0053] The node registration information includes, but is not limited to, node identifier (ID), network address (IP and port), hardware configuration parameters (such as the number of CPU cores and memory size), real-time load data (such as current CPU utilization and memory usage), and heartbeat status information.

[0054] The node summary table can consist of node serial number, performance metrics, node IP, and liveness status (online / offline). The performance metrics in the node summary table include, but are not limited to, CPU utilization and memory utilization.

[0055] If a sub-execution node in the node master table experiences a failure such as downtime or application crash, the failure sub-execution node can be automatically removed from the node master table.

[0056] The node registration center 103 can provide an interface to the pre-deployed child node monitoring agent to receive and cache the entry IP and performance metrics of the child execution nodes.

[0057] The child node monitoring agent reads the entry IPs of all child nodes in the current node cluster from the configuration file upon startup, and after startup, obtains real-time performance index data of all child nodes in the current node cluster according to a preset sampling frequency and sends it to the node registration center 103. The preset sampling frequency can be pre-set by those skilled in the art based on changes in node load, node cluster size, and node resource consumption; for example, it may obtain CPU utilization and memory utilization once per minute.

[0058] The node registration center 103 periodically obtains the historical performance index data of each child node within a preset historical time window based on the entry IP of each child node, and updates the node master table with the value obtained by arithmetic averaging of the historical performance index data within the preset historical time window as the target value of the performance index, and saves or updates the node master table to the node database.

[0059] For example, the preset historical time window can be pre-set according to the current needs of the aviation product query business scenario and the load fluctuation characteristics of the node cluster, such as 5 minutes.

[0060] The node database is used to persistently store the real-time liveness status (such as online / offline) and resource load indicators (such as CPU utilization, memory utilization, disk space and network I / O utilization) of each node in the node cluster, as well as the node summary table.

[0061] For example, assuming the preset historical time window is set to 5 minutes, and the performance indicators are CPU utilization and memory utilization, the node registration center obtains the historical values ​​of CPU utilization and memory utilization in the previous 5 minutes for each sub-execution node entry IP every 5 minutes, and calculates the arithmetic average of CPU utilization and memory utilization respectively, and updates the node master table as the target value.

[0062] For example, the node registration center 103 can dynamically allocate a specified number of sub-execution nodes according to the current overall load situation to ensure maximum resource utilization. Then, it can prioritize and sort all sub-execution nodes from largest to smallest, and extract a specified number of sub-execution nodes from the top of the sort to generate a sub-node table.

[0063] For example, the node registration center 103 can introduce a deep learning algorithm to dynamically allocate a specified number of sub-execution nodes based on the current overall load. Specifically, this includes: first, collecting historical load data of the current node cluster in real time (such as CPU utilization and memory utilization) and specific business metrics in the aviation product query scenario (such as requests per second (QPS), response latency (RT), error rate, and external event tags (such as the start of a major promotional event)); then, cleaning and normalizing all the collected raw data, extracting features, and converting key features such as timestamps and transaction volumes into sequence formats suitable for deep learning model processing to generate training samples; then using these training samples to train a pre-built LSTM neural network to generate a load prediction model, which outputs the predicted load for future periods, i.e., the resource demand trend range; then, comparing the predicted load output by the model with the actual capacity of the current node cluster; if the predicted load continues to exceed a set safety threshold (e.g., reaching 80% of the current capacity); If the load continues for two cycles, then node expansion is performed. The required number of new nodes is calculated (e.g., the difference between the predicted load and the current actual capacity is divided by the baseline carrying capacity of the current minimum specification node, and the result is rounded up). The number of new nodes is added to the current number of nodes to obtain the specified number. If the predicted load does not exceed the set safety threshold, then node reduction is performed. The required number of nodes to be reduced is calculated (e.g., the difference between the current actual capacity and the predicted load is divided by the baseline carrying capacity of the current minimum specification node, and the result is rounded up). The number of nodes to be reduced is subtracted from the current number of nodes to obtain the target number. At the same time, the target number is compared with the preset minimum number of surviving instances, and the larger of the two is taken as the final specified number to avoid the avalanche effect caused by excessive reduction.

[0064] For example, the child node table construction process can also be as follows: First, scan the main node table, excluding all child execution nodes whose liveness status is marked as "offline". Then, based on the interface ID of the current source query request and the corresponding performance configuration weight, calculate the node priority by combining the performance indicators of each child execution node in the main node table, and generate a node child table corresponding to the interface ID according to the node priority from largest to smallest. Wherein, when the performance indicators are CPU utilization and memory utilization, the priority of the child execution node can be determined by using the CPU idle rate and memory idle rate determined based on CPU utilization and memory utilization, combined with the performance configuration weight.

[0065] The node registration center 103 will forcibly adjust the priority of the child execution node whose performance index exceeds the preset overload threshold to 0 in the corresponding child node table.

[0066] For example, when performance metrics include CPU utilization and memory utilization, the corresponding preset overload threshold for CPU utilization can be set to 80%, and the preset overload threshold for memory utilization can be set to 85%. When the CPU utilization of a child execution node is not less than 80%, or the memory utilization is not less than 85%, the node registration center 103 will forcibly adjust the priority of the current child execution node in the child node table to 0.

[0067] Therefore, by combining the resource consumption preferences of query requests with the performance indicators of nodes to calculate the priority of each sub-execution node, it is possible to reduce the priority of a node when its resource utilization is too high, thereby reducing the number of query tasks processed by that node and assigning more query tasks to nodes with higher priority and lower resource utilization. This effectively avoids single-point overload, achieves overall load balancing of the node cluster, and ensures high availability and low latency response for aviation query services.

[0068] The node registry 103 can check the liveness status of child nodes through the child node health detection interface. For offline child nodes, the node registry 103 sets their liveness status in the node master table to offline, and also sets the CPU and memory usage of the child node stored in the node master table to 0.

[0069] For example, such as Figure 5 As shown, Figure 5 This is a schematic diagram illustrating a child node table construction process, provided as an exemplary embodiment. Figure 5 It includes a main node table 1 and sub-node tables 1 and 2 constructed based on the sub-execution nodes in the main node table.

[0070] The node master table 1 includes five key fields: node number, CPU utilization, memory utilization, node IP, and liveness status. This node master table consists of n sub-execution nodes. The liveness status of the sub-execution nodes with node numbers n-1 and n is offline. The CPU utilization and memory utilization of these two nodes are set to 0 in the node master table 1. The nodes with node numbers n-1 and n are not included in the corresponding sub-node tables 1 and 2.

[0071] If the CPU utilization of the child execution node with node number n-3 is 80%, which is not less than the corresponding preset overload threshold of 80%, and the corresponding memory utilization is 70%, which is less than the corresponding preset overload threshold of 85%, then the priority of the child execution node with node number n-3 in child node table 1 and child node table 2 will be adjusted to 0.

[0072] If the CPU utilization of the child execution node with node number n-2 is 65%, which is less than the corresponding preset overload threshold, while the corresponding memory utilization is 85%, which is not less than the corresponding preset overload threshold of 85%, then the priority of the child execution node with node number n-2 in child node table 1 and child node table 2 will be adjusted to 0.

[0073] The node priority of each sub-execution node in sub-node table 1 is determined based on the performance configuration weight sent by interface IDI1 and the corresponding CPU utilization and memory utilization in node total table 1; the node priority of sub-node table 2 is determined based on the performance configuration weight sent by interface IDI2 and the corresponding CPU utilization and memory utilization in node total table 1.

[0074] like Figure 5 As shown, the CPU utilization of the child execution node with node number 1 is 50% and the memory utilization is 60%. When the priority of this node is determined based on the performance configuration weights sent through interface IDI1, with a CPU weight coefficient of 0.5 and a memory weight coefficient of 0.5, the priority of the child execution node with node number 1 is... ,in, This indicates the CPU idle rate of the child execution node with sequence number 1. This indicates the memory free rate of the child execution node with the node number 1.

[0075] When the priority of a node is determined based on the performance configuration weights sent via interface IDI2, with a CPU weight coefficient of 0.7 and a memory weight coefficient of 0.3, the priority of the child execution node with sequence number 1 of that node is... .

[0076] Node registration center 103 also sets the CPU and memory usage of nodes with an offline status to 0 in the node database.

[0077] The node registration center 103 alerts the administrator via email, SMS, and other means to nodes that fail the health check.

[0078] After the node registration center 103 forms the node sub-table, it can assemble all interface IDs and corresponding sub-node tables into a subscription result and return it to the request scheduling node 102.

[0079] In some embodiments, the sub-execution node 104 is deployed independently and is pluggable to facilitate expansion as needed.

[0080] For example, in this application scenario 100, an API gateway based on a 10 Gigabit Ethernet interface card may also be included. This API gateway can be used to receive and output large-scale messages, effectively authenticate various aviation query requests, and route them to the appropriate backend request scheduling node 102, thereby effectively implementing circuit breaking and rate limiting for query requests that cause failures.

[0081] For example, in this application scenario 100, load balancing can also be deployed in multiple layers. By deploying it in front of the API gateway, request scheduling node 102, and node registration center 103, the scalability of each architectural component can be effectively enhanced, system performance can be improved, and high availability can be guaranteed.

[0082] For example, such as Figure 6 As shown, Figure 6 This is a schematic diagram of an aviation product query process provided for an exemplary embodiment. The aviation product query process includes an aviation query request initiator 101, an API gateway 601, an aggregation application load balancer 602, an aggregation application 603, a node registration center load balancer 604, a node registration center 103, multiple sub-execution node load balancers (such as sub-execution node load balancers 605-1, 605-2 to 605-n), multiple sub-execution node clusters (such as sub-execution node clusters 104-1, 104-2 to 104-n), and multiple sub-execution node containers (such as sub-execution node containers 606-1, 606-2 to 606). -n) and multiple sub-execution node monitors (such as sub-execution node monitor 607-1, sub-execution node monitors 607-2 to 607-n); wherein, each sub-execution node cluster contains a sub-execution node container and a sub-execution node monitor (such as sub-execution node 104-1 cluster including sub-execution node container 606-1 and sub-execution node monitor 607-1, sub-execution node 104-2 cluster including sub-execution node container 606-2 and sub-execution node monitor 607-2, and sub-execution node 104-n cluster including sub-execution node container 606-n and sub-execution node monitor 607-n).

[0083] Among them, API gateway 601 can effectively authenticate the source query request sent by the initiator of the aviation query request 101 and route it to the appropriate backend aggregation application 603.

[0084] The aggregation application load balancer 602 is deployed between the aviation query request initiator 101 and the aggregation application 603 to help distribute massive front-end source query requests evenly to the back-end aggregation application, avoid single point of overload, and improve query high availability.

[0085] The aggregation application 603 splits the source query request sent by the API gateway 601 and distributes it to the sub-execution node containers 606-1 to 606-n.

[0086] Multiple sub-execution nodes are deployed in a load-balanced manner between the aggregated application 603 and multiple sub-execution node containers, serving as the core scheduling engine. This facilitates cluster-level computing power balancing and automatic fault isolation, thereby improving resource utilization.

[0087] The node registry load balancer 604 is deployed between the aggregation application 603 and the node registry 103 to help support the high-frequency read and write requests from the aggregation application 603 to the node registry 103, and to ensure the continuous stability and high availability of data management in the node registry 103.

[0088] The node registration center 103 communicates with the sub-execution node monitoring 607-1 to sub-execution node monitoring 607-n to obtain information such as the health status and running performance of each sub-execution node container in real time, and dynamically updates the node master table accordingly, providing data support for the intelligent scheduling of the aggregation application 603.

[0089] The sub-execution node containers contained in each sub-execution node cluster are used as actual computing execution units, receiving sub-requests distributed by the aggregation application 603, concurrently calling the underlying data source for query processing, and returning aviation query response results.

[0090] The monitoring of each sub-execution node in the sub-execution node cluster is used to continuously collect runtime performance metrics (such as CPU utilization, memory usage, response latency, etc.) of the corresponding sub-execution node containers, and periodically report these time-series data to the node registration center 103.

[0091] For example, such as Figure 7 As shown, Figure 7 This is a flowchart illustrating a product query method provided as an exemplary embodiment. The aviation product query method, applied to a request scheduling node 102, includes: S701. The received source query request is split into multiple sub-requests.

[0092] The source query request includes multiple sets of query parameters arranged in a preset uniform structure; the query parameters are used to characterize the product attributes of aviation products.

[0093] The source query request is a structured retrieval instruction for aviation product query scenarios; the query parameters can be a set of parameters that define the business attributes, rules and constraints of aviation queries.

[0094] For example, when the source query request is a comprehensive search request for connecting flights, the corresponding query parameters may include the departure airport code, destination airport code, travel date range, passenger type, and cabin class preference, etc.

[0095] S702, Send a request to subscribe to the sub-node table to the node registration center 103; the request to subscribe to the sub-node table includes requesting the scheduling node 102 to determine the performance configuration weight based on the service type of the source query request.

[0096] In some embodiments, the service type of the source query request can be classified based on the load characteristics of the source query request; the service type of the source query request includes at least one of computing power sensitive type, capacity sensitive type and mixed load type, and different service types correspond to different performance configuration weights.

[0097] The load characteristics of the source query request are used to characterize the resource consumption preference for executing the current source query request. By using the load characteristics of the source query request to classify the business type of the source query request and determine the corresponding performance configuration weight, a basis can be provided for subsequent node priority calculation. This is beneficial for matching appropriate execution nodes according to the resource consumption preference of the current source query request, thereby improving the response performance of the query request.

[0098] The computational power sensitive category consists of source query requests that have high computational power requirements, corresponding to CPU-intensive and complex logical operation scenarios. For example, a source query request in the computational power sensitive category could be a real-time freight rate calculation.

[0099] Capacity-sensitive requests are source query requests that have high requirements for memory bandwidth / capacity, corresponding to memory-intensive scenarios. For example, capacity-sensitive source query requests can be flight queries or historical order queries.

[0100] Hybrid load classes are source query requests that balance computing power and memory bandwidth / capacity requirements, corresponding to resource balancing scenarios. For example, source query requests in hybrid load classes can be query services such as flight search and remaining ticket display, which require real-time price calculation and rule matching, as well as fast retrieval and caching of massive amounts of flight, seat, and passenger information from the database.

[0101] Different business types of source query requests correspond to different performance configuration weights. For example, when the performance metrics are CPU utilization and memory utilization, in the performance configuration weights for source query requests with computing power sensitive business types, the weight coefficient of CPU utilization is higher than that of memory utilization; in the performance configuration weights for source query requests with capacity sensitive business types, the weight coefficient of CPU utilization is lower than that of memory utilization; and in the performance configuration weights for source query requests with mixed load business types, the weight coefficient of CPU utilization is equal to that of memory utilization.

[0102] For example, assuming the performance metrics are CPU utilization and memory utilization, when the business type of the source query request is computing power sensitive, the corresponding performance configuration weights include a CPU weight coefficient of 0.7 and a memory weight coefficient of 0.3; when the business type of the source query request is capacity sensitive, the corresponding performance configuration weights include a CPU weight coefficient of 0.3 and a memory weight coefficient of 0.7; when the business type of the source query request is mixed load, the corresponding performance configuration weights include a CPU weight coefficient of 0.5 and a memory weight coefficient of 0.5.

[0103] S703. Distribute multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registration center 103, so that the multiple sub-execution nodes can execute their respective distributed sub-requests in parallel; the sub-node table includes the priority of each sub-execution node determined by the node registration center 103, and the priority is determined based on the performance configuration weight and the performance index of the sub-execution node.

[0104] Among them, performance metrics are used to characterize the load status of sub-execution nodes.

[0105] The child node table includes the priority of each child execution node determined by the node registration center 103, as well as the node IP and node sequence number.

[0106] Therefore, by using the performance configuration weight determined based on the business type of the source query request and the performance indicators of the sub-execution nodes to determine the priority, a basis can be provided for generating an ordered sub-node table, while also helping to distribute subsequent requests to the best execution node, improving resource utilization, and preventing the sub-execution node from crashing due to sudden traffic.

[0107] S704. Receive aviation query response results returned by some or all of the sub-execution nodes among multiple sub-execution nodes.

[0108] S705. Based on the aviation query response results returned by some or all of the multiple sub-execution nodes, send the target response result to the aviation query requester 101 of the source query request.

[0109] The target response result is the aviation query response results returned by some or all of the multiple sub-execution nodes, assembled according to the order of the corresponding sub-requests in the source query request.

[0110] Therefore, by splitting the received source query request into multiple sub-requests through the request scheduling node, the pressure on a single backend server to process messages can be reduced when dealing with a large number of aviation product queries. The request scheduling node sends a request to the node registry center to subscribe to the sub-node table, carrying performance configuration weights determined based on the business type of the source query request. This provides an effective quantitative standard for prioritizing sub-execution nodes, helping to select a more suitable execution node for the current query request while ensuring that the returned sub-node table accurately reflects the optimal node scheduling order that meets the current request's business requirements. The request scheduling node then selects multiple sub-nodes from the sub-node table returned by the node registry center. The execution node distributes multiple sub-requests and aggregates the aviation query response results returned by the parallel execution of each sub-request. This effectively improves the request processing efficiency and reduces query response time in scenarios involving large-volume aviation product queries. The priority of each sub-execution node in the sub-node table, determined by the node registry center, is based on performance configuration weights and performance indicators used to characterize the load status of the sub-execution node. This avoids distributing requests to already overloaded nodes, achieving load balancing, improving resource utilization, and reducing request response latency. At the same time, it prevents sub-execution nodes from crashing due to sudden traffic surges, thereby significantly improving the efficiency and fault tolerance of the query service.

[0111] In some embodiments, distributing multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registration center 103 includes: distributing multiple sub-requests in descending order of priority of the sub-execution nodes in the sub-node table, provided that the number of sub-requests does not exceed the number of nodes in the sub-node table.

[0112] In some embodiments, distributing multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registration center 103 further includes: if the number of sub-requests exceeds the number of nodes in the sub-node table, distributing the multiple sub-requests in multiple rounds according to the number of nodes in the sub-node table, and distributing the sub-requests in the last round according to the priority of the sub-execution nodes in the sub-node table from high to low.

[0113] For example, assuming the current number of sub-requests is 30 and the number of nodes in the sub-node table is 12, the first 24 sub-requests are evenly distributed among these 12 sub-execution nodes (each sub-execution node gets 2); the remaining 6 sub-requests enter the last round and are distributed in descending order of priority of the sub-execution nodes, with these 6 requests being assigned to the top 6 sub-execution nodes first.

[0114] Therefore, in the face of high-frequency and massive concurrent requests in the aviation query scenario, by adopting a multi-round uniform distribution in the early stage, it can be ensured that all nodes can bear the basic concurrent pressure and achieve load balancing. The priority distribution in the later stage can effectively reduce the overall processing time of requests and reduce computational overhead.

[0115] In some embodiments, receiving aviation query response results returned by some or all of the multiple sub-execution nodes includes: when the processing time of the source query request reaches a preset timeout threshold, identifying at least one incomplete first target sub-request among the multiple sub-requests, and actively giving up waiting for the aviation query response result of the first target sub-request.

[0116] The preset timeout threshold can be pre-set by those skilled in the art based on the statistical distribution of historical request response delays, the overall load status of the node cluster, and the business complexity of the current source query request.

[0117] The first target sub-request is a sub-request that has not yet returned a query response result when the processing time of the source query request reaches the preset timeout threshold.

[0118] For example, suppose the current source query request A is split into sub-request 1, sub-request 2 and sub-request 3, and the preset timeout threshold is 20 seconds; when the processing time of source query request A reaches 20 seconds, sub-request 1 and sub-request 2 return the corresponding normal query response results, while sub-request 3 does not return. At this time, sub-request 3 is regarded as the first target sub-request, and the waiting for sub-request 3 is actively abandoned. The corresponding query response results returned by sub-request 1 and sub-request 2 are used to assemble a partial response and return it to the initiator of the aviation query request of source query request A.

[0119] Therefore, when multiple child nodes process tasks in parallel, if a child node's processing speed is slow and exceeds the predetermined time limit, the scheduling node will request that the scheduling node no longer wait for that node and directly assemble the output parameters, thus ensuring the high timeliness of the interface server.

[0120] In some embodiments, after receiving the aviation query response results returned by some or all of the multiple sub-execution nodes, the method further includes: determining at least one second target sub-request among the multiple sub-requests that has an execution error, and removing the aviation query response result corresponding to the second target sub-request.

[0121] The second target sub-request is a failed sub-request that, after being distributed to the sub-execution node, fails to return valid business data due to various abnormal conditions.

[0122] Therefore, discarding the aviation query response results corresponding to the sub-requests that have encountered errors can effectively prevent invalid response results from causing a global avalanche, ensuring the accuracy and consistency of aviation product query responses while improving query speed and user experience.

[0123] In some embodiments, based on the aviation query response results returned by some or all of the multiple sub-execution nodes, a target response result is sent to the aviation query requester 101 of the source query request, including: generating a target response result based on the aviation query response results obtained, excluding the aviation query response results of the first target sub-request and the aviation query response results of the second target sub-request, and sending it to the aviation query requester 101 of the source query request.

[0124] Therefore, by discarding the aviation query response results corresponding to the executed sub-requests that have encountered errors, as well as the aviation query response results of the timed-out sub-requests that have been actively abandoned, and by generating the target response result using the aviation query response results of normally executed sub-requests other than timed-out requests and abnormal requests, it is possible to ensure the exposure of effective query response results, improve query fault tolerance, and ensure the high availability and business continuity of aviation product queries under various circumstances.

[0125] For example, such as Figure 8 As shown, Figure 8 A schematic diagram of the structure of an aviation product query system 800 provided for an exemplary embodiment. The aviation product query system 800 is applied to a request scheduling node 102 and includes: The request splitting module 801 is used to split the received source query request into multiple sub-requests.

[0126] The source query request includes multiple sets of query parameters arranged in a preset uniform structure; the query parameters are used to characterize the product attributes of aviation products.

[0127] The request distribution module 802 is used to send a request to subscribe to the child node table to the node registration center 103; the request to subscribe to the child node table includes the performance configuration weight determined by the request scheduling node 102 based on the business type of the source query request.

[0128] The business type of the source query request can be classified based on the load characteristics of the source query request; the business type of the source query request includes at least one of computing power sensitive type, capacity sensitive type and mixed load type, and different performance configuration weights are determined for different business types.

[0129] The request distribution module 802 is also used to distribute multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registration center 103, so that the multiple sub-execution nodes can execute their respective distributed sub-requests in parallel; the sub-node table includes the priority of each sub-execution node determined by the node registration center 103, and the priority is determined based on the performance configuration weight and the performance index of the sub-execution node.

[0130] Among them, performance metrics are used to characterize the load status of sub-execution nodes.

[0131] The request-response module 803 is used to receive aviation query response results returned by some or all of the multiple sub-execution nodes.

[0132] The request-response module 803 is also used to send the target response result to the aviation query requester 101 of the source query request based on the aviation query response results returned by some or all of the multiple sub-execution nodes.

[0133] In some embodiments, the aviation product query system 800 includes hardware structures and / or software modules corresponding to the execution of each function in order to achieve the above-described functions. Those skilled in the art will readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0134] This application embodiment can divide the aviation product query system 800 into functional modules according to the above method embodiment. For example, each function can be divided into its own functional module, or two or more functions can be integrated into a feature extraction module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation. Figure 9 As shown, the computer device provided in this application embodiment may include a processor 901, a bus 902, a communication interface 903, and a memory 904. The processor 901, memory 904, and communication interface 903 communicate with each other via the bus 902. It should be understood that this application does not limit the number of processors and memories in the network device.

[0135] The 902 bus can be a PCI bus, an Extended Industry Standard Architecture (EISA) bus, or a UB bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 9 The bus 902 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 902 may include a path for transmitting information between various components of the network device (e.g., memory 904, processor 901, communication interface 903).

[0136] Processor 901 may include any one or more processors such as CPU, graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0137] The memory 904 may include volatile memory, such as random access memory (RAM). The processor 901 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0138] The communication interface 903 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between network devices and other devices or communication networks.

[0139] The memory 904 stores executable program code, which the processor 901 executes to implement the functions of the aforementioned method embodiments. That is, the memory 904 stores instructions for executing the aforementioned flow rate measurement method.

[0140] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer programs or instructions. When a computer program or instruction is loaded and executed on a computer, the processes or functions of the embodiments of this application are performed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable module. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, a computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD).

[0141] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for querying aviation products, applied to a request scheduling node, characterized in that, include: The received source query request is split into multiple sub-requests; The source query request includes multiple sets of query parameters arranged according to a preset uniform structure; The query parameters are used to characterize the product attributes of aviation products; Send a request to subscribe to the child node table to the node registry center; The subscription sub-node table request includes the performance configuration weight determined by the request scheduling node based on the business type of the source query request; The multiple sub-requests are distributed to multiple sub-execution nodes in the sub-node table returned by the node registry center, so that the multiple sub-execution nodes execute their respective distributed sub-requests in parallel; the sub-node table includes the priority of each sub-execution node determined by the node registry center, the priority being determined based on the performance configuration weight and the performance index of the sub-execution node; the performance index is used to characterize the load status of the sub-execution node; Receive aviation query response results returned by some or all of the multiple sub-execution nodes; Based on the aviation query response results returned by some or all of the multiple sub-execution nodes, the target response result is sent to the aviation query requester of the source query request.

2. The aviation product query method according to claim 1, characterized in that, The business types include at least one of computing power sensitive type, capacity sensitive type and mixed load type, and different performance configuration weights are determined for different business types.

3. The aviation product query method according to claim 1, characterized in that, Distribute the multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registration center, including: If the number of requests in the sub-request does not exceed the number of nodes in the sub-node table, the multiple sub-requests are distributed in descending order of priority of the sub-execution nodes in the sub-node table.

4. The aviation product query method according to claim 3, characterized in that, Distributing the multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registration center also includes: If the number of sub-requests exceeds the number of nodes in the sub-node table, the multiple sub-requests are distributed in multiple rounds according to the number of nodes in the sub-node table, and in the last round, the sub-requests are distributed in descending order of priority of the sub-execution nodes in the sub-node table.

5. The aviation product query method according to claim 1, characterized in that, Receiving the aviation query response results returned by some or all of the plurality of sub-execution nodes includes: When the processing time of the source query request reaches a preset timeout threshold, at least one first target sub-request that has not been completed among the multiple sub-requests is identified, and the waiting for the aviation query response result of the first target sub-request is actively abandoned.

6. The aviation product query method according to claim 5, characterized in that, After receiving the aviation query response results returned by some or all of the multiple sub-execution nodes, the method further includes: Identify at least one second target sub-request among the plurality of sub-requests that has resulted in an execution error, and remove the aviation query response result corresponding to the second target sub-request.

7. The aviation product query method according to claim 6, characterized in that, The step of sending the target response result to the aviation query requester of the source query request based on the aviation query response results returned by some or all of the multiple sub-execution nodes includes: Based on the obtained aviation query response results other than the aviation query response results of the first target sub-request and the second target sub-request, the target response result is generated and sent to the aviation query requester of the source query request.

8. A product query system, applied to a request scheduling node, characterized in that, include: The request splitting module is used to split the received source query request into multiple sub-requests; The source query request includes multiple sets of query parameters arranged according to a preset uniform structure; The query parameters are used to characterize the product attributes of aviation products; The request distribution module is used to send a request to subscribe to a sub-node table to the node registration center; the request to subscribe to a sub-node table includes the performance configuration weight determined by the request scheduling node based on the business type of the source query request; The request distribution module is further configured to distribute the multiple sub-requests to multiple sub-execution nodes in the sub-node table returned by the node registration center, so that the multiple sub-execution nodes execute their respective distributed sub-requests in parallel; the sub-node table includes the priority of each sub-execution node determined by the node registration center, the priority being determined based on the performance configuration weight and the performance index of the sub-execution node; the performance index is used to characterize the load status of the sub-execution node; The request-response module is used to receive aviation query response results returned by some or all of the multiple sub-execution nodes; The request-response module is also used to send the target response result to the aviation query requester of the source query request based on the aviation query response results returned by some or all of the multiple sub-execution nodes.

9. A computer device, characterized in that, The device includes a processor and a memory, the processor being coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computer device to implement the aviation product query method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer-executable instructions that, when executed on a computer, cause the computer to perform the aviation product query method as described in any one of claims 1-7.

Images