Block chain node route distribution method and device, equipment and medium

Abstract

The invention relates to the technical field of route distribution, and discloses a block chain node route distribution method, device and equipment and a medium, and the method comprises the steps: obtaining the historical load data of block chain nodes, and calculating the expected processing delay, the expected concurrent request amount and the network topology distance of each block chain node based on the historical load data; performing performance quantitative analysis on the expected processing delay, the expected concurrent request quantity and the network topology distance to obtain a processing delay metric value, a concurrent request metric value and a network topology distance metric value; determining a corresponding scene weight coefficient according to the business application scene of the block chain node; calculating a routing distribution cost characteristic value according to the processing delay metric value, the concurrent request metric value, the network topology distance metric value and the scene weight coefficient; and performing a routing distribution decision on the block chain node according to the routing distribution cost feature value. According to the invention, the accuracy of node routing distribution can be improved.

Description

Technical Field

[0001] This invention relates to the field of routing distribution, and more particularly to a method, apparatus, device, and medium for routing distribution of blockchain nodes. Background Technology

[0002] With the rapid development of blockchain technology and the continuous expansion of its application scenarios, the number of nodes in blockchain networks is increasing daily, and the services they support are becoming more diversified and complex. In practical applications, how to efficiently and intelligently route and distribute transaction requests or data synchronization tasks to appropriate blockchain nodes has become a key technical issue for improving overall network performance, ensuring service quality, and optimizing resource utilization.

[0003] Currently, common blockchain node routing and distribution methods are mostly based on single or simple static indicators, such as random selection, round-robin scheduling, or decisions based solely on the node's real-time network latency. While these methods are simple to implement, they have significant limitations: First, they fail to comprehensively consider the historical load patterns of nodes, leading to performance bottlenecks or uneven resource allocation under dynamic loads; second, existing methods lack the ability to adapt to different business application scenarios, failing to achieve "scenario-based" intelligent routing.

[0004] Therefore, how to route and distribute blockchain nodes according to different business scenarios in order to improve the accuracy of blockchain node routing and distribution has become an urgent problem to be solved. Summary of the Invention

[0005] This invention provides a blockchain node routing and distribution method, apparatus, device, and medium, the main purpose of which is to solve the problem of low accuracy in blockchain node routing and distribution.

[0006] Firstly, to achieve the above objectives, the present invention provides a blockchain node routing and distribution method, comprising: Obtain historical load data of multiple blockchain nodes, and calculate the expected processing latency, expected concurrent request volume, and network topology distance between each blockchain node and a preset server within a preset time period based on the historical load data. Performance quantification analysis is performed based on the expected processing latency, expected concurrent request volume, and network topology distance corresponding to each blockchain node to obtain the processing latency metric, concurrent request metric, and network topology distance metric for each blockchain node. Determine the scenario weight coefficients corresponding to the processing latency metric, the concurrent request metric, and the network topology distance metric based on the business application scenario of the blockchain node; Based on the processing latency metric, concurrent request metric, and network topology distance metric of each blockchain node, as well as the corresponding scenario weight coefficient, calculate the routing distribution cost feature value of the corresponding blockchain node; The routing distribution decision is made for the blockchain nodes based on the routing distribution cost feature value corresponding to different blockchain nodes.

[0007] Secondly, the present invention also provides a blockchain node routing and distribution device, comprising: The expected load data calculation module is used to obtain historical load data of multiple blockchain nodes, and calculate the expected processing delay, expected concurrent request volume, and network topology distance between each blockchain node and the preset server within a preset time period based on the historical load data. The load performance quantification analysis module is used to perform performance quantification analysis based on the expected processing latency, expected concurrent request volume and network topology distance of each blockchain node, and to obtain the processing latency metric, concurrent request metric and network topology distance metric for each blockchain node. The scenario weight coefficient determination module is used to determine the scenario weight coefficients corresponding to the processing delay metric, the concurrent request metric, and the network topology distance metric based on the business application scenario of the blockchain node. The routing cost feature value calculation module is used to calculate the routing distribution cost feature value of the corresponding blockchain node based on the processing latency metric, concurrent request metric, network topology distance metric and the corresponding scenario weight coefficient of each blockchain node. The node routing and distribution decision module is used to make routing and distribution decisions for the blockchain nodes based on the routing and distribution cost feature values ​​corresponding to different blockchain nodes.

[0008] Thirdly, the present invention also provides an electronic device, the electronic device comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the blockchain node routing and distribution method described above.

[0009] Fourthly, the present invention also provides a computer-readable storage medium storing at least one computer program, which is executed by a processor in an electronic device to implement the blockchain node routing and distribution method described above.

[0010] This invention comprehensively calculates the expected processing latency, expected concurrent request volume, and network topology distance to a preset server for each blockchain node within a preset time period based on historical load data. This enables multi-dimensional dynamic prediction of blockchain nodes, significantly improving the overall processing efficiency and resource utilization of the subsequent blockchain network. By quantitatively analyzing the three key indicators of expected processing latency, expected concurrent request volume, and network topology distance, these indicators are transformed into standardized metrics that can be compared horizontally. This allows the processing latency metric, concurrent request metric, and network topology distance metric to objectively and fairly reflect the core performance characteristics of each node, eliminating the differences in dimensions and comparability barriers between different indicators.

[0011] Specifically, the weight coefficients of each metric are dynamically determined based on specific business application scenarios (such as high-frequency trading, data storage, or the Internet of Things), enabling scenario-adaptive and strategy-flexible node selection. This ensures that the blockchain node that best meets the current scenario's optimal goal is always selected in complex and ever-changing business environments, reducing the blindness of request routing. By calculating the routing distribution cost feature value of each node, a clear and unified ranking basis is provided for routing distribution decisions. This allows for the automatic and efficient identification and priority selection of high-quality nodes with the lowest overall cost, achieving dynamic and optimal task distribution and ultimately improving the overall throughput efficiency of the blockchain network. Based on the routing distribution cost feature value, automated and intelligent node selection and routing distribution decisions are achieved, greatly improving the accuracy of blockchain node routing distribution, as well as the task distribution efficiency and resource utilization rationality of blockchain nodes. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram of an application environment for a blockchain node routing and distribution method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a blockchain node routing and distribution method according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating a process for calculating the expected processing latency, expected concurrent request volume, and network topology distance between each blockchain node and a preset server within a preset time period based on the historical load data, according to an embodiment of the present invention. Figure 4This is a functional block diagram of a blockchain node routing and distribution device according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device that implements a blockchain node routing and distribution method according to an embodiment of the present invention; Figure 6 This is another structural schematic diagram of an electronic device that implements a blockchain node routing and distribution method, as provided in an embodiment of the present invention.

