Self-adaptive routing method and device for CMDB cluster load

Abstract

The invention provides a self-adaptive routing method and device for a CMDB cluster load. The method comprises the following steps: receiving real-time performance data sent by a plurality of slave node hosts according to a preset period; calculating a weight value of each slave node host based on the real-time performance data; updating a cluster routing rule based on the weight value; and when the client sends a service data stream to the master node host, mapping the service data stream to each slave node host for storage according to the cluster routing rule. According to the method provided by the invention, the slave node hosts can be distinguished based on the weight values, and the storage strategy can be determined according to the resource use conditions of the hosts with different performances. Moreover, the slave node hosts have different weight values, so that when a certain slave node host fails, the storage strategy of the to-be-stored data can be determined based on the weight value, and the problem that a single slave node is overloaded due to excessive received data is avoided.

Description

Technical Field

[0001] The present application relates to the field of big data distributed storage technology, and in particular to an adaptive routing method and device for CMDB cluster load. Background Art

[0002] In the context of big data, the data scale has leapt from the gigabyte (GB) level to the petabyte (PB) level, which places extremely high demands on data storage and processing capabilities. Due to the limitation of hardware resources, a single-machine system is obviously unable to effectively handle such a huge amount of data. Therefore, large-scale clusters have become an inevitable choice for processing big data.

[0003] Large-scale cluster systems are usually composed of multiple computer nodes that work together to complete data storage and computing tasks, thereby efficiently processing and analyzing massive amounts of data and significantly improving data processing capabilities and storage capacity.

[0004] Generally, each computer node in the cluster performs storage tasks in sequence. When a computer node fails, the data that has not been successfully stored due to the failure will be postponed to the next computer node for storage. In this process, since the different performances of different computer nodes and their different data processing capabilities are not taken into account, it is easy to cause high-performance computer nodes to be idle and low-performance computer nodes to be overloaded, thus causing the problem of uneven resource utilization. Summary of the invention

[0005] The embodiments of the present application provide an adaptive routing method and device for CMDB cluster load to solve the problem that traditional routing methods easily cause unbalanced resource utilization.

[0006] In a first aspect, an embodiment of the present application provides an adaptive routing method for a CMDB cluster load, wherein the cluster includes a master node host and multiple slave node hosts. The method is applied to the master node host, and the method includes: receiving real-time performance data sent by multiple slave node hosts at a preset period; calculating a weight value of each slave node host based on the real-time performance data; updating cluster routing rules based on the weight value; when a client sends a business data stream to the master node host, mapping the business data stream to each slave node host for storage according to the cluster routing rules.

[0007] In one feasible manner, a business data stream includes multiple business data; when a client sends a business data stream to a master node host, according to cluster routing rules, the steps of mapping the business data stream to each slave node host for storage include: performing hash processing on each business data separately to obtain a hash process value for each business data; based on the cluster routing rules, determining multiple shard intervals formed by the current hash space division; wherein the size of the current hash space is a default value, different shard intervals have different hash space ranges, each shard interval includes multiple data shards, and different data shards correspond to different hash values ​​in the hash space range; for each business data, allocate it to each data shard according to its corresponding hash process value.

[0008] In one achievable method, after the step of allocating each piece of business data to each data shard according to its corresponding hash process value, it also includes: determining the various slave node hosts included in the shard interval based on the cluster routing rules; for each shard interval, mapping the data shards included therein to the various slave node hosts according to the size of the weight values ​​of the corresponding slave node hosts, so that the slave node hosts store the business data in the data shards.

[0009] In one achievable manner, the method further includes: for a target sharding interval, when one or more slave node hosts included therein fail, determining the unstored data shards corresponding to the failed slave node hosts; remapping the unstored data shards to each first slave node host according to the weight value of the first slave node host, so that the first slave node host stores the business data in the unstored data shards; wherein the first slave node host is a slave node host that has not failed and is included in the target sharding interval.

[0010] In one implementable manner, the cluster routing rules are changeable, and the first change in the cluster routing rules refers to an increase in the number of shard intervals in the current hash space; the method also includes: in response to the first change in the cluster routing rules, determining whether the newly added shard interval includes the newly added slave node host and / or the original slave node host; if the newly added shard interval includes the newly added slave node host, determining the updated hash space range of the original shard interval based on the cluster routing rules; for each original shard interval, determining the range difference between the corresponding original hash space range and the updated hash space range; determining the data shard to be migrated corresponding to the range difference, and determining the migration address of the data shard to be migrated, wherein the migration address is determined by the hash value corresponding to the data shard to be migrated, and the migration address is other original shard intervals or newly added shard intervals; based on the migration address, migrating the first business data to the original slave node host or the newly added slave node host, the first business data being the business data corresponding to the data shard to be migrated.

[0011] In one achievable manner, in response to a first change in the cluster routing rules, after the step of determining whether the newly added shard interval includes the newly added slave node host and / or the original slave node host, the method also includes: if the newly added shard interval includes the original slave node host, determining the original slave node host corresponding to the newly added shard interval as the host to be migrated; determining the target original shard interval to which the host to be migrated belongs before the first change in the cluster routing rules; migrating the second business data to each second slave node host according to the weight value of the second slave node host; wherein the second slave node host is the other slave node host included in the target original shard interval except the host to be migrated; when the newly added shard interval only includes the original slave node host, the second business data is all business data stored in the host to be migrated, and when the newly added shard interval includes the newly added slave node host and the original slave node host, the second business data is the part of the business data stored in the host to be migrated except the first business data.

[0012] In one feasible method, the real-time performance data is the real-time data of various performance indicators, the performance indicators include resource performance indicators and / or business performance indicators, the resource performance indicators include CPU occupancy, memory occupancy and / or storage occupancy, the business performance indicators include the response time of each storage of the slave node host within a preset period, and the number of storage anomalies that occur in the slave node host within the preset period; the step of calculating the weight value of each slave node host based on the real-time performance data includes: for each slave node host, according to the preset weight rule, calculating the weight score corresponding to the real-time data of each performance indicator; multiplying each weight score with its corresponding weight coefficient to obtain the sub-weight value corresponding to the real-time data of each performance indicator; wherein the weight coefficients of different performance indicators are the same or different; summing the sub-weight values ​​to obtain the weight value of the slave node host.

[0013] In the second aspect, an embodiment of the present application also provides an adaptive routing method for CMDB cluster load, the cluster includes a master node host and multiple slave node hosts, the method is applied to any slave node host, the method includes: collecting real-time performance data according to a preset period; sending the real-time performance data to the master node host; and the method also includes: when the client sends a business data stream to the master node host, storing the corresponding business data stream in response to the mapping of the master node host.

