A dynamic hot data migration method of a distributed cache system

Abstract

This invention belongs to the field of distributed caching technology and relates to a dynamic hotspot data migration method for distributed caching systems. By acquiring multi-dimensional operational status data in real time and generating a real-time status dataset, this invention overcomes the lag and inadequacy of traditional static sharding strategies in dealing with hotspot data, improving the accuracy of system load distribution perception. It establishes a dynamic linkage mechanism between hotspot prediction, migration cost simulation, and node resource allocation. Based on access trend parameters and changes in node instantaneous processing capacity, it differentiates and adjusts data migration paths and synchronization strategies, achieving optimal matching between hotspot data distribution and node resource utilization, as well as a dynamic balance between service performance and stability. Through background incremental synchronization and traffic collaborative control, it monitors the distribution of read and write requests during the data migration process in real time and continuously optimizes the migration plan based on objective indicators, avoiding service jitter and resource contention during migration.

Description

Technical Field

[0001] This invention belongs to the field of distributed caching technology and relates to a method for dynamic hot data migration in a distributed caching system. Background Technology

[0002] Distributed caching systems are an indispensable key component in modern large-scale network applications. They accelerate data access and reduce the pressure on backend databases by caching frequently accessed data in memory. In the field of digital data processing, such systems typically consist of multiple cache nodes, which distribute data across different nodes using specific data sharding strategies. As business access volume dynamically changes, the access frequency of certain data items may increase sharply, forming so-called "hot data." If not effectively handled, a single node will bear enormous pressure and become a system performance bottleneck.

[0003] To address the issue of hot data, existing technologies typically employ migration methods based on monitoring thresholds. These methods periodically monitor the performance metrics of each cache node, such as CPU utilization, network bandwidth, or the access frequency of data items. When a metric on a node exceeds a preset static threshold, the system identifies the specific data on that node as hot data and initiates a migration process to copy it from the high-load node to a currently less loaded node.

[0004] However, the aforementioned existing technical solutions have significant technical shortcomings in practical applications. First, monitoring methods based on static thresholds suffer from recognition lag, often triggering migration only after system performance has already been affected. Second, the migration process itself consumes resources from both the source and target nodes, and direct data replication operations can easily cause service instability. Furthermore, selecting target nodes based solely on their current load does not adequately consider the potential load changes after data migration, which can easily lead to the target node quickly becoming a new hotspot or causing uneven resource allocation. Summary of the Invention

[0005] In view of this, in order to solve the problems mentioned in the background technology, a dynamic hot data migration method for distributed caching systems is proposed. The method adopts a technical solution that combines prediction-driven, simulation decision-making and seamless execution, which can realize the active and smooth migration of hot data, and improve the overall stability and resource utilization efficiency of the system.

[0006] The objective of this invention can be achieved through the following technical solution: This invention provides a dynamic hotspot data migration method for a distributed caching system, comprising: acquiring multi-dimensional running status data of each node in the distributed caching system in real time, generating a real-time status dataset, performing a lightweight trend prediction operation, and outputting the predicted hotspot data identifier and the corresponding access trend parameters;

[0007] Based on the predicted hotspot data identifiers and access trend parameters, a migration cost simulation operation is performed on the candidate target node set to generate the instantaneous processing capacity score change of the node and the predicted link load value, and to determine the optimal migration target node.

[0008] A target buffer is created at the optimal migration target node, and an asynchronous data preloading operation is performed. When the asynchronous data preloading operation is completed, a source sub-route switching operation is triggered to direct new read requests to the target buffer.

[0009] The source buffer is retained in the source node to handle read and write requests before the switch. The write operations during the operation of the target buffer and the updated data in the source buffer are performed in the background for incremental synchronization to generate the final target buffer.

[0010] When the background incremental synchronization operation is completed, the request is switched to generate the final target buffer and the source buffer is cleared. The actual migration process indicator data is collected and fed back to the lightweight trend prediction operation and migration cost simulation operation.

[0011] Compared with existing technologies, the beneficial effects of the present invention are as follows: 1. The present invention, through a forward-looking prediction mechanism combined with multi-dimensional state perception, can proactively identify and intervene before hot data truly becomes a performance bottleneck. Compared with the traditional passive threshold triggering mechanism, it significantly improves the timeliness of hotspot processing, avoids service quality degradation caused by response lag, and thus ensures the stable operation of the system in high-concurrency scenarios.

[0012] 2. This invention innovatively introduces a migration cost simulation decision-making process. When selecting a target node, it not only considers its current load but also proactively assesses the comprehensive impact of the migration action itself and subsequent accesses. This globally optimal decision-making approach ensures the rationality of migration target selection, effectively prevents the generation of new bottlenecks, and achieves balanced utilization of system resources and optimization of overall performance.