[0014] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0015] To enable those skilled in the art to better understand the technical solutions of this disclosure, and to fully understand and implement the process of how this disclosure applies technical means to solve technical problems and achieve corresponding technical effects, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, not all embodiments. The embodiments of this disclosure and the various features within them can be combined with each other without conflict, and the resulting technical solutions are all within the protection scope of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort should fall within the protection scope of this disclosure.

[0016] It should be noted that the terms "first," "second," etc., used in this disclosure and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0017] This application provides a blockchain node routing and distribution method. The execution entity of this method includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the device provided in this application: a server, a terminal, etc. In other words, the blockchain node routing and distribution method can be executed by software or hardware installed on a terminal device or a server device. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0018] This invention discloses a blockchain node routing and distribution method, which can be applied to applications such as... Figure 1 In this application environment, the client communicates with the server via a network. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will now be described in detail through specific embodiments.

[0019] Reference Figure 2 The diagram shown is a flowchart illustrating a blockchain node routing and distribution method according to an embodiment of the present invention. In this embodiment, the blockchain node routing and distribution method includes: S1. Obtain historical load data of multiple blockchain nodes, and calculate the expected processing delay, expected concurrent request volume, and network topology distance between each blockchain node and the preset server within a preset time period based on the historical load data.

[0020] In this embodiment of the invention, the historical load data refers to data related to the workload processed by the blockchain node over a past period, including the number of transactions processed, request frequency, resource usage, etc., which reflects the node's past working status and pressure; the expected processing latency is an estimate of the time required for the blockchain node to process requests within a preset time period based on historical load data and other information, reflecting the expected speed at which the blockchain node processes requests; the expected concurrent request volume is an estimate of the number of requests that the blockchain node can process simultaneously within a preset time period based on historical load data, reflecting the blockchain node's ability to handle multiple requests simultaneously; the network topology distance is an indicator of the path between the blockchain node and the preset server, typically considering factors such as the number of routing hops between nodes, to reflect the length or difficulty of the path for request transmission in the network.

[0021] like Figure 3 As shown in this embodiment of the invention, the step of calculating the expected processing latency, expected concurrent request volume, and network topology distance between each blockchain node and the preset server within a preset time period based on the historical load data includes: Extract the historical request records of each blockchain node within a preset time period from the historical load data, and clean and format the historical request records to obtain a standard time-series dataset. Based on the standard time-series dataset, calculate the total request processing time and the corresponding number of request records for each blockchain node in each time window within a preset time period. Divide the total request processing time of each time window by the corresponding number of request records to obtain the average request processing time of the blockchain node in the time window; Calculate the average of the average request processing time for all the time windows, and use the average as the expected processing delay of the blockchain node; Based on the standard time-series dataset, the peak concurrent requests of each blockchain node within a historical interval that has the same time-series characteristics as a preset time period are statistically analyzed. The expected number of concurrent requests for the blockchain node in the next corresponding time period is calculated using a preset time series prediction model and the peak concurrent request. Each of the blockchain nodes sends network probe packets to a preset server, and the number of intermediate routers through which the network probe packets travel from the blockchain nodes to the server is counted. The number of routers is used as the routing hop count between the blockchain node and the server, and the routing hop count is used as the network topology distance between the blockchain node and the server.

[0022] In this embodiment of the invention, the historical load data is typically stored in different data sources such as databases and log files. By writing specific query statements (such as SQL statements for databases) or using corresponding file reading interfaces (such as for log files), all historical request records generated by each blockchain node within a preset time period are extracted from these data sources. The historical request records include information such as the request initiation time, request type, and processing result.

[0023] Historical request records may contain some abnormal or invalid data, such as missing data, incorrect formatting, and duplicate records. Data cleaning techniques will process historical request records, such as deleting duplicate records, filling in missing data (according to business rules or default values), and correcting data with incorrect formatting, to ensure the accuracy and consistency of the data. In order to facilitate subsequent calculations and analysis, the cleaned historical request records need to be formatted. For example, the initiation time of historical request records is uniformly converted into a specific time format (such as a timestamp or a standard date and time format), and the type of historical request record is represented by a uniform encoding, so that all request records have a uniform format and form a standard time-series dataset.

[0024] In detail, the preset time period is divided into multiple consecutive time windows according to a certain time interval. For example, if the preset time period is one day and the time interval is one hour, then this day will be divided into 24 time windows. For each time window, all request records belonging to that time window are selected from the standard time series dataset, these request records are processed, and the total request processing time of all requests in that time window is calculated. The total request processing time refers to the cumulative time from the time the request is initiated to the time the request is completed. At the same time, the number of request records in that time window is counted, that is, the number of requests that occur in that time window.

[0025] Specifically, for each time window, the total request processing time of that time window is divided by the corresponding number of request records. For example, if the total request processing time of a time window is 100 seconds and there are 10 request records in that time window, then the average request processing time of that time window is 100 seconds divided by 10, which is 10 seconds.

[0026] This involves summing up the average request processing times calculated for all time windows and then calculating the average of these average request processing times. For example, if there are 24 time windows, 24 average request processing times are calculated for each window. These 24 values ​​are then added together and divided by 24 to obtain the average of the average request processing times for all time windows. This average is used as the expected processing delay for blockchain nodes.

[0027] Furthermore, from the standard time series dataset, find the historical intervals that have the same time series characteristics as the preset time period. For example, if the preset time period is a certain time period of a certain day, then find the same time period of the same date (such as the same day of the week) in the historical data. Within this historical interval, count the number of concurrent requests at each time point, that is, the number of requests being processed at the same time. The peak of concurrent requests is the maximum number of concurrent requests within this historical interval.

[0028] In detail, a time series forecasting model is a model that predicts future data based on historical data. When calculating the expected concurrent request volume, the statistically obtained peak concurrent request volume is used as the input data of the model. The model will predict the concurrent request volume for the corresponding future time period (i.e., the preset time period) based on the patterns and trends in historical data. For example, the model may analyze factors such as the periodic changes and growth trends of historical peak concurrent requests to predict the expected concurrent request volume for the corresponding future time period.

[0029] Furthermore, on the blockchain node, network probing technologies (such as the ping command of the ICMP protocol or other specialized network probing tools) are used to send network probe packets to the preset server. When the network probe packets are transmitted in the network, they will pass through multiple intermediate routers. Through route tracing technology (such as the traceroute command), the relevant information of the intermediate routers that the network probe packets pass through from the blockchain node to the server can be recorded, and the number of these intermediate routers can be counted to obtain the number of route hops from the blockchain node to the preset server.