[0014] In a third aspect, an embodiment of the present application also provides an adaptive routing device for CMDB cluster load, wherein the cluster includes a master node host and multiple slave node hosts, and the device is applied to the master node host, and the device includes: a receiving module for receiving real-time performance data sent by multiple slave node hosts according to a preset period; a calculation module for calculating the weight value of each slave node host based on the real-time performance data; an update module for updating the cluster routing rules based on the weight value; and a mapping module for mapping the business data stream to each slave node host for storage according to the cluster routing rules when the client sends a business data stream to the master node host.

[0015] In a fourth aspect, an embodiment of the present application further provides an adaptive routing device for a CMDB cluster load, wherein the cluster includes a master node host and multiple slave node hosts, and the device is applied to any slave node host, and the device includes: a collection module for collecting real-time performance data according to a preset period; a sending module for sending the real-time performance data to the master node host; and,

[0016] The device also includes: a storage module, which is used to store the corresponding business data stream in response to the mapping of the main node host when the client sends the business data stream to the main node host.

[0017] From the above content, it can be seen that the present application provides an adaptive routing method and device for CMDB cluster load, the method comprising: receiving real-time performance data sent by multiple slave node hosts according to a preset period; calculating the weight value of each slave node host based on the real-time performance data; updating the cluster routing rules based on the weight value; when the client sends a business data stream to the master node host, according to the cluster routing rules, the business data stream is mapped to each slave node host for storage. The method provided in the present application can distinguish each slave node host based on the weight value, and supports determining the storage strategy based on the resource usage of hosts with different performance. In addition, since each slave node host has a different weight value, when a slave node host fails, the storage strategy for the data to be stored can also be determined based on the weight value, avoiding the problem of a single slave node being overloaded due to receiving too much data. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A schematic diagram of the structure of a cluster provided in an embodiment of the present application;

[0019] Figure 2 A flowchart of a first adaptive routing method for CMDB cluster load provided in an embodiment of the present application;

[0020] Figure 3 A schematic diagram of a data processing flow provided for an embodiment of the present application;

[0021] Figure 4A schematic diagram of a process for calculating the weight value of a slave node host provided in an embodiment of the present application;

[0022] Figure 5 A schematic diagram of a process for storing business data in a slave node host provided in an embodiment of the present application;

[0023] Figure 6 A schematic diagram of the data sharding remapping process provided in an embodiment of the present application;

[0024] Figure 7 A schematic diagram of a first process of data migration provided in an embodiment of the present application;

[0025] Figure 8 A second flow chart of data migration provided in an embodiment of the present application;

[0026] Fig. 9 A flow chart of a second adaptive routing method for CMDB cluster load provided in an embodiment of the present application;

[0027] Fig.10 A schematic diagram of the structure of a first adaptive routing device for CMDB cluster load provided in an embodiment of the present application;

[0028] Fig.11 A schematic diagram of the structure of a second adaptive routing device for CMDB cluster load provided in an embodiment of the present application. DETAILED DESCRIPTION

[0029] In order to enable those skilled in the art to better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work should fall within the scope of protection of the present application.

[0030] Before introducing the technical solutions of the embodiments of the present application, the terms involved in the embodiments of the present application are first introduced by way of example.

[0031] 1. Configuration Management Database (CMDB): It is a database used to store and manage IT assets and their configurations, including information on various hardware, software, network equipment and other resources.

[0032] CMDB provides a centralized database to manage and record the configuration information of each component in the cluster. For a big data cluster, there may be thousands of nodes, virtual machines, containers, etc., and CMDB can help administrators clearly understand the detailed configuration of these resources and ensure the stability and manageability of the cluster.

[0033] 2. CMDB operation and maintenance management platform: It is a tool dedicated to helping enterprises effectively manage and maintain IT infrastructure information. It provides unified, visual and comprehensive configuration management information to IT personnel, helping them better manage and maintain the entire IT infrastructure, improve work efficiency, reduce risks, and provide support for the enterprise's IT operations and management.

[0034] 3. Sharding: A data management and storage strategy or method that aims to split large databases or data sets into smaller parts (i.e., shards), which can be distributed on different storage media or nodes to improve the scalability, performance, and availability of the system.

[0035] 4. Hash space refers to the set of all possible hash values ​​generated by the hash algorithm. When performing a hash operation, we use a hash function to map an input value (such as a string, number, etc.) to a specific hash value. The hash space is the set of all these possible hash values.

[0036] In the context of big data, the data scale has leaped from GB level to PB level, which places extremely high demands on data storage and processing capabilities. Single-machine systems are obviously unable to effectively handle such a huge amount of data due to hardware resource limitations. Therefore, large-scale clusters have become an inevitable choice for processing big data. System scalability, as an important indicator to measure the quality of a system, is particularly important in big data processing. System scalability specifically refers to the ability of a system to improve performance and processing capabilities by adding resources (such as hardware, nodes, storage, etc.) when facing increased workloads or data volumes.

[0037] Traditional parallel database systems usually use vertical expansion to support more data. This approach mainly relies on improving the performance of single-machine hardware, such as increasing the number of CPU cores, expanding memory capacity, using faster storage devices, etc., in order to enhance the data processing capabilities of a single server. However, this approach has obvious limitations, that is, the improvement of hardware resources is often accompanied by high costs and is constrained by physical limits.

[0038] In contrast, the current mainstream big data storage and computing systems tend to adopt a horizontal expansion approach. This approach expands the system's processing power by increasing the number of machines to achieve horizontal expansion. Horizontal expansion can not only obtain stronger processing power at a lower cost, but also expand without interrupting services, improving the flexibility and availability of the system.

[0039] In order to effectively manage and process massive amounts of data, big data systems usually use data sharding technology. Data sharding refers to dividing a large-scale data set into multiple smaller parts and distributing these parts to different machines for storage and processing. After data sharding, how to quickly locate the storage location of a record becomes a key issue, which is usually achieved through data routing technology.

[0040] Data routing technology can map query requests to corresponding data shards according to certain rules (such as hash functions, range partitioning, etc.), thereby achieving fast access to data. At the same time, in order to ensure high availability of data, big data systems can also use data replication technology to store multiple copies of data shards on different machines to prevent data loss caused by single point failures.

[0041] In summary, system scalability has become an important indicator to measure the quality of the system under the background of big data. By adopting horizontal expansion and data sharding and data routing technology, big data systems can efficiently process massive data and meet the needs of enterprises and organizations for data processing capabilities. Common routing algorithms include: polling algorithm, consistent hashing algorithm, etc.