[0013] 3. This invention employs a seamless execution scheme combining dual-buffered gradual migration and traffic-coordinated switching, minimizing the impact of data migration on online services. Through a series of refined operations such as asynchronous preloading, read-write separation, and background incremental synchronization, a smooth data transition is achieved, ensuring that users experience virtually no impact throughout the migration process, greatly improving system availability and service continuity.

[0014] 4. This invention constructs a complete feedback optimization closed loop from execution to perception, continuously iterating and refining the prediction model and decision parameters by collecting effect data during the actual migration process. This self-learning and adaptive mechanism enables the system to continuously evolve and has a stronger ability to adapt to changing business load patterns, thereby ensuring the efficiency and robustness of the method in long-term operation. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments 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.

[0016] Figure 1 This is a schematic diagram of the implementation steps of the method of the present invention.

[0017] Figure 2 This is a flowchart of buffer management corresponding to one embodiment of the present invention.

[0018] Figure 3 This is a flowchart illustrating a lightweight trend prediction operation corresponding to one embodiment of the present invention.

[0019] Figure 4 The flowchart illustrates the migration cost simulation operation for one embodiment of the present invention. Detailed Implementation

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

[0021] Please see Figure 1 As shown, this invention provides a method for dynamic hotspot data migration in a distributed caching system, with the following specific steps:

[0022] The system acquires multi-dimensional operational status data of each node in the distributed caching system in real time, generates a real-time status dataset, performs lightweight trend prediction operations, and outputs predicted hot data identifiers and corresponding access trend parameters.

[0023] In a preferred embodiment of the present invention, the specific method for acquiring the multidimensional operating status data is as follows: collecting the real-time access frequency change rate, access source distribution characteristics, and read / write request ratio parameters of each data item.

[0024] Monitor the CPU utilization, memory usage, input / output wait queue depth, and network transmit / receive queue depth of each node.

[0025] Obtain the link delay parameters and available bandwidth parameters between nodes.

[0026] The real-time status dataset is generated by combining the access frequency change rate, access source distribution characteristics, read / write request ratio parameters, CPU utilization, memory usage, input / output waiting queue depth, network transceiver queue depth, link latency parameters, and available bandwidth parameters.

[0027] It should be explained that, in order to achieve a comprehensive and in-depth understanding of the system status, this method first obtains multi-dimensional operational status data from three dimensions: data items, nodes, and network.

[0028] At the data item level, for each monitored data unit, the system not only counts the number of accesses but also calculates the real-time access frequency change rate to capture the growth trend of access popularity. At the same time, the system analyzes the request source to form access source distribution characteristics, which is used to determine whether the hotspot is caused by a single source or by general access. It also counts the ratio of read and write operations and generates read and write request ratio parameters to provide a basis for differentiated processing of subsequent migration strategies.

[0029] At the node level, the system monitors the status of each physical or virtual node in the distributed cache and collects its core performance indicators, including CPU utilization reflecting the computing load, memory occupancy reflecting resource capacity, and input / output wait queue depth and network transceiver queue depth revealing potential performance bottlenecks.

[0030] At the network level, the system proactively acquires key information about the communication quality between nodes, namely link latency parameters and available bandwidth parameters, through lightweight inter-node probing, in order to assess the channel status of data migration.

[0031] Finally, the system structurally integrates all the parameters collected above, including access frequency change rate, access source distribution characteristics, read / write request ratio parameters, CPU utilization, memory usage, input / output waiting queue depth, network transmit / receive queue depth, link latency parameters, and available bandwidth parameters, to generate a unified and comprehensive real-time status dataset. This dataset provides accurate and multi-dimensional input for subsequent trend prediction and migration decisions.

[0032] Please see Figure 3 As shown, in a preferred embodiment of the present invention, the specific method for performing the lightweight trend prediction operation is as follows: input the real-time status dataset into a preset exponential smoothing model, and calculate the predicted value of the access intensity within the future time window.

[0033] Furthermore, the specific analysis method and calculation formula for the predicted access intensity value are as follows: ,in Indicates the first Exponentially smoothed value for a time period Indicates the first Exponentially smoothed value for a time period This represents the smoothing coefficient, which by default prioritizes recent data. Further optimization and adjustments can be made based on feedback. This represents the actual access intensity in period t. The exponentially smoothed value of the latest period is used as the predicted access intensity for the next time window.

[0034] It should be explained that the exponential smoothing model is a time series forecasting method. Its core idea is that the trend of time series has stability and continuity. Therefore, it assigns greater weight to recent observation data and less weight to long-term data. By using this weighted averaging method, it smooths out random fluctuations in the data, thereby revealing the inherent trend of data access intensity. After calculation by this model, the system generates a smoothed access intensity prediction value for each monitored data item.