[0030] In the network topology, the number of hops can reflect the complexity of the path between two nodes and the ease of data transmission to a certain extent. Generally speaking, the more hops, the more intermediate nodes the request needs to pass through in the network, and the longer or more complex the path may be. Therefore, the number of hops is used as the network topology distance between the blockchain node and the preset server to measure the network connectivity between them.

[0031] In this embodiment of the invention, based on historical load data, the expected processing latency, expected concurrent request volume, and network topology distance to the preset server of each blockchain node within a preset time period are comprehensively calculated. This enables multi-dimensional dynamic evaluation of blockchain nodes, significantly improving the overall processing efficiency and resource utilization of the subsequent blockchain network, and reducing the blindness of request routing.

[0032] S2. Based on the expected processing latency, expected concurrent request volume, and network topology distance corresponding to each blockchain node, a performance quantification analysis is performed to obtain the processing latency metric, concurrent request metric, and network topology distance metric for each blockchain node.

[0033] In this embodiment of the invention, the processing latency metric is a quantified value obtained after performing performance quantification analysis on the expected processing latency of a blockchain node. It is used to compare the performance of different blockchain nodes in terms of processing latency, and the value directly reflects the quality of the blockchain node's processing latency. The concurrent request metric is used to measure the performance of a blockchain node in terms of its ability to handle concurrent requests. Comparing the concurrent request metric values ​​of different nodes can clearly show the differences in the ability of each node to handle concurrent requests. The network topology distance metric is used to compare the quality of network connections between different blockchain nodes and a preset server. The value reflects the complexity of the network path between the node and the server and the ease of data transmission.

[0034] In this embodiment of the invention, the performance quantification analysis based on the expected processing latency, expected concurrent request volume, and network topology distance corresponding to each blockchain node, to obtain the processing latency metric, concurrent request metric, and network topology distance metric for each blockchain node, includes: Obtain the first performance weight coefficient corresponding to the expected processing delay, the second performance weight coefficient corresponding to the expected concurrent request volume, and the third performance weight coefficient corresponding to the network topology distance; Calculate the relative latency ratio between the expected processing latency and the preset latency benchmark value, and multiply the relative latency ratio by the first performance weight coefficient to obtain the processing latency metric value of the blockchain node; Multiply the expected number of concurrent requests by the second performance weight coefficient to obtain the concurrent request metric of the blockchain node; The network topology distance is exponentially calculated with the preset maximum allowed distance threshold to obtain the distance standardization coefficient. The distance standardization coefficient is then multiplied by the third performance weight coefficient to obtain the network topology distance metric of the blockchain node.

[0035] Specifically, the processing latency metric is shown in the following formula: in, This represents the processing latency metric. This represents the first performance weighting coefficient. This indicates the expected processing delay. This represents the maximum delay reference value among the preset delay reference values. This represents the minimum delay reference value among the preset delay reference values.

[0036] Specifically, the concurrent request metric is shown in the following formula: in, This represents the concurrent request metric. This represents the second performance weighting coefficient. This indicates the expected number of concurrent requests.

[0037] In detail, the network topology distance metric is expressed by the following formula: in, This represents the network topology distance metric. Indicates the network topology distance. This indicates the preset maximum allowable distance threshold. This represents the third performance weighting coefficient. This represents the preset exponential slope parameter.

[0038] In this embodiment of the invention, the Analytic Hierarchy Process (AHP) is used to determine the first performance weight coefficient corresponding to the expected processing delay, the second performance weight coefficient corresponding to the expected concurrent request volume, and the third performance weight coefficient corresponding to the network topology distance. By constructing a hierarchical model, the blockchain node performance evaluation is taken as the target layer, and the expected processing delay, expected concurrent request volume, and network topology distance are taken as the criteria layer. For each factor in the criteria layer, the relative importance between them is determined by pairwise comparison.

[0039] For example, by comparing the expected processing latency and the expected concurrent request volume, we can determine which factor has a greater impact on node performance and give the corresponding comparison judgment value. Based on these comparison judgment values, we can construct a judgment matrix. By calculating the eigenvector and the largest eigenvalue of the judgment matrix, we can obtain the relative weights of each factor, that is, the first performance weight coefficient corresponding to the expected processing latency, the second performance weight coefficient corresponding to the expected concurrent request volume, and the third performance weight coefficient corresponding to the network topology distance.

[0040] In detail, a latency benchmark value is preset. This benchmark value is set according to the actual needs and performance requirements of the blockchain application. For example, in a financial transaction blockchain system with strict requirements for response time, the latency benchmark value may be set to an extremely short time. The expected processing latency of the blockchain node is compared with the preset latency benchmark value, and the relative latency ratio between them is calculated. The calculated relative latency ratio is multiplied by the corresponding first performance weight coefficient. Through multiplication, the relative latency ratio is weighted according to its importance to obtain the processing latency metric of the blockchain node, which can more accurately reflect the performance of the node in terms of processing latency.

[0041] Furthermore, the expected concurrent request volume of a blockchain node is multiplied by the corresponding second performance weight coefficient. Through multiplication, the expected concurrent request volume is weighted according to its importance to obtain the concurrent request metric of the blockchain node. This metric reflects the node's ability to handle concurrent requests and takes into account the relative importance of concurrent request volume in the overall performance evaluation, making it easier to compare and evaluate different nodes.

[0042] Furthermore, a maximum allowed distance threshold is preset. For example, in a blockchain network with a limited distribution range, the maximum allowed distance threshold might be a fixed number of router hops. The network topology distance of the blockchain node is then exponentially calculated with this maximum allowed distance threshold. For example, a specific exponential function (such as a power function with a certain base) is used to process the ratio between the two. Through exponential calculation, the network topology distance can be mapped to a more suitable range, resulting in a distance standardization coefficient. The calculated distance standardization coefficient is then multiplied by the corresponding third performance weight coefficient. Through multiplication, the distance standardization coefficient is weighted according to its importance to obtain the network topology distance metric of the blockchain node, which can more accurately reflect the node's performance in terms of network topology.

[0043] In this embodiment of the invention, by quantifying and analyzing three key indicators—expected processing latency, expected concurrent request volume, and network topology distance—they are transformed into standardized metrics that can be compared horizontally. This enables the processing latency metric, concurrent request metric, and network topology distance metric to objectively and fairly reflect the core performance characteristics of each node, eliminating the differences in dimensions and comparability barriers between different indicators.

[0044] S3. Determine the scenario weight coefficients corresponding to the processing latency metric, the concurrent request metric, and the network topology distance metric based on the business application scenario of the blockchain node.