[0042] The routing scheme of the polling algorithm refers to assigning read and write requests to servers (or nodes) in sequence. For example, the first read and write request is sent to the first server, then the second read and write request is sent to the second server, and so on. After all the requests in one round are assigned, they are redistributed from the first server. However, if the performance of the servers in the cluster varies greatly, some servers may process very quickly while others may process very slowly. Using the polling algorithm may result in high-performance servers not being fully utilized, while poor-performance servers may be overloaded.

[0043] The routing scheme of the consistent hashing algorithm is that when a node fails, part of the data that the node was originally responsible for will be migrated to the next node. However, if the amount of data to be migrated is too large, or multiple nodes fail at the same time, the node receiving the data may crash due to excessive load, which will lead to an "avalanche effect". It can be seen that the consistent hashing algorithm itself does not take into account the performance differences of each node, which may cause the number of requests processed by nodes with strong performance and nodes with weak performance to be the same, resulting in unbalanced use of system resources and failure to give full play to the advantages of high-performance nodes.

[0044] The embodiment of the present application provides an adaptive routing method and device for CMDB cluster load, wherein CMDB is a database that stores and manages the configuration and status information of all IT resources (such as servers, network devices, software applications, etc.) in an organization. A cluster refers to a system composed of multiple computers or servers (referred to as nodes), and each node can work together through a network connection to complete a specific computing task. In practical applications, operation and maintenance personnel can manage and maintain CMDB through a CMDB operation and maintenance management platform so that CMDB can be applied to a cluster environment. Specifically, in a cluster environment, each computer (or server), database, storage device, etc. in the cluster is an IT resource and can be used as a configuration item (CI) in CMDB. Under the management of the CMDB operation and maintenance management platform, CMDB can record the structural information of the cluster, such as cluster nodes, the relationship between nodes, application deployment information, etc. Alternatively, in a cluster environment, nodes may change frequently, such as the addition, reduction, and failure recovery of nodes. Under the management of the CMDB operation and maintenance management platform, these changes can be synchronized and updated in CMDB. In actual applications, through the CMDB operation and maintenance management platform, operation and maintenance personnel can efficiently manage and monitor various configuration items of the cluster in the CMDB to ensure high availability, performance optimization, and rapid response to faults of the cluster.

[0045] The method provided in the embodiment of the present application can be applied to cluster operation and maintenance tools, such as a CMDB operation and maintenance management platform, so that it can adapt to changes in the cluster (such as increase or decrease of cluster nodes, increase or decrease of shard intervals, etc.) and change routing rules. In addition, the method can distinguish different cluster nodes based on the different weights of each cluster node, so that high-performance nodes can bear more business loads, while low-performance nodes bear relatively less business loads, thereby avoiding high-performance nodes being idle and low-performance nodes being overloaded, making more rational use of node resources, and realizing dynamic resource scheduling and load balancing.

[0046] Figure 1 A schematic diagram of the structure of a cluster provided in an embodiment of the present application.

[0047] like Figure 1 As shown, the cluster provided in the embodiment of the present application may include a master node host and multiple slave node hosts. The number of slave node hosts can be configured based on actual conditions, and the embodiment of the present application does not make any specific limitations on this. Figure 1 The cluster shown in the figure may be any one of a high availability cluster (HA Cluster), a load balancing cluster (Load Balancing Cluster), a computing cluster (Compute Cluster), a storage cluster (Storage Cluster) and a big data cluster (BigData Cluster), and the embodiments of the present application do not make any specific limitation on this.

[0048] The client can send the business data that needs to be stored to the master node host, and then the master node host can distribute the data to different slave node hosts for storage. Business data includes user behavior logs, transaction records, network traffic records, and video surveillance data. The client and the master node host can communicate through a lightweight protocol, such as TCP / IP protocol or HTTP / HTTPS protocol, which is not specifically limited in the embodiments of the present application.

[0049] Figure 2 A flowchart of a first adaptive routing method for CMDB cluster load provided in an embodiment of the present application.

[0050] Figure 3 A schematic diagram of the data processing flow provided for an embodiment of the present application.

[0051] like Figure 2 and Figure 3 As shown, the method provided in the embodiment of the present application can be applied to a master node host in a cluster, and can include the following steps S100-S400.

[0052] S100: receiving real-time performance data sent by multiple slave node hosts according to a preset period.

[0053] Among them, the real-time performance data can be the real-time data of various performance indicators, and the performance indicators can include resource performance indicators and / or business performance indicators. The resource performance indicators can include CPU occupancy, memory occupancy and / or storage occupancy, and the business performance indicators include the response time of each storage of the slave node host within a preset period, and can include the number of storage anomalies that occur in the slave node host within a preset period. By monitoring the performance data, the master node host can timely understand the health status and resource usage of each slave node host.

[0054] The preset period is, for example, 1 minute, 2 minutes or 5 minutes, which can be determined based on actual conditions and is not specifically limited in the embodiments of the present application.

[0055] S200: Calculate the weight value of each slave node host based on the real-time performance data.

[0056] The embodiment of the present application can calculate the weight value of each slave node host based on the real-time operation of the slave node host. In the embodiment of the present application, the weight value can be associated with the load capacity, processing capacity and current resource usage of the slave node host. Further, a slave node host with a lower load or stronger performance can obtain a higher weight value, while a slave node host with a higher load or poorer performance will obtain a lower weight value. In this way, it is helpful to dynamically adjust the load distribution of each slave node host in the cluster and improve the overall performance and resource utilization efficiency of the cluster.

[0057] The specific steps for calculating the weight value will be described in detail below and will not be repeated here.

[0058] Continue to see Figure 3 In an embodiment of the present application, a "probe" can be installed in each cluster slave node host, and the "probe" is used to collect the real-time performance data of the node. The real-time performance data is then sent to the master node host, specifically to the cluster service of the master node host. The cluster service can use this information to perform weight processing, that is, dynamically evaluate the load capacity of each slave node host according to the real-time performance of each slave node host. It should be supplemented that the "probe" can be a software component or tool deployed on the slave node host. The main function of the probe is to monitor, collect and report the real-time performance data of the slave node host.

[0059] S300: Update cluster routing rules based on the weight value.

[0060] It is understandable that the embodiment of the present application can update the cluster routing rules according to a preset period. In this step, the master node host can dynamically update the cluster routing rules according to the weight values ​​of each slave node calculated. The cluster routing rules define how the business data stream is distributed between different slave nodes to ensure that the data can be distributed to each node more reasonably, thereby avoiding overloading of some nodes and affecting system performance. The master node host can update the cluster routing rules after calculating the real-time weight value to adjust the routing strategy of the data stream. In this way, when a new business data stream arrives, the business data stream can be sent to the slave node with lighter load and higher performance first to improve the response speed and throughput of the cluster.