[0035] The predicted access intensity values ​​are processed using a linear extrapolation algorithm to generate the access trend parameters.

[0036] It should be noted that, in order to make predictions about the future, the system uses a linear extrapolation algorithm to process this predicted access intensity value. The linear extrapolation algorithm simply and quickly extends the prediction to a very short time window in the future based on the rate of change of a series of recent smoothed values, thereby generating an access trend parameter that quantifies future access pressure.

[0037] One embodiment provides a method for calculating the access trend parameter, as follows: The predicted access intensity values ​​for the past 10 minutes are obtained through multi-dimensional data collection, at 32, 38, 45, 53, 61, 68, 75, 82, 89, 95, 102, and 110 times / 15 seconds respectively. A linear extrapolation algorithm is used, and the slope is calculated from the five most recent predicted values: (110-82) / ((5-1)×15 seconds) = 28 / 60 ≈ 0.47 times / second. Based on this slope, the access intensity change for the next 30 seconds is extrapolated, resulting in an access trend parameter that the access intensity will increase by approximately 14 times in the next 30 seconds, at an increase rate of 0.47 times / second, which is used for subsequent comparison with potential hotspot thresholds.

[0038] When the access trend parameter exceeds the preset potential hotspot threshold, the predicted hotspot data is marked.

[0039] Furthermore, the system-generated access trend parameters are compared with a preset potential hotspot threshold. This threshold represents a critical point of access growth that needs to be monitored in advance. Once the access trend parameter of a data item exceeds this threshold, the system marks it as a predicted hotspot data identifier and outputs it along with the corresponding access trend parameter as the basis for subsequent migration decisions.

[0040] In one embodiment, taking an e-commerce distributed caching system as an example, a hotspot threshold is set using a combination of a base threshold and dynamic adjustment. First, the average access intensity of each data item during non-promotional periods over the past three months is statistically analyzed. For example, if it's 20 times / 10 seconds, this is tripled to 60 times / 10 seconds and set as the initial base threshold. Then, dynamic adjustments are made based on the real-time status dataset: if the node's CPU utilization exceeds 60% or memory usage exceeds 70%, the threshold is lowered by 10% to 54 times / 10 seconds; if the link latency is less than 15ms and available bandwidth is sufficient, the threshold is increased by 5% to 63 times / 10 seconds. For example, if the access trend parameter for a certain product's data is 85 times / 10 seconds, exceeding the current adjusted threshold of 63 times / 10 seconds, it is marked as predicted hotspot data.

[0041] Please see Figure 4 As shown, based on the predicted hotspot data identifier and access trend parameters, a migration cost simulation operation is performed on the candidate target node set to generate the instantaneous processing capacity score change of the node and the predicted link load value, and to determine the optimal migration target node.

[0042] In a preferred embodiment of the present invention, the specific method for performing the migration cost simulation operation is as follows: a simulated migration environment is constructed for each candidate target node.

[0043] It should be noted that building a simulated migration environment for each candidate target node involves creating a virtual exercise scenario with the same hardware configuration and current load status as the node, without affecting its actual business operations. First, the candidate node's real hardware parameters and real-time load data are copied to simulate its actual operating foundation. Then, the actual data volume, data structure, and corresponding access trend parameters of the predicted hotspot data are imported. Finally, the complete data migration process is reproduced in the environment to accurately calculate the impact of migration on the candidate node's resource consumption, processing capacity, and link load, providing a reliable basis for subsequent target node selection.

[0044] Load the data volume and access trend parameters corresponding to the predicted hotspot data identifier in the simulated migration environment.

[0045] The calculation of the input / output resource consumption and CPU overhead increase generated during the data loading process.

[0046] The incremental overhead of the central processing unit is corrected by combining the node hardware difference factor, and a score of the instantaneous processing capability of the node after simulated loading is generated.

[0047] It should be noted that the hardware difference factor is a coefficient used to quantify the hardware performance differences among different candidate target nodes and to correct the CPU overhead increment calculation results. Its core purpose is to eliminate the bias caused by different hardware configurations leading to different actual load capacities under the same overhead increment. Its value is determined based on the node's key hardware parameters: CPU performance is taken first, followed by memory bandwidth and I / O interface speed. The more powerful the node, the closer the factor is to 1; the weaker the node, the larger the factor. This ensures that the corrected CPU overhead increment accurately reflects the node's actual load pressure, providing a precise basis for subsequent processing capacity scoring.