[0045] In this embodiment of the invention, the business application scenarios of the blockchain node include high real-time network scenarios, high concurrency network scenarios, and high stability network scenarios. Based on the specific business application scenario in which the blockchain node is located, corresponding scenario weight coefficients are assigned to the processing latency metric, concurrent request metric, and network topology distance metric.

[0046] The scenario weighting coefficients reflect the importance of processing latency, concurrent request capability, and network topology distance to the overall performance evaluation of blockchain nodes and subsequent routing distribution under different business scenarios. For example, in business scenarios with extremely high real-time requirements, the scenario weighting coefficient for processing latency may be larger; while in business scenarios with high requirements for the number of device connections, the scenario weighting coefficient for concurrent request capability will be relatively higher. By setting scenario weighting coefficients, the performance evaluation of blockchain nodes can be made more closely aligned with actual business needs, and more accurately reflect the applicability and performance of nodes in different scenarios.

[0047] In this embodiment of the invention, determining the scenario weight coefficients corresponding to the processing latency metric, the concurrent request metric, and the network topology distance metric based on the business application scenario of the blockchain node includes: Identify the business type identifier of the target business carried by the blockchain node; The business application scenario category to which the blockchain node belongs is determined based on the business type identifier; Obtain the mapping relationship between the business application scenario category and the preset scenario weight coefficient, and determine the scenario weight coefficient corresponding to the business application scenario category based on the mapping relationship; If the business application scenario category is a high real-time network scenario, then the weight coefficient of the first scenario is configured to be greater than the weight coefficients of the second and third scenarios. If the business application scenario category is a high-concurrency network scenario, then the weight coefficient of the second scenario is configured to be greater than the weight coefficient of the first scenario and the weight coefficient of the third scenario. If the business application scenario category is a high-stability network scenario, then the weight coefficient of the third scenario is configured to be greater than the weight coefficient of the first scenario and the weight coefficient of the second scenario.

[0048] In this embodiment of the invention, when blockchain nodes carry out business operations, they interact with the business in various ways, leaving behind specific business characteristic information during these interactions. For example, in financial transactions, there are characteristics such as transaction amount, transaction type (e.g., transfer, payment), and identity information of the transacting parties; in IoT data collection, there are characteristics such as device type, data type, and collection frequency. By analyzing transaction records and data transmission logs on the blockchain nodes, these key business characteristics are extracted. These extracted characteristics are then matched with predefined feature templates for various business types. Each business type has its unique combination of characteristics. Through comparison and matching, the business type to which the target business belongs is determined, and its business type identifier is obtained.

[0049] In detail, a series of scenario classification rules are predefined. These rules are based on the relationship between different business types and business application scenarios. For example, if the business type is identified as financial transaction, and the transaction frequency is high with strict real-time requirements, then the corresponding business application scenario category may be high real-time financial transaction scenario. If the business type is identified as IoT device data collection, and the number of devices is large with high data concurrency, then the corresponding business application scenario category may be high concurrency IoT data collection scenario. The identified business type identifier is input into the scenario classification rule engine. The rule engine judges and infers according to the pre-set rules, and finally determines the business application scenario category to which the blockchain node belongs.

[0050] Specifically, various business application scenario categories and their corresponding preset scenario weight coefficients are pre-stored in a database or configuration file in a mapping relationship. For example, key-value pairs can be used, with the business application scenario category as the key and the scenario weight coefficient as the value. Once the business application scenario category of the blockchain node is determined, the corresponding scenario weight coefficient value is retrieved based on the business application scenario category key through a database query or configuration file read operation.

[0051] Specifically, when the business application scenario category to which the blockchain node belongs is determined to be a high real-time network scenario, the weight coefficient of the first scenario (corresponding to the processing latency metric) is configured to be greater than the weight coefficient of the second scenario (corresponding to the concurrent request metric) and the weight coefficient of the third scenario (corresponding to the network topology distance metric). This can be achieved by setting conditional statements in the code, which assign values ​​to the corresponding weight coefficients when the condition of the business application scenario category being a high real-time network scenario is met.

[0052] Similar to the handling of high real-time network scenarios, when the business application scenario to which the blockchain node belongs is determined to be a high-concurrency network scenario, the weight coefficient of the second scenario (corresponding to the concurrent request metric) is adjusted to be greater than the weight coefficient of the first scenario (corresponding to the processing latency metric) and the weight coefficient of the third scenario (corresponding to the network topology distance metric). When the business application scenario to which the blockchain node belongs is determined to be a high-stability network scenario, the weight coefficient of the third scenario (corresponding to the network topology distance metric) is optimized to be greater than the weight coefficient of the first scenario (corresponding to the processing latency metric) and the weight coefficient of the second scenario (corresponding to the concurrent request metric). This ensures that the impact of network topology distance on node performance is fully considered during subsequent routing distribution, thereby improving the applicability of the node in various network scenarios.

[0053] In this embodiment of the invention, the weight coefficients of each metric are dynamically determined according to the specific business application scenario (such as high-frequency trading, data storage, or the Internet of Things), realizing scenario adaptation and strategy flexibility in node selection. Thus, in a complex and ever-changing business environment, the blockchain node that best meets the current scenario's optimal goal can always be selected, significantly improving business execution efficiency and service quality.

[0054] S4. Calculate the routing distribution cost feature value of the corresponding blockchain node based on the processing latency metric, concurrent request metric, network topology distance metric, and the corresponding scenario weight coefficient of each blockchain node.

[0055] In this embodiment of the invention, the routing distribution cost feature value refers to a quantitative feature value obtained through a specific calculation method to evaluate the cost of a blockchain node in the routing distribution process. The magnitude of the routing distribution cost feature value can serve as an important basis for route selection, helping the blockchain network to allocate routing tasks more rationally, optimize network resource utilization, and improve overall operating efficiency.

[0056] In this embodiment of the invention, calculating the routing distribution cost feature value corresponding to the blockchain node based on the processing latency metric, concurrent request metric, network topology distance metric, and corresponding scenario weight coefficient of each blockchain node includes: The processing latency metric, concurrent request metric, and network topology distance metric of each blockchain node are weighted and summed with the corresponding scenario weight coefficients to obtain the initial routing distribution cost feature value of the corresponding blockchain node. The initial routing distribution cost feature value is normalized to obtain the routing distribution cost feature value corresponding to the blockchain node.