[0061] S400: When the client sends a service data stream to the master node host, the service data stream is mapped to each slave node host for storage according to the cluster routing rule.

[0062] When the client sends a business data stream to the master node host, the master node host can determine which one or more slave node hosts the business data stream should be stored on based on the cluster routing rules updated in the previous cycle. By mapping the data to the slave node host with the best performance for storage, the efficiency and reliability of data processing can be ensured, overload can be avoided, the processing capacity of the cluster can be improved, and the distribution and storage of data can be ensured to meet the load balancing requirements of the cluster.

[0063] It should also be noted that the business data flow can be a small data packet or a large data block. The business data flow can specifically include multiple business data, and the specific number can be determined based on actual conditions. The embodiments of the present application do not make specific limitations on this.

[0064] From the above content, it can be seen that the embodiment of the present application provides an adaptive routing method for CMDB cluster load, which includes: receiving real-time performance data sent by multiple slave node hosts according to a preset period; calculating the weight value of each slave node host based on the real-time performance data; updating the cluster routing rules based on the weight value; when the client sends a business data stream to the master node host, according to the cluster routing rules, the business data stream is mapped to each slave node host for storage. The method provided by the embodiment of the present application can distinguish each slave node host based on the weight value to solve the heterogeneity problem of physical nodes, and support the determination of storage strategies based on the resource usage of machines (hosts) with different performance. In addition, since each slave node host has a different weight value, when a slave node host fails, the storage strategy for the data to be stored can also be determined based on the weight value to avoid the problem of a single slave node being overloaded due to receiving too much data.

[0065] The following is an introduction to the steps for calculating the weight value of the slave node host.

[0066] Figure 4 A schematic diagram of a process for calculating the weight value of a slave node host provided in an embodiment of the present application.

[0067] like Figure 4 As shown, step S200 may include the following steps S201-S203.

[0068] S201: For each slave node host, calculate the weight score corresponding to the real-time data of each performance indicator according to the preset weight rule.

[0069] The preset weight rules define the thresholds, weight scores and weight coefficients of different performance indicators. Table 1 gives an exemplary introduction to the preset weight rules.

[0070] Table 1 Preset weight rules table

[0071] Performance Indicators Threshold Weight coefficient Weight score CPU 80％ 10 0.1 Memory 85％ 10 0.1 storage 90％ 10 0.1 Response time 1000ms 40 0.4 Abnormal number >1 30 0.3 100 1.0

[0072] When calculating the weight scores corresponding to the real-time data of each performance indicator according to the preset weight rules, if the real-time data of the performance indicator is less than or equal to its corresponding threshold, it will score, if the real-time data of the performance indicator is greater than its corresponding threshold, it will not score, or it will be recorded as zero. For example, the real-time performance data of a slave node host is as follows: CPU occupancy rate is 70%, memory occupancy rate is 60%, storage occupancy rate is 60%, and the storage response time within 1 minute is 200ms, 300ms and 600ms, and the number of storage anomalies within 1 minute is 1. Then, the weight scores of the performance indicators of the slave node host participating in the weight value calculation are 0.1, 0.1, 0.1, 0.4 and 0 respectively.

[0073] S202: Multiply each weight score by its corresponding weight coefficient to obtain a sub-weight value corresponding to the real-time data of each performance indicator; wherein the weight coefficients of different performance indicators are the same or different.

[0074] It can be understood that the weight score needs to be multiplied by its corresponding weight coefficient. For example, for the aforementioned slave node host, the sub-weight values ​​corresponding to the real-time data of its various performance indicators are: 10*0.1, 10*0.1, 10*0.1, 40*0.4.

[0075] S203: Sum the sub-weight values ​​to obtain the weight value of the slave node host.

[0076] Exemplarily, for the aforementioned slave node host, its final weight value is 10*0.1+10*0.1+10*0.1+40*0.4=19.

[0077] In this way, the weight value can reflect the real-time operation status of the slave node host in each preset period.

[0078] Figure 5 A schematic diagram of a process for storing business data in a slave node host provided in an embodiment of the present application.

[0079] Further, in an embodiment of the present application, when the client sends a service data stream to the master node host, the master node host can perform a hash calculation on the service data, and then divide the service data into different data shards according to the hash calculation result and a preset hash space range, and finally map the service data to the slave node host for storage based on the data shards. Specifically, step S400 can specifically include the following steps S401-S403.

[0080] S401: Perform hash processing on each piece of business data to obtain a hash process value for each piece of business data.

[0081] In this step, a hash operation can be performed on each piece of business data received. A hash operation is an algorithm that converts data of any length into a numerical value of a fixed length. Through the hash operation, a unique identifier, i.e., a hash process value, can be generated for each piece of business data. This hash process value will be used for subsequent data distribution and routing decisions. In the embodiment of the present application, a hash algorithm such as the MD5 algorithm, the SHA-1 algorithm, etc. can be used to calculate the hash process value, and the embodiment of the present application does not specifically limit this.

[0082] S402: Based on the cluster routing rule, determine multiple sharding intervals formed by the current hash space division.

[0083] The current hash space size is the default value, for example, the current hash space size is 1024. Figure 3 As shown, the current hash space can be divided into two shard intervals, namely shard 1 and shard 2. Furthermore, different shard intervals can have different hash space ranges. When the size of the current hash space is 1024, the hash space range of shard 1 can be 0-511, and the hash space range of shard 2 can be 512-1023. Each shard interval includes multiple data shards, and different data shards correspond to different hash values ​​in the hash space range. When the size of the current hash space is 1024, the hash space range of shard 1 is 0-511, and the hash space range of shard 2 is 512-1023, then shard 1 includes 512 data shards, and shard 2 includes 512 data shards. Each data shard corresponds to a hash value. The hash values ​​corresponding to the 512 data shards included in shard 1 are 0, 1, 2...511, respectively, and the hash values ​​corresponding to the 512 data shards included in shard 2 are 512, 513, 514...1023, respectively. For example, the first data shard in shard 1 corresponds to the hash value "0", and so on.

[0084] S403: For each piece of business data, distribute it to each data shard according to its corresponding hash process value.