[0048] One method for setting node hardware difference factors involves: first, screening candidate nodes with different hardware configurations in the distributed caching system, covering differences in key hardware dimensions such as CPU core count, memory capacity, and network card bandwidth. Simulating the same hot data migration scenario on each node, including loading the same scale of hot data and simulating consistent access trends, recording core resource consumption indicators such as the increase in CPU overhead for each node during data loading. Using the node with the best hardware performance as a benchmark, its hardware difference factor is set to 1. Then, the final hardware difference factor for each node is determined based on the resource consumption difference ratio between other nodes and the benchmark node.

[0049] For example, the corrected CPU overhead increment is equal to the product of the node hardware difference factor and the CPU overhead increment.

[0050] In one embodiment, taking candidate nodes Node1 and Node2 in an e-commerce caching system as examples, the initial instantaneous processing capability scores of both nodes are first obtained: Node1 scores 85 points, and Node2 scores 78 points. A simulated loading of hot data is performed, and the initial CPU overhead increment for both nodes is calculated to be 15%. Hardware difference factor correction is applied: Node1 is a 32-core server with a corresponding hardware difference factor of 1, resulting in a corrected overhead of 15%; Node2 is a 16-core server with a corresponding hardware difference factor of 1.2, resulting in a corrected overhead of 18%. The score after simulated loading is calculated as: initial score - corrected CPU overhead increment, meaning 1 point is deducted for every 1% overhead. Node1 scores 70 points, and Node2 scores 60 points. This score directly reflects the actual processing capability of the nodes after loading hot data.

[0051] It should be noted that, in order to cope with the hardware heterogeneity that is common in distributed systems, the system introduces a key node hardware difference factor. This factor quantifies the difference in processing capabilities of different nodes and is used to correct the CPU overhead increment calculated above, thereby obtaining a simulated instantaneous processing capability score of the node after loading that better reflects the node's true capacity.

[0052] The instantaneous processing capability score of the node after the simulated loading is compared with the initial instantaneous processing capability score of the node to generate the change in the instantaneous processing capability score of the node.

[0053] For example, the change in the node instantaneous processing capability score is equal to the difference between the node instantaneous processing capability score after the simulated loading and the initial node instantaneous processing capability score.

[0054] Assess the bandwidth consumption of the migrated data and predict the increase in access traffic to generate the predicted link load value.

[0055] For example, first, the bandwidth consumption of the migrated data is calculated. Based on the predicted total amount of hot data, the size of the data chunks, and the transmission time, combined with the data transmission protocol overhead, the average bandwidth consumption during the migration period is calculated. Next, the increase in access traffic is predicted. Based on access trend parameters, the increase in access traffic on the link after the migration is calculated. Finally, the two are combined with the current actual bandwidth usage of the link to generate a predicted link load value. This value is used to assess whether the link will experience congestion due to the migration and subsequent access.

[0056] It's important to note that by performing cost simulations before making decisions, the system can anticipate the potential chain reactions that might occur after migrating hot data to a specific node. These reactions include the impact on the node's own computing and storage resources, as well as the pressure on network links. In particular, the introduction of node hardware difference factors allows the decision-making process to intelligently adapt to hardware with different performance levels, avoiding the incorrect allocation of heavy loads to weaker nodes. This simulation not only evaluates the steady-state load after migration but also the instantaneous overhead of the migration process itself. This allows for the selection of a target node that can stably handle future hotspot access while completing the migration process at minimal cost. This effectively avoids secondary hotspots or system instability caused by improper decision-making, significantly improving the rationality of resource utilization and the overall stability of the system.

[0057] In a preferred embodiment of the present invention, the specific method for determining the optimal migration target node is as follows: calculate the node stability index of each candidate target node, wherein the node stability index is determined by the difference between the instantaneous processing capability score change of the node and a preset bottleneck threshold.

[0058] It's important to explain that the bottleneck threshold setting is based on historical system data and real-time node status. The specific threshold setting process is as follows: First, during the past three months of normal system operation, the minimum processing capacity score of each node that has not experienced congestion and can stably carry services is calculated, and the average score is used as the initial baseline for the bottleneck threshold. Next, the status of candidate nodes and link conditions are monitored in real time. If a node's memory utilization exceeds 70% or the available bandwidth of its link is less than 20%, it indicates a decrease in the node's load-bearing capacity. In this case, the initial baseline threshold should be increased by 5% to prevent the node from quickly becoming a bottleneck after loading hot data due to insufficient load capacity. If the node's CPU idle rate exceeds 40% and the link latency is less than 15ms, it indicates sufficient node redundancy resources, and the initial baseline threshold can be decreased by 5% to fully utilize the node's idle resources and reduce unnecessary migration operations. After adjustment, a final bottleneck threshold that fits the node's real-time load capacity potential is obtained, which is used to determine whether the node will become a new bottleneck after loading hot data.

[0059] Calculate the link stability index, which is determined by the ratio of the predicted link load to a preset bandwidth capacity.