[0057] Specifically, the routing distribution cost feature value is shown in the following formula: in, This represents the characteristic value of the routing distribution cost. This represents the processing latency metric. This represents the concurrent request metric. This represents the network topology distance metric. This represents the weight coefficient of the first scenario. This represents the weighting coefficient for the second scenario. This represents the weighting coefficient of the third scenario.

[0058] In this embodiment of the invention, weighted summation is a common calculation method. Its core idea is to assign corresponding weights based on the importance of different factors, then multiply the values ​​of each factor by their corresponding weights and sum them to obtain a comprehensive result. In this invention, processing latency metrics, concurrent request metrics, and network topology distance metrics respectively reflect the performance of blockchain nodes in different aspects, while the scenario weight coefficient reflects the importance of these performance indicators in the current business scenario.

[0059] By multiplying each metric by its corresponding scenario weight coefficient, each performance indicator is weighted, highlighting the contribution of different indicators in specific scenarios. The weighted results are then summed to obtain the initial route distribution cost feature value. This value integrates the node's performance in terms of processing latency, concurrent requests, and network topology distance, and takes into account the business scenario's preference for different indicators.

[0060] Furthermore, since the initial route distribution cost feature value is obtained by weighted summation of different metrics, these metrics may vary significantly in terms of units and ranges. For example, the unit for processing latency might be milliseconds, the unit for concurrent request metrics might be the number of requests processed per second, and the unit for network topology distance metrics might be hop count or geographical distance. This difference leads to a large numerical range for the initial route distribution cost feature value, which is detrimental to subsequent comparisons and analyses.

[0061] Data normalization techniques can transform data with different dimensions and value ranges into a unified range, typically between [0, 1]. Through normalization, the dimensional differences between different metrics are eliminated, making the initial route distribution cost feature values ​​comparable. For example, for a large initial route distribution cost feature value, normalization will map it to a relatively small range, while smaller initial values ​​will be adjusted accordingly, thus ensuring that the route distribution cost feature values ​​of different nodes can be compared on the same scale.

[0062] In this embodiment of the invention, by calculating the routing distribution cost feature value of each node, a clear and unified sorting basis is provided for routing distribution decisions. This enables the automatic and efficient identification and priority selection of high-quality nodes with the lowest overall cost, achieving dynamic and optimal task distribution, and ultimately improving the overall throughput efficiency of the blockchain network.

[0063] S5. Make routing distribution decisions for the blockchain nodes based on the routing distribution cost feature values ​​corresponding to different blockchain nodes.

[0064] In this embodiment of the invention, the routing and distribution decision refers to the automated decision-making process by which a control unit (such as a scheduler or smart contract) in the blockchain network selects one or more target blockchain nodes from among numerous blockchain nodes for an upcoming business request to be distributed and executes task distribution.

[0065] In this embodiment of the invention, the step of making routing distribution decisions for the blockchain nodes based on the routing distribution cost feature values ​​corresponding to different blockchain nodes includes: The blockchain nodes are sorted in ascending order based on the routing distribution cost feature value corresponding to different blockchain nodes to generate an ordered node list. Starting from the head of the ordered node list, select several nodes to form an initial candidate node set; If the number of initial candidate nodes in the initial candidate node set is greater than one, then the load rate of each initial candidate node in the initial candidate node set is calculated. Based on the routing distribution cost feature value and the load rate of each initial candidate node, a corresponding node selection weight is assigned to each initial candidate node; Based on the node selection weights, a target blockchain node set for processing preset business requests to be distributed is determined from the initial candidate node set. The business requests to be distributed are distributed to the target blockchain node set according to the preset routing and distribution strategy.

[0066] In this embodiment of the invention, all blockchain nodes are sorted in ascending order according to their routing cost feature values. During the sorting process, the routing cost feature values ​​of each node are compared, and their positions in the ordered list are determined based on the comparison results. For example, for two nodes, the algorithm compares their routing cost feature values, placing the node with the smaller feature value first and the node with the larger feature value later, thus providing a basis for subsequent routing decisions.

[0067] Starting from the head of the ordered list of nodes, nodes are selected according to certain rules (such as selecting the first N nodes, where N is a positive integer), and these nodes are combined to form an initial candidate node set. For example, if the goal is to select the first 5 nodes, then starting from the first node of the list, the 1st, 2nd, 3rd, 4th, and 5th nodes are selected in sequence and placed into the initial candidate node set.

[0068] Specifically, for each node in the initial candidate node set, its current load-related data is obtained through load monitoring technology, and the load rate of that node is calculated based on this data. For example, by monitoring the CPU utilization of a node, if the CPU utilization is too high, it indicates that the node is processing a large number of tasks and has a heavy load, and the CPU utilization is used as the current load rate of the node.

[0069] In detail, a node selection weight is assigned to each initial candidate node. Based on business needs and actual conditions, the importance of the routing distribution cost feature value and load rate in the node selection process is determined, and corresponding weights are assigned to them. For each initial candidate node, its routing distribution cost feature value and load rate are multiplied by the corresponding weights to obtain a weighted value. The two weighted values ​​are added together to obtain the node selection weight of that node.

[0070] Furthermore, based on the node selection weights, a target blockchain node set is selected from the initial candidate node set to handle the business requests to be distributed. For example, a weight threshold can be set, and nodes with selection weights greater than the threshold can be selected into the target blockchain node set; or, the top M nodes (M is a positive integer) can be selected as the target blockchain node set according to their selection weights from high to low. This allows for the selection of the most suitable nodes from the initial candidate node set to handle the current business requests to be distributed, improving the efficiency and quality of business request processing.

[0071] Furthermore, business requests can be rationally distributed to various nodes in the target blockchain node set. For example, a round-robin approach can be used to distribute business requests sequentially to each node in the target blockchain node set. By executing a preset routing and distribution strategy, it can be ensured that business requests are processed efficiently and rationally, thereby improving the performance and stability of the entire blockchain network.

[0072] In this embodiment of the invention, distributing the service request to be distributed to the target blockchain node set according to a preset routing distribution strategy includes: If the routing distribution strategy is the lowest-cost single-node distribution strategy, then the business request to be distributed will be routed to the blockchain node with the smallest routing distribution cost feature value in the target blockchain node set; If the routing distribution strategy is a multi-node parallel distribution strategy, then from the target blockchain node set, select the top few blockchain nodes with the smallest routing distribution cost feature value to form a parallel distribution node group; The business request to be distributed is divided into several sub-tasks, and the several sub-tasks are respectively routed to several corresponding blockchain nodes in the parallel distribution node group.