[0085] Among them, the embodiment of the present application can perform a modulo calculation on the hash process value, specifically, modulo the size of the current hash space 1024. For example, the hash process value of a certain business data is calculated to be a591a6d40bf420404a011733cfb7b190d62c65bf0bcda88e5a99e3cbb6db05ee. The step of taking the modulo of the hash process value to 1024 includes: The hexadecimal number is converted to binary and then the remainder is taken. The remainder includes: 75706761187104745339774078915663541050433676615548413841373198493263910094%1024=862, that is, the remainder result is 862, then the business data can be allocated to the data shard corresponding to the hash value 862, and the data shard is specifically located in shard 2.

[0086] For further information, see Figure 5 , step S403 may be followed by the following steps S404-S405.

[0087] S404: Based on the cluster routing rules, determine each slave node host included in the shard interval.

[0088] For example, Figure 3 As shown, for the sharding interval of sharding 1, it includes slave node host 1, slave node host 2, slave node host 3 and slave node host 4, a total of four slave node hosts. For the sharding interval of sharding 2, it includes slave node host 5, slave node host 6, slave node host 7 and slave node host 8, a total of four slave node hosts.

[0089] It is worth noting that the number of shard intervals, the hash space range of the shard intervals, and the slave node host data included in the shard intervals can all be designed and modified when configuring the cluster or presetting the cluster routing rules.

[0090] S405: For each shard interval, map the data shards included therein to the respective slave node hosts according to the weight values ​​of the respective slave node hosts corresponding thereto, so that the slave node hosts store the business data in the data shards.

[0091] This step is the node mapping step. The node mapping server of the master node host can map the data shards to specific slave node hosts in proportion according to the weight values ​​of each slave node host in the cluster. Since the weight value supports dynamic update, the node mapping also supports dynamic adjustment. In actual applications, node mapping can be performed based on the proportion of the weight values ​​of each slave node host.

[0092] For example, when the weight value of slave node host 1 is equal to 30, the weight value of slave node host 2 is equal to 30, the weight value of slave node host 3 is equal to 20, and the weight value of slave node host 4 is equal to 20, then for the data shards to be stored in shard 1, they can be divided according to the number of data shards, and 30% of them can be mapped to slave node host 1, 30% to slave node host 2, 20% to slave node host 3, and 20% to slave node host 4, and the mapping ratio is 3:3:2:2.

[0093] The method provided in the embodiment of the present application can also dynamically adjust the data routing capability of the system based on the expansion or reduction of the cluster size without reallocating all data, and when a slave node host fails, the data to be stored can also be allocated to several other slave node hosts included in the same shard interval, without a single slave node host assuming the storage task of the failed slave node host. This step is described in detail below in conjunction with the accompanying drawings.

[0094] Figure 6 A schematic diagram of the data slice remapping process provided in an embodiment of the present application.

[0095] like Figure 6 As shown, the embodiment of the present application may also include the following steps S501-S502.

[0096] S501: For a target sharding interval, when one or more slave node hosts included therein fail, determine the unstored data shards corresponding to the failed slave node hosts.

[0097] When a slave node host fails, its node mapping service will automatically disconnect from the master node host, and the master node host will no longer interact with the failed slave node host. Further, the master node host can determine the data shards that have not been stored in the target shard interval when the shard interval includes one or more failed slave node hosts.

[0098] S502: according to the weight value of the first slave node host, remap the unstored data slices to each first slave node host so that the first slave node host stores the business data in the unstored data slices; wherein the first slave node host is a non-failed slave node host included in the target slice interval.

[0099] The embodiment of the present application can use all the slave node hosts that have not failed in the target sharding interval to share the storage task, and the master node host can be mapped according to the weight value of the remaining slave node hosts. Exemplarily, when slave node host 4 fails, and the cluster routing rule shows that the weight value of slave node host 1 is 20, the weight value of slave node host 2 is 40, and the weight value of slave node host 3 is 30, then the business data in the unstored data shards will be mapped to slave node host 1, slave node host 2 and slave node host 3 in proportion, and the mapping ratio is slave node host 1: slave node host 2: slave node host 3 = 2:4:3. It can be understood that the mapping ratio is determined based on the weight size. Further, each slave node host can store the business data in the unstored data shards, so that the problem of failure overload can be avoided, and the stability and reliability of the system can be significantly improved.

[0100] In the embodiment of the present application, the cluster routing rules are changeable, for example, a first change or a second change occurs, the first change of the cluster routing rules refers to an increase in the shard interval of the current hash space, and the second change of the cluster routing rules may refer to a decrease in the shard interval of the current hash space. In addition, the cluster scale can also be expanded or reduced, which can be specifically reflected in the increase or decrease in the number of slave node hosts. The following will be classified and discussed in terms of the increase or decrease in shard intervals, the increase or decrease in slave node hosts, and the change of the slave node host's shard interval.

[0101] The method provided in the embodiment of the present application also includes the following step S601.

[0102] S601: In response to a first change in a cluster routing rule, determine whether a newly added shard interval includes a newly added slave node host and / or an original slave node host.

[0103] The first case: the number of shard intervals increases, and the newly added shard intervals only include the newly added slave node hosts.

[0104] Figure 7 A first flow chart of data migration provided in an embodiment of the present application.

[0105] like Figure 7 As shown, in the first case, step S601 may be followed by the following steps S602-S605.

[0106] S602: If the newly added shard interval includes a newly added slave node host, determine the updated hash space range of the original shard interval based on the cluster routing rule.

[0107] like Figure 7As shown, the newly added shard interval can be shard 3, that is, the current hash space is changed from two shard intervals to three shard intervals, then the hash space ranges of the three shard intervals are: 0-341, 342-683 and 684-1023. In other words, the hash space range of shard 1 is updated from 0-511 to 0-341, and the hash space range of shard 2 is updated from 512-1023 to 342-683.

[0108] S603: For each original sharding interval, determine the range difference between the corresponding original hash space range and the updated hash space range.

[0109] It can be understood that for shard 1, the range difference is 342-511, and for shard 2, the range difference is 684-1023.

[0110] S604: Determine the data shard to be migrated corresponding to the range difference, and determine the migration address of the data shard to be migrated, wherein the migration address is determined by the hash value corresponding to the data shard to be migrated, and the migration address is other original shard intervals or newly added shard intervals.

[0111] It can be understood that for shard 1, the data shards to be migrated corresponding to the range difference are the data shards corresponding to the hash values ​​342-511, and for shard 2, the data shards to be migrated corresponding to the range difference are the data shards corresponding to the hash values ​​684-1023.