[0060] It should be noted that the bandwidth capacity setting is based on the physical upper limit of the link hardware and the system's service requirements. First, based on the hardware specifications of the inter-node communication link, its actual stable transmission bandwidth value is taken as the basic reference value. Second, combined with the maximum actual bandwidth occupied by the link during historical peak service periods, a certain amount of redundant bandwidth is reserved to cope with sudden traffic surges. Finally, considering both hardware potential and service redundancy requirements, the preset bandwidth capacity is determined, providing a benchmark for calculating the link stability index.

[0061] It should be noted that the link stability index reflects the network smoothness of the migration path after it has carried data migration and subsequent access traffic. The higher the index, the lower the risk of network link congestion.

[0062] The node stability index and the link stability index are weighted and summed, and the candidate target node with the largest result is selected as the optimal migration target node.

[0063] It should be noted that because node processing capacity directly determines the stability of subsequent services for hot data, node stability is typically assigned a higher weight, such as 0.6. Link stability affects migration efficiency and subsequent access latency, and is assigned a slightly higher weight, such as 0.4. The weights can be fine-tuned based on the system's priority requirements for node performance or link quality. The node with the largest weighted sum is selected as the optimal migration target node. This node can stably handle hot data while ensuring smooth data migration and subsequent access, achieving optimal overall system performance.

[0064] A target buffer is created at the optimal migration target node, and an asynchronous data preloading operation is performed. When the asynchronous data preloading operation is completed, a source sub-routes switching operation is triggered to direct new read requests to the target buffer.

[0065] It's important to explain that the source sub-routing switch operation is a crucial step in the hot data migration process of the distributed caching system. Its main purpose is to accurately direct new read requests to the target buffer without affecting normal system operation and data request processing, ensuring a smooth transition during data migration. The source sub-routing switch operation is executed by a central routing controller or distributed coordination service. Upon receiving a signal indicating the asynchronous data preloading is complete, this controller or service immediately updates the routing table or naming service record in the distributed caching system. This operation is triggered based on the completion of asynchronous data preloading, ensuring timely route switching when the target buffer is ready to receive data requests. During the route switching, all established old connections pointing to the source node continue processing their current requests until completion, while all new connections and requests for predicted hot data arriving after the switch are directly directed to the target buffer. This approach ensures that ongoing requests are unaffected by the route switching, while new requests are quickly and accurately directed to the new target buffer, maintaining normal system operation and the continuity of data access.

[0066] In a preferred embodiment of the present invention, the specific method of performing the asynchronous data preloading operation is as follows: after the target buffer is created at the optimal migration target node, the target buffer is configured as a temporary storage area capable of independently receiving and storing predicted hotspot data. The asynchronous data preloading operation starts an independent background thread or process, which is responsible for reading the predicted hotspot data from the source node in parallel.

[0067] The parallel read operation adopts a block transmission mechanism, which divides the predicted hot spot data into multiple small data blocks and uses multiple concurrent connections or remote direct memory access technology to efficiently transmit the data blocks.

[0068] When the asynchronous data preloading operation is executed on the source node, it ensures that the normal read and write request processing of the source node does not have a visibility impact or performance degradation.

[0069] The completion criteria for the asynchronous data preloading operation include: all predicted hot spot data blocks have been successfully transmitted and written to the target buffer, and have undergone preliminary data integrity verification.

[0070] For example, the data integrity verification process is as follows: For each data block transmitted in a segment, a checksum, such as an MD5 hash, is calculated at the source node and transmitted along with the data block. After receiving the data block, the target buffer recalculates the checksum using the same algorithm and compares it with the checksum transmitted from the source node. If the checksums of all data blocks match, the data is deemed undamaged. Simultaneously, the total number of received data blocks is compared with the preset total number of segments to confirm that no data blocks are missing. This completes the initial integrity verification, providing data reliability assurance for triggering atomic routing switching.

[0071] When preloading is complete, a completion signal is sent, triggering the source sub-route switching operation.

[0072] In a preferred embodiment of the present invention, the source sub-routing switching operation is specifically performed as follows: the source sub-routing switching operation is executed by a central routing controller or a distributed coordination service. After receiving the asynchronous data preloading completion signal, the controller or service will immediately update the routing table or naming service record in the distributed caching system, and resolve the target of all new read requests for predicted hot data from the source node to the target buffer on the optimal migration target node.

[0073] During the routing switch, all established old connections to the source node continue to process their current requests until completion, while all new connections and requests for predicted hotspot data arriving after the switch are directly directed to the target buffer.

[0074] The source sub-route switching operation also includes publishing a route update notification, enabling all clients or proxy services to promptly detect the new access path for hot data and refresh their locally cached route information to ensure the correct routing of subsequent requests.