[0073] In this embodiment of the invention, if the routing distribution strategy is the lowest cost single-node distribution strategy, then the nodes in the target blockchain node set are traversed, their routing distribution cost feature values ​​are compared, the node with the smallest routing distribution cost feature value is found, and the business request to be distributed is routed to this blockchain node with the smallest routing distribution cost feature value, ensuring that the business request is distributed to the node with the best performance in terms of the current routing distribution cost for processing.

[0074] If the routing distribution strategy is a multi-node parallel distribution strategy, the nodes are arranged in ascending order of the routing distribution cost feature value. From the sorted target blockchain node set, the top few blockchain nodes with the smallest routing distribution cost feature value are selected and they are grouped into a parallel distribution node group. The business request is then split into several sub-tasks. For example, if the business request is a data processing task, it can be split according to different parts of the data.

[0075] In a parallel task distribution node group, each node has a certain processing capacity and resources. Subtasks are rationally allocated to each node based on factors such as node performance and load. For example, computationally intensive subtasks can be assigned to nodes with higher performance, while less computationally intensive subtasks can be assigned to nodes with relatively lower performance; alternatively, subtasks can be assigned to nodes with lighter loads based on their current load status, thus achieving load balancing. Through task allocation technology, it is ensured that each subtask is processed efficiently, improving the overall processing speed and quality of business requests.

[0076] In this embodiment of the invention, based on the routing distribution cost feature value, automated and intelligent node selection and routing distribution decision-making are realized, which greatly improves the accuracy of routing distribution of blockchain nodes, and also improves the task distribution efficiency and resource utilization rationality of blockchain nodes.

[0077] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0078] like Figure 4 The diagram shown is a functional block diagram of a blockchain node routing and distribution device provided in an embodiment of the present invention.

[0079] This disclosure provides a blockchain node routing and distribution device, which corresponds one-to-one with the blockchain node routing and distribution method described in the above embodiments. For example... Figure 4As shown, this blockchain node routing and distribution device 100 can be installed in an electronic device. According to its functions, the blockchain node routing and distribution device 100 includes a projected load data calculation module 101, a load performance quantification and analysis module 102, a scenario weight coefficient determination module 103, a routing cost feature value calculation module 104, and a node routing and distribution decision module. Detailed descriptions of each functional module are as follows: The expected load data calculation module 101 is used to obtain historical load data of multiple blockchain nodes, and calculate the expected processing delay, expected concurrent request volume, and network topology distance between each blockchain node and the preset server within a preset time period based on the historical load data. The load performance quantification analysis module 102 is used to perform performance quantification analysis based on the expected processing latency, expected concurrent request volume and network topology distance corresponding to each blockchain node, and obtain the processing latency metric, concurrent request metric and network topology distance metric for each blockchain node. The scenario weight coefficient determination module 103 is used to determine the scenario weight coefficients corresponding to the processing delay metric, the concurrent request metric, and the network topology distance metric based on the business application scenario of the blockchain node. The routing cost feature value calculation module 104 is used to calculate the routing distribution cost feature value of the corresponding blockchain node based on the processing delay metric value, the concurrent request metric value, the network topology distance metric value, and the corresponding scenario weight coefficient of each blockchain node. The node routing and distribution decision module 105 is used to make routing and distribution decisions for the blockchain nodes based on the routing and distribution cost feature values ​​corresponding to different blockchain nodes.

[0080] In one embodiment, when the expected load data calculation module 101 calculates the expected processing latency, expected concurrent request volume, and network topology distance between each blockchain node and a preset server within a preset time period based on the historical load data, it is used to: Extract the historical request records of each blockchain node within a preset time period from the historical load data, and clean and format the historical request records to obtain a standard time-series dataset. Based on the standard time-series dataset, calculate the total request processing time and the corresponding number of request records for each blockchain node in each time window within a preset time period. Divide the total request processing time of each time window by the corresponding number of request records to obtain the average request processing time of the blockchain node in the time window; Calculate the average of the average request processing time for all the time windows, and use the average as the expected processing delay of the blockchain node; Based on the standard time-series dataset, the peak concurrent requests of each blockchain node within a historical interval that has the same time-series characteristics as a preset time period are statistically analyzed. The expected number of concurrent requests for the blockchain node in the next corresponding time period is calculated using a preset time series prediction model and the peak concurrent request. Each of the blockchain nodes sends network probe packets to a preset server, and the number of intermediate routers through which the network probe packets travel from the blockchain nodes to the server is counted. The number of routers is used as the routing hop count between the blockchain node and the server, and the routing hop count is used as the network topology distance between the blockchain node and the server.

[0081] In one embodiment, when the load performance quantification analysis module 102 performs performance quantification analysis based on the expected processing latency, expected concurrent request volume, and network topology distance corresponding to each blockchain node, and obtains the processing latency metric, concurrent request metric, and network topology distance metric for each blockchain node, it is used to: Obtain the first performance weight coefficient corresponding to the expected processing delay, the second performance weight coefficient corresponding to the expected concurrent request volume, and the third performance weight coefficient corresponding to the network topology distance; Calculate the relative latency ratio between the expected processing latency and the preset latency benchmark value, and multiply the relative latency ratio by the first performance weight coefficient to obtain the processing latency metric value of the blockchain node; Multiply the expected number of concurrent requests by the second performance weight coefficient to obtain the concurrent request metric of the blockchain node; The network topology distance is exponentially calculated with the preset maximum allowed distance threshold to obtain the distance standardization coefficient. The distance standardization coefficient is then multiplied by the third performance weight coefficient to obtain the network topology distance metric of the blockchain node.

[0082] In one embodiment, when the scenario weight coefficient determination module 103 determines the scenario weight coefficients corresponding to the processing latency metric, the concurrent request metric, and the network topology distance metric based on the business application scenario of the blockchain node, it is used to: Identify the business type identifier of the target business carried by the blockchain node; The business application scenario category to which the blockchain node belongs is determined based on the business type identifier; Obtain the mapping relationship between the business application scenario category and the preset scenario weight coefficient, and determine the scenario weight coefficient corresponding to the business application scenario category based on the mapping relationship; If the business application scenario category is a high real-time network scenario, then the weight coefficient of the first scenario is configured to be greater than the weight coefficients of the second and third scenarios. If the business application scenario category is a high-concurrency network scenario, then the weight coefficient of the second scenario is configured to be greater than the weight coefficient of the first scenario and the weight coefficient of the third scenario. If the business application scenario category is a high-stability network scenario, then the weight coefficient of the third scenario is configured to be greater than the weight coefficient of the first scenario and the weight coefficient of the second scenario.