[0112] In an embodiment of the present application, the step of migrating the data shards to be migrated may be the step of migrating the business data corresponding to the data shards to be migrated (business data originally stored in the slave node host) to the newly added slave node host for storage, so that the storage pressure of the original slave node host can be alleviated. Specifically, it can be determined that the migration address of the data shards to be migrated is the newly added shard interval. At this time, the data shards to be migrated are the data shards with hash values ​​342-511 and the data shards with hash values ​​684-1023. Then, the business data corresponding to the data shards to be migrated can be directly migrated to the newly added slave node host for storage.

[0113] In some implementations, the migration address may also be other original shard intervals, which may also be referred to as target shard intervals. Specifically, it may be determined based on the range difference and the updated hash space range of the target shard interval. When the range difference falls within the updated hash space range of the original shard interval, the original shard interval is the target shard interval. For example, the business data corresponding to each data shard with hash values ​​of 342-511 may be migrated to the original slave node host corresponding to shard 2, the business data corresponding to each data shard with hash values ​​of 512-683 in shard 2 may not be migrated, and the business data corresponding to each data shard with hash values ​​of 684-1023 may be migrated to the newly added slave node host corresponding to the newly added shard 3. Figure 7 The figure only shows the case where the migration address is a newly added data shard.

[0114] S605: Based on the migration address, migrate the first business data to the original slave node host or the newly added slave node host, where the first business data is the business data corresponding to the data shard to be migrated.

[0115] like Figure 7 As shown, the newly added slave node hosts are, for example, slave node hosts 9 and slave node hosts 10. It is worth noting that, since the slave node host weight values ​​of the newly added shard intervals are yet to be determined, the business data corresponding to the data shards to be migrated can be evenly distributed to the newly added slave node hosts.

[0116] In this way, the storage pressure on the original slave node host can be alleviated.

[0117] The second situation: the number of shard intervals increases, and the newly added shard intervals include the newly added slave node hosts and the original slave node hosts.

[0118] Figure 8 A second flow chart of data migration provided in an embodiment of the present application.

[0119] like Figure 8 As shown, step S601 may further include the following steps S606-S608.

[0120] S606: If the newly added sharding interval includes the original slave node host, the original slave node host corresponding to the newly added sharding interval is determined as the host to be migrated.

[0121] It is understandable that if the cluster routing rules define a new shard interval including the original slave node host and the new slave node host, then the original slave node host will be migrated to the new shard interval, and the business data stored by the original slave node host will also be stored by other slave node hosts in its original shard interval.

[0122] S607: Determine the target original sharding interval to which the host to be migrated belongs before the first change occurs to the cluster routing rule.

[0123] Exemplarily, the host to be migrated may be slave node host 1, and the target original shard interval is shard 1.

[0124] S608: Migrate the second business data to each second slave node host according to the weight value of the second slave node host; wherein the second slave node host is the other slave node hosts included in the target original shard interval except the host to be migrated; when the newly added shard interval includes the newly added slave node host and the original slave node host, the second business data is the part of the business data stored in the host to be migrated except the first business data.

[0125] It is understandable that when migrating the host to be migrated to the newly added sharding interval, the business data stored in it can be migrated to other slave node hosts in the original sharding interval. Then, when new business data arrives, the master node host can map the data shards of the newly added sharding interval to the host to be migrated based on the latest cluster routing rules.

[0126] It is worth noting that the second business data does not include the first business data, which means that when the host to be migrated needs to be migrated to a newly added shard interval, the business data corresponding to the data shard to be migrated stored therein (i.e., the first business data) does not need to be migrated to the second slave node host, which can avoid complicated migration steps.

[0127] It is worth noting that in this case, the newly added shard range includes both the newly added slave node host and the original slave node host. Therefore, the steps of determining the host to be migrated and migrating the business data can be performed first, and then the steps of determining the data shard to be migrated and migrating the business data can be performed, that is, first perform steps S606-S608, and then perform steps S602-S605. In this way, the shard range can be updated after the host ownership is updated, which can avoid business migration failures.

[0128] It is worth noting that since the weight value of the slave node host of the newly added shard interval is yet to be determined, the business data corresponding to the data shard to be migrated can be stored in the newly added slave node host instead of being migrated to the host to be migrated. After the business data migration of the host to be migrated is completed and the weight value is determined, the host to be migrated can be used for storage. The third situation: the number of shard intervals increases, and the newly added shard interval only includes the original slave node host.

[0129] It can be understood that steps S602-S605 are executed under the condition that "the newly added shard interval includes the newly added slave node host", and steps S606-S608 are executed under the condition that "the newly added shard interval includes the original slave node host". Therefore, in the third case, since the newly added shard interval only includes the original slave node host, only steps S606-S608 need to be executed to complete the slave node host migration, and steps S602-S605 do not need to be executed. At this time, the second business data is all the business data stored in the host to be migrated.

[0130] The fourth case: the sharding range remains unchanged and a new slave node host is added.

[0131] At this time, you only need to map the nodes according to the weight values ​​of each slave node host in the latest cluster routing rules when mapping the nodes, without redistributing all business data.

[0132] In some implementations, the weight value of the newly added slave node host may default to 0, 20, or 30, which is not specifically limited in the embodiments of the present application.

[0133] The fifth case: the sharding interval is reduced and the slave node host remains unchanged.

[0134] At this time, you only need to map the nodes according to the weight values ​​of each slave node host in the latest cluster routing rules when mapping the nodes, without redistributing all business data.

[0135] The sixth situation: the number of shard intervals decreases and the number of slave node hosts also decreases.

[0136] At this time, you only need to map the nodes according to the weight values ​​of each slave node host in the latest cluster routing rules when mapping the nodes, without redistributing all business data.

[0137] It is worth noting that the increase or decrease of shard intervals and the increase or decrease of slave node hosts depend on the data volume of the business data flow in the past period of time, or on the data volume change trend of the business data flow. When the data volume continues to grow, more shard intervals and slave node hosts can be added to cope with higher data processing and storage requirements. On the contrary, if the data volume decreases or shows a downward trend, the number of shard intervals and slave node hosts can be appropriately reduced to optimize resource utilization and reduce unnecessary overhead. This dynamic adjustment mechanism enables the cluster to flexibly adapt to fluctuations in data volume, ensuring both economic efficiency and stability and reliability.

[0138] In actual operation, cluster administrators or automated tools can be used to regularly analyze the data volume and changing trends of business data flows, and adjust the configuration of shard intervals and slave node hosts based on the analysis results, that is, adjust cluster routing rules. In this way, dynamic resource scheduling can be achieved.

[0139] It is worth noting that, in the embodiment of the present application, the cluster routing rules define how the shard intervals are divided, the mapping relationship between the shard intervals and the slave node hosts, and the weight value of each slave node host.