[0075] The source buffer is retained in the source node to handle read and write requests before the switch. The write operations during the operation of the target buffer and the updated data in the source buffer are performed in the background for incremental synchronization to generate the final target buffer.

[0076] In a preferred embodiment of the present invention, the specific method for performing the background incremental synchronization operation is as follows: capturing the write operation log generated during the operation of the target buffer.

[0077] Real-time monitoring of data update records in the source buffer.

[0078] The write operation log and data update record are merged into an incremental synchronization dataset.

[0079] The incremental synchronization dataset is transmitted to the optimal migration target node in batches according to a preset time period.

[0080] Preferably, after the new read request is switched to the target buffer of the optimal migration target node, the system starts background incremental synchronization operations in parallel to ensure eventual data consistency and prepare for subsequent write request switching.

[0081] This operation first monitors two data sources in parallel. On one hand, the system captures any write operation logs that may be generated during the operation of the target buffer. These logs record a small number of write requests that may be directed to the target node under the new route. On the other hand, the system monitors the source buffer on the source node, which is still processing the vast majority of write requests, in real time and accurately records all data update records, which include all modifications that occurred during this transition.

[0082] Subsequently, the system merges and sorts the change information collected from these two sources—the write operation log and the data update record—to form a unified incremental synchronization dataset containing all incremental changes. To improve network transmission efficiency and reduce interference with the system, the system does not send these changes one by one. Instead, it packages the accumulated incremental synchronization datasets during a preset time period and periodically transmits them to the optimal migration target node. The target node receives and applies the data, thereby gradually catching up with the data differences from the source node.

[0083] It's important to note that the preset time batch is a standard time interval set for periodically transmitting incremental synchronization datasets during background incremental synchronization operations to balance data consistency and system performance. Its core purpose is to avoid excessive resource consumption from high-frequency transmissions or excessive data discrepancies from low-frequency transmissions. The setting should be based on the business scenario: if the system has a high volume of write requests, a short interval should be set to reduce data synchronization lag; if write requests are less frequent, a longer interval can be used. In actual execution, the system packages and transmits the accumulated write operation logs and data update records within the set interval, ensuring timely synchronization of incremental data while reducing the continuous consumption of node CPU and network resources, thus supporting efficient background incremental synchronization.

[0084] In a preferred embodiment of the present invention, a traffic coordination control operation is further included, which is specifically analyzed as follows: During the execution of the background incremental synchronization operation, the real-time load difference between the source node and the target node is dynamically calculated.

[0085] The write request allocation weights for the source and target nodes are adjusted based on the real-time load difference.

[0086] When the completion rate of the background incremental synchronization operation reaches a preset stage threshold, the write request allocation weight of the target node is linearly increased.

[0087] For example, the incremental synchronization completion rate in the background refers to the proportion of incremental data that has been synchronized to the target node to the total incremental data to be synchronized between the source and target nodes. The preset stage threshold is a pre-set progress node, which can be set according to the business requirements for data consistency.

[0088] Preferably, the preset stage threshold is 50%, 75%, or 90%.

[0089] When the completion rate exceeds a certain threshold, the system increases the weight of write requests allocated to the target node according to a preset linear rule. For example, when the completion rate reaches 50%, the weight increases linearly from 10% to 30%; when it reaches 75%, it increases to 60%, ultimately achieving coordinated advancement of data synchronization and traffic migration to ensure a smooth switchover.

[0090] It's important to further explain that the core of traffic coordination control is dynamically adjusting the ratio of write traffic sent to the source and target nodes. The system continuously and in real-time monitors the load status of the source and target nodes and calculates the real-time load difference between them by comparing their key performance indicators. Based on this difference, the system dynamically adjusts the weighting of write requests. If the target node has a low load, its write request weight can be appropriately increased, and vice versa. This is a reactive adjustment mechanism.

[0091] Meanwhile, the system also employs a proactive strategy that monitors the completion rate of background incremental synchronization operations, i.e., the proportion of synchronized data to the total data to be synchronized. The system presets several stage thresholds, such as 50%, 75%, and 90% synchronization completion. Whenever the completion rate of background incremental synchronization operations exceeds a preset stage threshold, the system proactively and linearly increases the write request allocation weight assigned to the optimal migration target node. This means that as the data gap narrows, the target node will systematically and gradually take on more write traffic.

[0092] Please see Figure 2 As shown, when the background incremental synchronization operation is completed, the request is switched to generate the final target buffer and the source buffer is cleared. The actual migration process indicator data is collected and fed back to the lightweight trend prediction operation and migration cost simulation operation.

[0093] In a preferred embodiment of the present invention, the specific content of the feedback to the lightweight trend prediction operation and migration cost simulation operation is as follows: extract the actual migration time, node resource fluctuation amplitude and prediction deviation value to generate a feedback training dataset.