[0083] In one embodiment, when the routing cost feature value calculation module 104 calculates the routing distribution cost feature value corresponding to the blockchain node based on the processing latency metric, the concurrent request metric, the network topology distance metric, and the corresponding scenario weight coefficient for each blockchain node, it is used to: The processing latency metric, concurrent request metric, and network topology distance metric of each blockchain node are weighted and summed with the corresponding scenario weight coefficients to obtain the initial routing distribution cost feature value of the corresponding blockchain node. The initial routing distribution cost feature value is normalized to obtain the routing distribution cost feature value corresponding to the blockchain node.

[0084] In one embodiment, when the node routing distribution decision module 105 performs routing distribution decisions for the blockchain nodes based on the routing distribution cost feature values ​​corresponding to different blockchain nodes, it is used to: The blockchain nodes are sorted in ascending order based on the routing distribution cost feature value corresponding to different blockchain nodes to generate an ordered node list. Starting from the head of the ordered node list, select several nodes to form an initial candidate node set; If the number of initial candidate nodes in the initial candidate node set is greater than one, then the load rate of each initial candidate node in the initial candidate node set is calculated. Based on the routing distribution cost feature value and the load rate of each initial candidate node, a corresponding node selection weight is assigned to each initial candidate node; Based on the node selection weights, a target blockchain node set for processing preset business requests to be distributed is determined from the initial candidate node set. The business requests to be distributed are distributed to the target blockchain node set according to the preset routing and distribution strategy.

[0085] In one embodiment, when the node routing and distribution decision module 105 distributes the service request to be distributed to the target blockchain node set according to a preset routing and distribution strategy, it is used to: If the routing distribution strategy is the lowest-cost single-node distribution strategy, then the business request to be distributed will be routed to the blockchain node with the smallest routing distribution cost feature value in the target blockchain node set; If the routing distribution strategy is a multi-node parallel distribution strategy, then from the target blockchain node set, select the top few blockchain nodes with the smallest routing distribution cost feature value to form a parallel distribution node group; The business request to be distributed is divided into several sub-tasks, and the several sub-tasks are respectively routed to several corresponding blockchain nodes in the parallel distribution node group.

[0086] In this invention, the specific limitations of a blockchain node routing and distribution device can be found in the above-described limitations of a blockchain node routing and distribution method, and will not be repeated here. Each module in the aforementioned blockchain node routing and distribution device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0087] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of a blockchain node routing and distribution method on the server side.

[0088] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 6As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements the client-side functions or steps of a blockchain node routing and distribution method.

[0089] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain historical load data of multiple blockchain nodes, and calculate the expected processing latency, expected concurrent request volume, and network topology distance between each blockchain node and a preset server within a preset time period based on the historical load data. Performance quantification analysis is performed based on the expected processing latency, expected concurrent request volume, and network topology distance corresponding to each blockchain node to obtain the processing latency metric, concurrent request metric, and network topology distance metric for each blockchain node. Determine the scenario weight coefficients corresponding to the processing latency metric, the concurrent request metric, and the network topology distance metric based on the business application scenario of the blockchain node; Based on the processing latency metric, concurrent request metric, and network topology distance metric of each blockchain node, as well as the corresponding scenario weight coefficient, calculate the routing distribution cost feature value of the corresponding blockchain node; The routing distribution decision is made for the blockchain nodes based on the routing distribution cost feature value corresponding to different blockchain nodes.

[0090] In the several embodiments provided by this invention, it should be understood that the disclosed devices and apparatuses can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0091] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0092] Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within the invention. No appended diagram markings in the claims should be construed as limiting the scope of the claims.

[0093] In some embodiments of this example, a computer-readable storage medium is provided, on which a computer program is stored, characterized in that the computer program, when executed by a processor, implements the steps of the method described in the above embodiments.

[0094] The readable storage medium of the present invention stores a computer program, which, when executed by a processor of an electronic device, can perform the following: Obtain historical load data of multiple blockchain nodes, and calculate the expected processing latency, expected concurrent request volume, and network topology distance between each blockchain node and a preset server within a preset time period based on the historical load data. Performance quantification analysis is performed based on the expected processing latency, expected concurrent request volume, and network topology distance corresponding to each blockchain node to obtain the processing latency metric, concurrent request metric, and network topology distance metric for each blockchain node. Determine the scenario weight coefficients corresponding to the processing latency metric, the concurrent request metric, and the network topology distance metric based on the business application scenario of the blockchain node; Based on the processing latency metric, concurrent request metric, and network topology distance metric of each blockchain node, as well as the corresponding scenario weight coefficient, calculate the routing distribution cost feature value of the corresponding blockchain node; The routing distribution decision is made for the blockchain nodes based on the routing distribution cost feature value corresponding to different blockchain nodes.

[0095] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0096] Computer-readable storage media may also store at least one computer-executable program / instruction, such as computer-readable instructions. Computer-readable storage media include, but are not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Computer-readable storage media may include, for example, read-only memory (ROM), hard disk, flash memory, etc. For example, a non-transitory computer-readable storage medium may be connected to a computing device such as a computer, and then, when the computing device executes the computer-readable instructions stored on the computer-readable storage medium, the various methods described above can be performed.

[0097] In addition, the computer device may include (but is not limited to) a data bus, an input / output (I / O) bus, a display, and input / output devices (e.g., keyboard, mouse, speakers, etc.).

[0098] In one embodiment, the at least one computer-executable instruction may also be compiled into or comprise a software product / computer program product, wherein one or more computer-executable instructions are executed by a processor to perform the steps of the various functions and / or methods in the embodiments described herein.

[0099] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Furthermore, any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory.

[0100] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0101] In the embodiments provided in this disclosure, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0102] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

[0103] It should be noted that if any software tools or components not belonging to our company appear in the embodiments of this application, they are merely for illustrative purposes and do not represent actual use.

Claims

1. A blockchain node routing and distribution method, characterized in that, The method includes: Obtain historical load data of multiple blockchain nodes, and calculate the expected processing latency, expected concurrent request volume, and network topology distance between each blockchain node and a preset server within a preset time period based on the historical load data. Performance quantification analysis is performed based on the expected processing latency, expected concurrent request volume, and network topology distance corresponding to each blockchain node to obtain the processing latency metric, concurrent request metric, and network topology distance metric for each blockchain node. Determine the scenario weight coefficients corresponding to the processing latency metric, the concurrent request metric, and the network topology distance metric based on the business application scenario of the blockchain node; Based on the processing latency metric, concurrent request metric, and network topology distance metric of each blockchain node, as well as the corresponding scenario weight coefficient, calculate the routing distribution cost feature value of the corresponding blockchain node; The routing distribution decision is made for the blockchain nodes based on the routing distribution cost feature value corresponding to different blockchain nodes.