[0140] Fig. 9 A flowchart of a second adaptive routing method for CMDB cluster load provided in an embodiment of the present application.

[0141] like Fig. 9 As shown, the second adaptive routing method for CMDB cluster load provided in the embodiment of the present application can be applied to any slave node host in the cluster, and the method can include the following steps S701-S702.

[0142] S701: Collect real-time performance data according to a preset period.

[0143] S702: Send the real-time performance data to the master node host.

[0144] as well as,

[0145] The method further includes S703: when the client sends a service data stream to the master node host, storing the corresponding service data stream in response to the mapping of the master node host.

[0146] In this way, the slave node host can regularly collect and report real-time performance data, and can execute storage tasks.

[0147] In summary, the adaptive routing method for CMDB cluster load provided by the embodiment of the present application can solve the heterogeneity problem and fault overload problem of physical nodes, and can significantly improve the stability and reliability of the system. In addition, it can better cope with sudden traffic and fault conditions, and ensure the continuity and integrity of business data. In addition, the method provided by the embodiment of the present application can more reasonably utilize the resources of physical nodes through dynamic resource scheduling and load balancing strategies, high-performance nodes can bear more business loads, and low-performance nodes can avoid overload. In addition, the method provided by the embodiment of the present application can be used to configure automated and intelligent operation and maintenance tools, so that the need for manual intervention can be reduced and the operation and maintenance costs can be reduced.

[0148] Fig.10 A schematic diagram of the structure of a first adaptive routing device for CMDB cluster load provided in an embodiment of the present application.

[0149] like Fig.10 As shown, an embodiment of the present application provides an adaptive routing device for CMDB cluster load, the cluster includes a master node host and multiple slave node hosts, the device is applied to the master node host, and the device includes:

[0150] The receiving module 1001 is used to receive real-time performance data sent by multiple slave node hosts according to a preset period;

[0151] A calculation module 1002 is used to calculate the weight value of each slave node host based on the real-time performance data;

[0152] An updating module 1003, configured to update cluster routing rules based on weight values;

[0153] The mapping module 1004 is used to map the service data stream to each slave node host for storage according to the cluster routing rule when the client sends the service data stream to the master node host.

[0154] In some implementations, the mapping module 1004 is specifically used to: perform hash processing on each piece of business data separately to obtain a hash process value for each piece of business data; determine multiple shard intervals formed by the current hash space division based on cluster routing rules; wherein the size of the current hash space is a default value, different shard intervals have different hash space ranges, each shard interval includes multiple data shards, and different data shards correspond to different hash values ​​in the hash space range; for each piece of business data, allocate it to each data shard according to its corresponding hash process value.

[0155] In some implementations, the mapping module 1004 is also used to: determine the various slave node hosts included in the shard interval based on the cluster routing rules; for each shard interval, map the data shards included therein to the various slave node hosts according to the weight values ​​of the corresponding slave node hosts, so that the slave node hosts store the business data in the data shards.

[0156] In some implementations, the mapping module 1004 is also used to: for a target sharding interval, when one or more slave node hosts included therein fail, determine the unstored data shards corresponding to the failed slave node hosts; remap the unstored data shards to each first slave node host according to the weight value of the first slave node host, so that the first slave node host stores the business data in the unstored data shards; wherein the first slave node host is a slave node host that has not failed and is included in the target sharding interval.

[0157] In some implementations, the cluster routing rules are changeable, and the first change in the cluster routing rules refers to the increase in the number of shard intervals in the current hash space. The mapping module 1004 is also used to: in response to the first change in the cluster routing rules, determine whether the newly added shard interval includes the newly added slave node host and / or the original slave node host; if the newly added shard interval includes the newly added slave node host, determine the updated hash space range of the original shard interval based on the cluster routing rules; for each original shard interval, determine the range difference between the original hash space range and the updated hash space range; determine the data shard to be migrated corresponding to the range difference, and determine the migration address of the data shard to be migrated, wherein the migration address is determined by the hash value corresponding to the data shard to be migrated, and the migration address is other original shard intervals or newly added shard intervals; based on the migration address, migrate the first business data to the original slave node host or the newly added slave node host, and the first business data is the business data corresponding to the data shard to be migrated.

[0158] In some implementations, the mapping module 1004 is also used for: if the newly added shard interval includes the original slave node host, determining the original slave node host corresponding to the newly added shard interval as the host to be migrated; determining the target original shard interval to which the host to be migrated belongs before the first change in the cluster routing rule occurs; migrating the second business data to each second slave node host according to the weight value of the second slave node host; wherein the second slave node host is the other slave node host included in the target original shard interval except the host to be migrated; when the newly added shard interval only includes the original slave node host, the second business data is all the business data stored in the host to be migrated, and when the newly added shard interval includes the newly added slave node host and the original slave node host, the second business data is the part of the business data stored in the host to be migrated except the first business data.

[0159] In some implementations, the real-time performance data is the real-time data of various performance indicators, the performance indicators include resource performance indicators and / or business performance indicators, the resource performance indicators include CPU occupancy, memory occupancy and / or storage occupancy, the business performance indicators include the response time of each storage of the slave node host within a preset period, and the number of storage anomalies that occur in the slave node host within a preset period; the calculation module 1002 is specifically used to: for each slave node host, according to the preset weight rule, calculate the weight score corresponding to the real-time data of each performance indicator; multiply each weight score by its corresponding weight coefficient to obtain the sub-weight value corresponding to the real-time data of each performance indicator; wherein the weight coefficients of different performance indicators are the same or different; sum the sub-weight values ​​to obtain the weight value of the slave node host.

[0160] Fig.11 A schematic diagram of the structure of a second adaptive routing device for CMDB cluster load provided in an embodiment of the present application.

[0161] like Fig.11 As shown, the embodiment of the present application also provides an adaptive routing device for CMDB cluster load, the cluster includes a master node host and multiple slave node hosts, the device is applied to any slave node host, and the device includes:

[0162] The collection module 2001 is used to collect real-time performance data according to a preset period;

[0163] The sending module 2002 is used to send the real-time performance data to the master node host;

[0164] as well as,

[0165] The device also includes: a storage module 2003, which is used to store the corresponding business data stream in response to the mapping of the main node host when the client sends the business data stream to the main node host.

[0166] In a specific implementation, the present invention further provides a computer storage medium, wherein the computer storage medium may store a program, and when the program is executed, the program may include some or all of the steps in each embodiment of the adaptive routing method for CMDB cluster load provided by the present invention. The storage medium may be a disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM).