[0094] The smoothing coefficient of the lightweight trend prediction operation is updated using the feedback training dataset.

[0095] For example, key metrics are extracted from the feedback training dataset, including actual migration time, node resource fluctuation amplitude, and the deviation between the predicted access intensity and the actual access volume. If the deviation remains positive, it indicates that the original smoothing coefficient is not sensitive enough to recent access data, and the coefficient needs to be increased by 0.05 to make the model focus more on recent data to capture access growth trends. If the deviation remains negative, the coefficient is decreased by 0.05 to reduce the weight of recent data and smooth out excessive fluctuations. After adjustment, the effect is verified using the predicted deviation value of the next migration. If the deviation value returns to within acceptable limits, the current coefficient is maintained; if it still exceeds the range, the above adjustment process is repeated until the coefficient adapts to the current access trend.

[0096] The parameters of the resource consumption calculation model for the migration cost simulation operation are revised.

[0097] For example, key comparative data can be extracted from the feedback training dataset, such as a predicted CPU overhead increase of 20% during simulation compared to an actual increase of 25%, or a simulated I / O bandwidth consumption of 100MB / s compared to an actual consumption of 115MB / s, to clarify the direction and magnitude of parameter deviations. Next, the model parameters that need correction can be identified. If the predicted CPU overhead remains consistently low, the CPU resource consumption coefficient can be adjusted to better reflect the actual computational cost of the hardware. If the predicted I / O bandwidth consumption has a large deviation, the proportion of data transmission protocol overhead can be adjusted to account for more protocol losses in actual transmission.

[0098] Furthermore, once a complete hotspot data migration process is completed, the system immediately initiates a feedback process to achieve self-optimization, specifically including:

[0099] The system will extract the actual execution effect data of this migration, including the precise time recorded from the start to the end of the migration, as the actual migration time.

[0100] Analyze the performance monitoring logs of the source node and the optimal migration target node during the migration period, and calculate the difference between the maximum peak and the average value of resource usage as the node resource fluctuation range.

[0101] The system compares the prediction results generated by the cost simulator before migration with the actual observed fluctuations in node resources and network traffic, and calculates the difference between the two. This difference is the prediction deviation value.

[0102] The system combines the actual migration time, node resource fluctuation range, and prediction deviation into a structured data record and stores this record in the feedback training dataset.

[0103] The system uses feedback training datasets to iteratively optimize its core model. On one hand, it adjusts the smoothing coefficient of the exponential smoothing model used in the lightweight trend prediction operation; if the prediction bias indicates that the prediction is too lagging, the smoothing coefficient is increased to improve sensitivity to new data. On the other hand, it corrects the resource consumption calculation model parameters in the migration cost simulation operation; for example, if the actual node resource fluctuations are always higher than the predictions, the system will correspondingly increase the estimation coefficients for computation or I / O consumption in the model.

[0104] The above content is merely an example and illustration of the concept of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described, or use similar methods to replace them, as long as they do not deviate from the concept of the invention or exceed the scope defined by the present invention, and all such modifications and additions should fall within the protection scope of the present invention.

Claims

1. A method for dynamic hot data migration in a distributed caching system, characterized in that: The method comprises the following steps: Real-time acquisition of multi-dimensional running state data of each node in the distributed cache system generates real-time state data set, performs lightweight trend prediction operation and outputs predicted hot data identifier and corresponding access trend parameter; According to the predicted hot data identifier and access trend parameter, the migration cost simulation operation is performed on the candidate target node set to generate the node instantaneous processing capacity score change and the link load prediction value, and the optimal migration target node is determined; Create a target buffer in the optimal migration target node, perform an asynchronous data preloading operation, and trigger a source sub-routing switching operation to direct new read requests to the target buffer when the asynchronous data preloading operation is completed; Reserve the source buffer in the source node, process the read request and the write request before switching, and perform a background incremental synchronization operation on the write operation during the operation of the target buffer and the update data of the source buffer to generate a final target buffer; When the background incremental synchronization operation is completed, switch the request to the final target buffer and clear the source buffer, collect actual migration process index data and feed back to the lightweight trend prediction operation and migration cost simulation operation. 2.The dynamic hot data migration method of a distributed cache system according to claim 1, characterized in that: The specific acquisition method of the multi-dimensional running state data is as follows: Collect real-time access frequency change rate, access source distribution characteristics and read-write request proportion parameters of each data item; Monitor the central processor utilization rate, memory occupancy rate, input-output waiting queue depth and network transceiver queue depth of each node; Obtain link delay parameters and available bandwidth parameters between nodes; Combine the access frequency change rate, access source distribution characteristics, read-write request proportion parameters, central processor utilization rate, memory occupancy rate, input-output waiting queue depth, network transceiver queue depth, link delay parameters and available bandwidth parameters to generate the real-time state data set.