2. The blockchain node routing and distribution method as described in claim 1, characterized in that, The calculation of the expected processing latency, expected concurrent request volume, and network topology distance between each blockchain node and the preset server within a preset time period based on the historical load data includes: Extract the historical request records of each blockchain node within a preset time period from the historical load data, and clean and format the historical request records to obtain a standard time-series dataset. Based on the standard time-series dataset, calculate the total request processing time and the corresponding number of request records for each blockchain node in each time window within a preset time period. Divide the total request processing time of each time window by the corresponding number of request records to obtain the average request processing time of the blockchain node in the time window; Calculate the average of the average request processing time for all the time windows, and use the average as the expected processing delay of the blockchain node; Based on the standard time-series dataset, the peak concurrent requests of each blockchain node within a historical interval that has the same time-series characteristics as a preset time period are statistically analyzed. The expected number of concurrent requests for the blockchain node in the next corresponding time period is calculated using a preset time series prediction model and the peak concurrent request. Each of the blockchain nodes sends network probe packets to a preset server, and the number of intermediate routers through which the network probe packets travel from the blockchain nodes to the server is counted. The number of routers is used as the routing hop count between the blockchain node and the server, and the routing hop count is used as the network topology distance between the blockchain node and the server.

3. The blockchain node routing and distribution method as described in claim 1, characterized in that, The performance quantification analysis based on the expected processing latency, expected concurrent request volume, and network topology distance for each blockchain node yields processing latency metrics, concurrent request metrics, and network topology distance metrics for each blockchain node, including: Obtain the first performance weight coefficient corresponding to the expected processing delay, the second performance weight coefficient corresponding to the expected concurrent request volume, and the third performance weight coefficient corresponding to the network topology distance; Calculate the relative latency ratio between the expected processing latency and the preset latency benchmark value, and multiply the relative latency ratio by the first performance weight coefficient to obtain the processing latency metric value of the blockchain node; Multiply the expected number of concurrent requests by the second performance weight coefficient to obtain the concurrent request metric of the blockchain node; The network topology distance is exponentially calculated with the preset maximum allowed distance threshold to obtain the distance standardization coefficient. The distance standardization coefficient is then multiplied by the third performance weight coefficient to obtain the network topology distance metric of the blockchain node.

4. The blockchain node routing and distribution method as described in claim 1, characterized in that, The step of determining the scenario weight coefficients corresponding to the processing latency metric, the concurrent request metric, and the network topology distance metric based on the business application scenario of the blockchain node includes: Identify the business type identifier of the target business carried by the blockchain node; The business application scenario category to which the blockchain node belongs is determined based on the business type identifier; Obtain the mapping relationship between the business application scenario category and the preset scenario weight coefficient, and determine the scenario weight coefficient corresponding to the business application scenario category based on the mapping relationship; If the business application scenario category is a high real-time network scenario, then the weight coefficient of the first scenario is configured to be greater than the weight coefficients of the second and third scenarios. If the business application scenario category is a high-concurrency network scenario, then the weight coefficient of the second scenario is configured to be greater than the weight coefficient of the first scenario and the weight coefficient of the third scenario. If the business application scenario category is a high-stability network scenario, then the weight coefficient of the third scenario is configured to be greater than the weight coefficient of the first scenario and the weight coefficient of the second scenario.

5. The blockchain node routing and distribution method as described in claim 1, characterized in that, The step of calculating the routing distribution cost feature value for each blockchain node based on the processing latency metric, concurrent request metric, network topology distance metric, and corresponding scenario weight coefficient includes: The processing latency metric, concurrent request metric, and network topology distance metric of each blockchain node are weighted and summed with the corresponding scenario weight coefficients to obtain the initial routing distribution cost feature value of the corresponding blockchain node. The initial routing distribution cost feature value is normalized to obtain the routing distribution cost feature value corresponding to the blockchain node.

6. The blockchain node routing and distribution method as described in claim 1, characterized in that, The step of making routing distribution decisions for the blockchain nodes based on the routing distribution cost feature values ​​corresponding to different blockchain nodes includes: The blockchain nodes are sorted in ascending order based on the routing distribution cost feature value corresponding to different blockchain nodes to generate an ordered node list. Starting from the head of the ordered node list, select several nodes to form an initial candidate node set; If the number of initial candidate nodes in the initial candidate node set is greater than one, then the load rate of each initial candidate node in the initial candidate node set is calculated. Based on the routing distribution cost feature value and the load rate of each initial candidate node, a corresponding node selection weight is assigned to each initial candidate node; Based on the node selection weights, a target blockchain node set for processing preset business requests to be distributed is determined from the initial candidate node set. The business requests to be distributed are distributed to the target blockchain node set according to the preset routing and distribution strategy.

7. The blockchain node routing and distribution method as described in claim 6, characterized in that, The step of distributing the service request to be distributed to the target blockchain node set according to a preset routing distribution strategy includes: If the routing distribution strategy is the lowest-cost single-node distribution strategy, then the business request to be distributed will be routed to the blockchain node with the smallest routing distribution cost feature value in the target blockchain node set; If the routing distribution strategy is a multi-node parallel distribution strategy, then from the target blockchain node set, select the top few blockchain nodes with the smallest routing distribution cost feature value to form a parallel distribution node group; The business request to be distributed is divided into several sub-tasks, and the several sub-tasks are respectively routed to several corresponding blockchain nodes in the parallel distribution node group.

8. A blockchain node routing and distribution device, characterized in that, The device includes: The expected load data calculation module is used to obtain historical load data of multiple blockchain nodes, and calculate the expected processing delay, expected concurrent request volume, and network topology distance between each blockchain node and the preset server within a preset time period based on the historical load data. The load performance quantification analysis module is used to perform performance quantification analysis based on the expected processing latency, expected concurrent request volume and network topology distance of each blockchain node, and to obtain the processing latency metric, concurrent request metric and network topology distance metric for each blockchain node. The scenario weight coefficient determination module is used to determine the scenario weight coefficients corresponding to the processing delay metric, the concurrent request metric, and the network topology distance metric based on the business application scenario of the blockchain node. The routing cost feature value calculation module is used to calculate the routing distribution cost feature value of the corresponding blockchain node based on the processing latency metric, concurrent request metric, network topology distance metric and the corresponding scenario weight coefficient of each blockchain node. The node routing and distribution decision module is used to make routing and distribution decisions for the blockchain nodes based on the routing and distribution cost feature values ​​corresponding to different blockchain nodes.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the blockchain node routing and distribution method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the blockchain node routing and distribution method as described in any one of claims 1 to 7.

Images