[0167] It is easy to understand that those skilled in the art can combine, split, reorganize, etc. the embodiments of the present application to obtain other embodiments based on the several embodiments provided in the present application, and these embodiments do not exceed the protection scope of the present application.

[0168] The above specific implementation methods further explain in detail the purpose, technical solutions and beneficial effects of the embodiments of the present application. It should be understood that the above are only specific implementation methods of the embodiments of the present application and are not used to limit the protection scope of the embodiments of the present application. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solutions of the embodiments of the present application should be included in the protection scope of the embodiments of the present application.

Claims

1. An adaptive routing method for CMDB cluster load, characterized in that: The cluster includes a master node host and multiple slave node hosts. The method is applied to the master node host. The method includes: Receiving real-time performance data sent by a plurality of slave node hosts according to a preset period; Calculate the weight value of each slave node host based on the real-time performance data; Updating cluster routing rules based on the weight value; When the client sends a service data stream to the master node host, the service data stream is mapped to each of the slave node hosts for storage according to the cluster routing rule.

2. The adaptive routing method for CMDB cluster load according to claim 1, characterized in that: The service data stream includes a plurality of service data; when the client sends the service data stream to the master node host, the step of mapping the service data stream to each of the slave node hosts for storage according to the cluster routing rule includes: Performing hash processing on each piece of the business data to obtain a hash process value for each piece of the business data; Based on the cluster routing rule, multiple shard intervals formed by the current hash space division are determined; wherein the size of the current hash space is a default value, different shard intervals have different hash space ranges, each shard interval includes multiple data shards, and different data shards correspond to different hash values ​​in the hash space range; For each piece of the business data, it is allocated to each of the data shards according to its corresponding hash process value.

3. The adaptive routing method for CMDB cluster load according to claim 2, characterized in that: After allocating each piece of the business data to each of the data shards according to its corresponding hash process value, the method further includes: Based on the cluster routing rule, determine each of the slave node hosts included in the shard interval; For each of the shard intervals, the data shards included therein are mapped to the respective slave node hosts according to the weight values ​​of the corresponding slave node hosts, so that the slave node hosts store the business data in the data shards.

4. The adaptive routing method for CMDB cluster load according to claim 2, characterized in that: The method further comprises: For the target sharding interval, when one or more slave node hosts included therein fail, determine the unstored data shards corresponding to the failed slave node hosts; According to the weight value of the first slave node host, the unstored data slice is remapped to each of the first slave node hosts so that the first slave node host stores the business data in the unstored data slice; wherein, the first slave node host is the slave node host that has not failed and is included in the target slice interval.

5. The adaptive routing method for CMDB cluster load according to claim 2, characterized in that: The cluster routing rule is changeable, and the first change of the cluster routing rule refers to an increase in the sharding interval of the current hash space; The method further comprises: In response to a first change in the cluster routing rule, determining whether the newly added shard interval includes a newly added slave node host and / or an original slave node host; If the newly added sharding interval includes the newly added slave node host, determining the updated hash space range of the original sharding interval based on the cluster routing rule; For each of the original sharding intervals, determine the range difference between the original hash space range corresponding to the original sharding interval and the updated hash space range; Determine the data shard to be migrated corresponding to the range difference, and determine the migration address of the data shard to be migrated, wherein the migration address is determined by the hash value corresponding to the data shard to be migrated, and the migration address is the other original shard interval or the newly added shard interval; Based on the migration address, migrate the first business data to the original slave node host or the newly added slave node host, the first business data being the business data corresponding to the data shard to be migrated.

6. The adaptive routing method for CMDB cluster load according to claim 5, characterized in that: In response to a first change in the cluster routing rule, after the step of determining whether the newly added shard interval includes a newly added slave node host and / or an original slave node host, the method further includes: If the newly added sharding interval includes the original slave node host, determining the original slave node host corresponding to the newly added sharding interval as the host to be migrated; Determine the target original sharding interval to which the host to be migrated belongs before the first change occurs to the cluster routing rule; The second business data is migrated to each of the second slave node hosts according to the weight value of the second slave node host; wherein the second slave node host is the other slave node hosts included in the target original sharding interval except the host to be migrated; when the newly added sharding interval only includes the original slave node hosts, the second business data is all the business data stored in the host to be migrated; when the newly added sharding interval includes the newly added slave node host and the original slave node host, the second business data is the part of the business data stored in the host to be migrated except the first business data.

7. The adaptive routing method for CMDB cluster load according to claim 1, characterized in that: The real-time performance data is real-time data of various performance indicators, the performance indicators include resource performance indicators and / or business performance indicators, the resource performance indicators include CPU occupancy, memory occupancy and / or storage occupancy, the business performance indicators include the response time of each storage of the slave node host within the preset period, and the number of storage anomalies of the slave node host within the preset period; The step of calculating the weight value of each slave node host based on the real-time performance data includes: For each of the slave node hosts, calculate the weight score corresponding to the real-time data of each performance indicator according to the preset weight rule; Multiply each weight score by its corresponding weight coefficient to obtain a sub-weight value corresponding to the real-time data of each performance indicator; wherein the weight coefficients of different performance indicators are the same or different; The sub-weight values ​​are summed to obtain the weight value of the slave node host.

8. An adaptive routing method for CMDB cluster load, characterized in that: The cluster includes a master node host and multiple slave node hosts, and the method is applied to any of the slave node hosts. The method includes: Collect real-time performance data according to preset cycles; Sending the real-time performance data to the master node host; as well as, The method further includes: when the client sends a service data stream to the master node host, storing the corresponding service data stream in response to the mapping of the master node host.

9. An adaptive routing device for CMDB cluster load, characterized in that: The cluster includes a master node host and multiple slave node hosts, and the device is applied to the master node host. The device includes: A receiving module, used for receiving real-time performance data sent by a plurality of slave node hosts according to a preset period; A calculation module, used for calculating the weight value of each slave node host based on the real-time performance data; An updating module, used for updating cluster routing rules based on the weight value; A mapping module is used to map the business data stream to each of the slave node hosts for storage according to the cluster routing rules when the client sends the business data stream to the master node host.

10. An adaptive routing device for CMDB cluster load, characterized in that: The cluster includes a master node host and multiple slave node hosts, and the device is applied to any of the slave node hosts, and the device includes: A collection module, used to collect real-time performance data according to a preset period; A sending module, used for sending the real-time performance data to the master node host; as well as, The device also includes: a storage module, which is used to store the corresponding business data stream in response to the mapping of the master node host when the client sends the business data stream to the master node host.

Images