3. The dynamic hot data migration method of a distributed cache system according to claim 2, characterized in that: The specific way of performing lightweight trend prediction operation is as follows: Input the real-time state data set into the preset exponential smoothing model to calculate the access intensity prediction value in the future time window; Generate the access trend parameter by processing the access intensity prediction value through linear extrapolation algorithm; When the access trend parameter exceeds the preset potential hot spot threshold, mark the predicted hot data identifier.

4. The dynamic hot data migration method of a distributed cache system according to claim 1, characterized in that: The specific way of performing migration cost simulation operation is as follows: Build a simulation migration environment for each candidate target node; Load the data volume corresponding to the predicted hot data identifier and the access trend parameter in the simulation migration environment; Calculate the input-output resource consumption and central processor overhead increment generated during data loading process; Combine the node hardware difference factor to correct the central processor overhead increment to generate the simulated post-loading node instantaneous processing capacity score; Compare the simulated post-loading node instantaneous processing capacity score with the initial node instantaneous processing capacity score to generate the node instantaneous processing capacity score change; Evaluate the migration data bandwidth consumption and predicted access traffic increment to generate the link load prediction value.

5. The dynamic hot data migration method of a distributed cache system according to claim 4, characterized in that: The specific way of determining the optimal migration target node is as follows: Calculate the node stability index of each candidate target node, which is determined by the difference between the node instantaneous processing capacity score change and the preset bottleneck threshold; calculating a link stability index determined by a ratio of the link load prediction value to a preset bandwidth capacity; performing weighted summation on the node stability index and the link stability index, and selecting the candidate target node with the largest result as the optimal migration target node.

6. The dynamic hot data migration method of a distributed cache system according to claim 1, characterized in that: The specific manner of performing the asynchronous data preloading operation is as follows: After the optimal migration target node creates the target buffer, the target buffer is configured as a temporary storage area capable of independently receiving and storing predicted hot data, and the asynchronous data preloading operation starts an independent background thread or process responsible for parallel reading of the predicted hot data from the source node; The parallel reading operation adopts a block transmission mechanism, divides the predicted hot data into multiple small data blocks, and uses multiple concurrent connections or a remote direct memory access technology to efficiently transmit the data blocks; When the asynchronous data preloading operation is performed on the source node, it ensures that the normal read-write request processing of the source node does not have a visible impact or performance degradation; The completion criteria of the asynchronous data preloading operation include that all predicted hot data blocks have been successfully transmitted and written to the target buffer, and have passed preliminary data integrity verification; When the preloading is completed, a completion signal is sent to trigger the source sub-route switching operation.

7. The dynamic hot data migration method of a distributed cache system according to claim 1, characterized in that: The specific manner of the source sub-route switching operation is as follows: The source sub-route switching operation is performed by a central route controller or a distributed coordination service, and after receiving the asynchronous data preloading completion signal, the controller or service immediately updates the routing table or naming service record in the distributed cache system, and points all new read requests for predicted hot data to the target buffer on the optimal migration target node; During the route switching, all established old connections pointing to the source node continue to process their current requests until completion, while all new connections and new requests for predicted hot data arriving after the switching time are directly directed to the target buffer; The source sub-route switching operation also includes issuing a route update notification to enable all clients or proxy services to timely perceive the new access path of hot data and refresh their locally cached routing information to ensure correct guidance of subsequent requests.

8. The dynamic hot data migration method of a distributed cache system according to claim 1, characterized in that: The specific manner of performing the background incremental synchronization operation is as follows: Capturing the write operation log generated during the operation of the target buffer; Real-time monitoring of data update records of the source buffer; Combining the write operation log and the data update record into an incremental synchronization data set; Transmitting the incremental synchronization data set to the optimal migration target node in batches according to a preset time.

9. The dynamic hot data migration method of a distributed cache system according to claim 8, characterized in that: It also includes a traffic coordination control operation, which is analyzed as follows: During the execution of the background incremental synchronization operation, the real-time load difference between the source node and the target node is dynamically calculated; Adjusting the write request allocation weight of the source node and the target node according to the real-time load difference; When the completion degree of the background incremental synchronization operation reaches a preset stage threshold, the write request allocation weight of the target node is linearly increased.

10. The dynamic hot data migration method of a distributed cache system according to claim 1, characterized in that: The feedback to the lightweight trend prediction operation and the migration cost simulation operation is as follows: Extract the actual migration time consumption, node resource fluctuation amplitude and prediction deviation value to generate a feedback training data set; Update the smoothing coefficient of the lightweight trend prediction operation by using the feedback training data set; Correct the resource consumption calculation model parameters of the migration cost simulation operation.

Images