Data synchronization method and device based on Linux system

Abstract

The embodiment of the invention relates to the technical field of computers, and discloses a data synchronization method and device based on a Linux system, and the method comprises the steps: obtaining a transmission delay value when a target data block in the Linux system is transmitted between target hardware components; comparing the transmission delay value with a transmission delay threshold value to obtain a delay comparison result; if the delay comparison result represents that the transmission delay value is greater than the transmission delay threshold value, performing data synchronization verification on the target data block; and if the data synchronization verification fails, adjusting the working frequency of the target hardware component, and performing data synchronization verification on the target data block based on the adjusted working frequency. By applying the technical scheme of the invention, the data synchronization efficiency and reliability of the linux system can be improved.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of computer technology, and particularly to a data synchronization method and apparatus based on the Linux system. Background Art

[0002] With the rapid development of information technology, as an open-source operating system, the Linux system has been widely applied in multiple fields such as servers, embedded devices, and personal computers. However, due to the difference in signal transmission speeds between different hardware modules in the Linux system, there are often problems of low data synchronization efficiency when dealing with high-concurrency or large-scale data transmission tasks. Summary of the Invention

[0003] In view of the above problems, embodiments of the present invention provide a data synchronization method and apparatus based on the Linux system.

[0004] According to one aspect of the embodiments of the present invention, there is provided a data synchronization method based on the Linux system, which is applied to the Linux system. The method includes: obtaining a transmission delay value when a target data block is transmitted between target hardware components in the Linux system; comparing the transmission delay value with a transmission delay threshold to obtain a delay comparison result; if the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, performing data synchronization verification on the target data block; if the data synchronization verification fails, adjusting the working frequency of the target hardware component, and performing data synchronization verification on the target data block based on the adjusted working frequency. Through the above process, the data synchronization efficiency and reliability of the Linux system can be improved.

[0005] In an optional embodiment, obtaining the transmission delay threshold includes:

[0006] obtaining historical transmission delay values of the target hardware component within a target time period;

[0007] performing statistical analysis on the historical transmission delay values to obtain a statistical delay value of the target hardware component;

[0008] determining the transmission delay value based on the statistical delay value and the delay standard deviation.

[0009] In an optional embodiment, obtaining the transmission delay threshold further includes:

[0010] determining an initial transmission delay value of the target hardware component based on the statistical delay value and the delay standard deviation;

[0011] obtaining the load value of the Linux system at the current moment;

[0012] determining the transmission delay threshold based on the load value and the initial transmission delay value.

[0013] In an alternative embodiment, obtaining the transmission delay threshold further includes:

[0014] Obtaining the confirmation information fed back by the target hardware component based on the heartbeat signal;

[0015] If the confirmation information is abnormal, determining the transmission delay threshold based on the feedback information of the target hardware component for the test data packet.

[0016] In an alternative embodiment, if the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, the method further includes:

[0017] Obtaining an alternative transmission path for the target data block;

[0018] Based on the alternative hardware component corresponding to the alternative transmission path, performing pre-synchronization processing on the target data block, and after the pre-synchronization processing is successful, performing the step of performing data synchronization verification on the target data block.

[0019] In an alternative embodiment, if the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, the method further includes:

[0020] Calculating a first delay difference between the transmission delay value and the transmission delay threshold;

[0021] Adjusting the transmission priority of the target hardware component based on the first delay difference to preferentially process data blocks with larger transmission delays; or,

[0022] Adjusting the size of the target data block based on the first delay difference and the corresponding data block adjustment factor, and after the adjustment is completed, performing the step of performing data synchronization verification on the target data block.

[0023] In an alternative embodiment, if the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, the method further includes:

[0024] Obtaining the consecutive transmission delay times of the target hardware component;

[0025] If the consecutive transmission delay times are greater than the delay times threshold, marking the target hardware component as a potential failure component;

[0026] Obtaining the original kernel module corresponding to the target hardware component, and scheduling the transmission task of the target data block to the target kernel module based on process affinity.

[0027] In an alternative embodiment, after obtaining the transmission delay value when the target data block is transmitted between target hardware components in the Linux system, the method further includes:

[0028] Calculating the average transmission delay of the target hardware component;

[0029] If the average transmission delay is greater than the system average transmission delay, and the second delay difference between the average transmission delay and the system average transmission delay is greater than the target error value, the task load of the target hardware component is adjusted, and the target error value is determined based on the load value of the Linux system.

[0030] In an alternative embodiment, if the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, the method further includes:

[0031] Obtain the duration during which the transmission delay value continuously exceeds the transmission delay threshold;

[0032] Determine the alarm level corresponding to the current transmission delay based on the duration;

[0033] Determine the verification method for data synchronization verification of the target data block based on the alarm level.

[0034] According to another aspect of the embodiments of the present invention, a data synchronization device based on the Linux system is provided, including: a data acquisition module for acquiring the transmission delay value when the target data block in the Linux system is transmitted between target hardware components; a delay comparison module for comparing the transmission delay value with the transmission delay threshold to obtain a delay comparison result; a synchronization verification module for performing data synchronization verification on the target data block if the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold; a data synchronization module for adjusting the working frequency of the target hardware component if the data synchronization verification fails, and performing data synchronization verification on the target data block based on the adjusted working frequency. Through the above modules, the data synchronization efficiency and reliability of the Linux system can be improved.

[0035] According to another aspect of the embodiments of the present invention, a computer device is provided, including: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface complete communication with each other through the communication bus; the memory is used to store at least one executable instruction, and the executable instruction causes the processor to execute the operations of the foregoing data synchronization method based on the Linux system.

[0036] According to yet another aspect of the embodiments of the present invention, a computer-readable storage medium is provided, in which at least one executable instruction is stored, and the executable instruction causes a computer device / device to execute the operations of the foregoing data synchronization method based on the Linux system.

[0037] According to yet another aspect of the embodiments of the present invention, a computer program product is provided, including computer instructions for causing a computer to execute the operations of the data synchronization method based on the Linux system in the first aspect or any corresponding embodiment thereof.

[0038] The above description is only an overview of the technical solution of the embodiment of the present invention. In order to be able to understand the technical means of the embodiment of the present invention more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features and advantages of the embodiment of the present invention more obvious and understandable, the following specifically illustrates the specific implementation manners of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The drawings are only used to illustrate the embodiments and are not considered as a limitation to the present invention. Moreover, throughout the drawings, the same reference numerals are used to represent the same components. In the drawings:

[0040] Figure 1 shows a schematic flowchart of a data synchronization method provided by the present invention based on the Linux system;

[0041] Figure 2 shows a schematic structural diagram of a data synchronization device provided by the present invention based on the Linux system;

[0042] Figure 3 shows a schematic structural diagram of a computer device provided by the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0043] In order to make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0044] Figure 1 shows a flowchart of the first embodiment of a data synchronization method provided by the present invention based on the Linux system, which is applied to the Linux system. As Figure 1 shown, the method includes the following steps:

[0045] Step 110, obtain the transmission delay value when the target data block is transmitted between the target hardware components in the Linux system.

[0046] As above, by obtaining the transmission delay value when the target data block is transmitted between the target hardware components in the Linux system, a benchmark can be provided for subsequent data synchronization verification, and the accuracy of the transmission delay value is crucial for judging the data transmission efficiency and potential problems.

[0047] Specifically, when obtaining the transmission delay value during the transmission of the target data block between target hardware components in the Linux system, the signal transmission speeds between each hardware component can be accurately measured and recorded first, and then a transmission delay model can be constructed based on the signal transmission speeds between each hardware component. Through this transmission delay model, dynamic verification and synchronization can be performed during data transmission to ensure that the data transmission between different components is consistent. For example, the clocks of each component can be synchronized through the Network Time Protocol (NTP), and then necessary delay adjustments can be made according to the pre-built transmission delay model. This can ensure that when repairing the Linux system failure, the data read and write operations of each storage device can be strictly carried out in accordance with the predetermined time sequence, avoiding the occurrence of data inconsistency.

[0048] In some alternative embodiments, when determining the transmission delay threshold, the historical transmission delay values of the target hardware component within the target time period can be obtained first; then, statistical analysis can be performed on the historical transmission delay values to obtain the statistical delay value and delay standard deviation of the target hardware component. Finally, based on the statistical delay value and delay standard deviation, the transmission delay value can be determined; the statistical analysis can include calculating statistical quantities such as the average value, median, and mode of the historical transmission delay values, as well as calculating the distribution characteristics of these statistical quantities, such as variance and standard deviation. The statistical delay value reflects the average transmission performance of the target hardware component within the target time period, while the delay standard deviation reveals the degree of fluctuation of the transmission delay. By combining the statistical delay value and delay standard deviation, the transmission delay threshold can be set more accurately. This threshold can dynamically adapt to the changes in the transmission performance of the target hardware component, improving the flexibility and accuracy of data synchronization.

[0049] Specifically, the formula for determining the transmission delay value based on the statistical delay value and delay standard deviation is: T_max = μ + kσ, where μ is the average value of the transmission delay, σ is the delay standard deviation of the transmission delay, and k is a coefficient, usually taking 3 to ensure that the transmission delay is within the normal range in most cases. For example, by collecting multiple groups of data and calculating μ = 10 microseconds and σ = 2 microseconds, then T_max = 10 + 3 * 2 = 16 microseconds.

[0050] Compare the actual transmission delay value D with the transmission delay threshold T_max. If the actual transmission delay value is greater than the transmission delay threshold T_max, a data synchronization check is triggered. This comparison operation is used to determine whether the current transmission delay is within the normal range. If the actual transmission delay value D is greater than the transmission delay threshold T_max, it indicates that there may be an abnormality or failure, and further data synchronization checks are required. Specifically, assume that the actual transmission delay measurement of a certain I / O device is 18 microseconds, which is greater than 16 microseconds of T_max. At this time, the system will automatically trigger a data synchronization check for this I / O device to ensure data consistency.

[0051] In some alternative embodiments, when determining the transmission delay threshold, the acknowledgment information feedback by the target hardware component based on the heartbeat signal may also be considered. If the acknowledgment information is abnormal, it may indicate that there is a problem with the hardware component itself. At this time, the transmission delay threshold can be determined based on the feedback information of the target hardware component on the test data packet, which can provide a reliable basis for subsequent data synchronization verification, thereby improving the efficiency and reliability of data synchronization.

[0052] Specifically, the transmission delay threshold T_max can also be updated regularly to continuously adjust the transmission delay threshold T_max, which is used to determine the upper limit value for judging whether the transmission delay is normal, during the operation of the system according to the actual environmental changes. For example, the transmission delay threshold T_max can be dynamically calculated based on historical data over a period of time. Usually, the initial value is set to 0.5 milliseconds, and the range can vary from 0.1 millisecond to 2 milliseconds. The optimal value needs to be determined according to the actual application environment, and usually, the best value found through multiple tests under a stable operating state is adopted. The purpose of setting this value is to ensure that the transmission delay of the system is within an acceptable range and to avoid affecting the system performance due to excessive transmission delay.

[0053] When the actually measured transmission delay value D is greater than the transmission delay threshold T_max each time, increase the verification frequency so that when it is found that the transmission delay exceeds the standard, verification can be performed more frequently, thereby promptly discovering problems and taking measures. For example, when the transmission delay value D is greater than the transmission delay threshold T_max for the first time, the verification frequency can be increased from once every 10 seconds to once every 5 seconds to capture abnormal situations more quickly. This strategy of dynamically adjusting the verification frequency helps to quickly respond to potential problems without affecting normal operation.

[0054] Adopt the heartbeat signal mechanism to monitor the real-time status of the hardware component to confirm whether the communication between the target hardware components is normal. Specifically, a specific instruction or data packet can be periodically sent, and the receiver immediately sends back an acknowledgment signal after receiving it. If the acknowledgment of the heartbeat signal is not received within the predetermined time, it can be considered that the communication may be abnormal. The sending frequency of the heartbeat signal is usually once per second, and the optimal value is also adjusted according to actual needs. This method is simple and effective and can promptly discover and locate the fault point.

[0055] If the heartbeat signal is abnormal, the transmission delay value D is recalculated immediately. When the abnormal heartbeat signal is detected, it is necessary to re-measure the current transmission delay. The purpose of recalculation is to confirm the current communication status and prevent incorrect operations caused by misjudgment. If the system fails to receive the confirmation of the heartbeat signal three times in a row, the re-measurement process of the transmission delay will be immediately started, including sending a new test data packet and recording the time difference from sending to receiving, and finally obtaining the latest transmission delay value D. In this way, the system can respond quickly and adjust the strategy to ensure the accuracy of data synchronization.

[0056] For example, in a Linux system, the system administrator can monitor the communication status between the system kernel and each peripheral through the above method. If it is found that the transmission delay value is greater than the set transmission delay threshold T_max, the logging frequency can be automatically increased, and the normal communication status can be restored in time by recalculating the transmission delay. This method can not only improve the robustness and reliability of the system, but also effectively reduce the need for manual intervention and improve the maintenance efficiency.

[0057] In some alternative embodiments, when determining the transmission delay threshold, the initial value of the transmission delay of the target hardware component can be determined first based on the statistical delay value and the delay standard deviation; then the load value of the Linux system at the current moment is obtained; finally, based on the load value and the initial value of the transmission delay, the transmission delay value is determined. Such a determination method can comprehensively consider the historical transmission performance and the current load of the system, making the transmission delay threshold more reasonable and better reflecting the actual operating state of the system.

[0058] In specific implementation, the load monitoring tools provided by the system, such as top, htop, etc., can be used to obtain the occupancy of resources such as CPU, memory, and disk I / O of the Linux system in real time, so as to obtain the load value of the system. The size of the load value reflects the current busyness of the system. When the system load is high, the data transmission between hardware components may be affected, resulting in an increase in transmission delay.

[0059] Based on the load value and the initial value of the transmission delay, the formula for determining the transmission delay value can be: T_real = T_init × (1 + L / L_max), where T_real is the actual transmission delay value, T_init is the initial value of the transmission delay, L is the load value of the Linux system at the current moment, and L_max is the maximum tolerance value of the system load. This formula takes into account the impact of system load on transmission delay, and makes the verification of data synchronization more in line with the actual operating state of the system by dynamically adjusting the transmission delay value.

[0060] For example, assume that the initial value of the transmission delay T_init is 10 microseconds, the maximum tolerance value of the system load L_max is 80%, and the current system load value L is 60%. Then the actual transmission delay value T_real = 10×(1 + 0.6 / 0.8) = 12.5 microseconds. Compare this value with the transmission delay threshold T_max. If T_real is greater than T_max, data synchronization check is also triggered, enabling the system to more accurately judge the transmission delay of data, timely detect problems and take measures to ensure the consistency of data among different hardware components. At the same time, it also improves the flexibility and adaptability of data synchronization, enabling the system to maintain stable performance under different load conditions.

[0061] In specific implementation, the formula for determining the transmission delay threshold can also be T_max = a*L + b, where L is the load value, and a and b are constants respectively used to adjust the threshold sensitivity. The load value L usually represents the CPU utilization rate of the system or other resource utilization rates, and its value range is from 0 to 100. The optimal values of the constants a and b need to be determined through experiments. Generally speaking, the value range of a is from 0.1 to 1.0, and the value range of b is from 1 to 10. The specific values of these two parameters depend on the characteristics and performance requirements of the system. When the actual transmission delay value D is greater than the transmission delay threshold T_max, an alarm is triggered, thus reducing the system overhead caused by false alarms, and avoiding the situation where when the system load is high, a slight delay may be due to the system being busy rather than a transmission failure. In addition, the verification strategy can be adjusted according to the alarm level; detailed logs of each transmission delay are recorded for later analysis.

[0062] When the actual transmission delay value D is greater than the transmission delay threshold T_max, an alarm is triggered, ensuring that the system can respond in a timely manner when detecting abnormal transmission delays. For example, when the load value L is 70, a is set to 0.5, and b is set to 5, the calculated result of the transmission delay threshold T_max is 40 milliseconds. When the actual delay D of a data transmission is 50 milliseconds, the system will trigger an alarm, prompting the operation and maintenance personnel to check the network status or component status. Since different alarm levels correspond to different countermeasures, for example, a low-level alarm may only require logging, while a high-level alarm may require immediately starting a backup mechanism or resynchronizing data. Specifically, if the actual delay of a critical service continuously exceeds the transmission delay threshold T_max for 1 minute, the alarm level is set to high, and the system automatically performs data redundancy verification to ensure data consistency. By recording the detailed logs of each transmission delay for later analysis. These logs should include key data such as timestamps, transmission delay values, and information about the hardware components involved. These logs not only help trace historical problems but can also be used to optimize system performance. In one embodiment, whenever the transmission delay is greater than the transmission delay threshold T_max, the system records a log entry containing the above information, and then these logs are imported into an analysis tool to regularly evaluate the overall health status and performance bottlenecks of the system. Through dynamically adjusting the threshold and detailed logging, the system can effectively avoid data inconsistency problems caused by network issues or hardware failures while ensuring high performance.

[0063] Step 120: Compare the transmission delay value with the transmission delay threshold to obtain a delay comparison result.

[0064] As described above, by comparing the transmission delay value with the transmission delay threshold, it is convenient to make subsequent processing decisions based on the obtained delay comparison result. If the delay comparison result indicates that the transmission delay value is less than or equal to the transmission delay threshold, it means that the data transmission status is normal, and no additional data synchronization verification operation is required. The system continues to operate according to the established strategy. Such a design aims to avoid unnecessary verification operations, reduce the consumption of system resources, and improve the overall operation efficiency.

[0065] Step 130: If the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, perform data synchronization verification on the target data block.

[0066] Specifically, if the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, obtain the duration for which the transmission delay value has been continuously greater than the transmission delay threshold. This step is crucial for accurately assessing the severity of the problem. The length of the duration not only reflects the urgency of the data transmission problem but also provides a key basis for determining the subsequent alarm level. Based on the duration, the system further determines the alarm level corresponding to the current transmission delay. The setting of the alarm level comprehensively considers the severity and duration of the transmission delay, aiming to ensure that the operation and maintenance personnel can quickly identify and respond to critical problems. Different levels of alarms correspond to different response strategies, from simple log recording to emergency data synchronization verification and backup mechanisms, to ensure that the system can take appropriate measures in the face of various data transmission problems. After determining the alarm level, the system selects the corresponding data synchronization verification method according to this level. The selection of the verification method aims to verify the integrity and consistency of the data in the most effective way while minimizing the impact on the normal operation of the system. For example, for low-level alarms, the system may only perform a quick data verification operation, while for high-level alarms, a comprehensive data synchronization and redundancy verification process may need to be initiated to ensure the absolute security of the data.

[0067] In some alternative embodiments, if the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, the first delay difference between the transmission delay value and the transmission delay threshold can be further calculated; based on the first delay difference, adjust the transmission priority of the target hardware component to preferentially process the data block with a larger transmission delay; or, in combination with the first delay difference and the corresponding data block adjustment factor, adjust the size of the target data block, and perform the data synchronization verification step of the target data block after the adjustment. Among them, the first delay difference reflects the deviation degree of the current transmission delay relative to the transmission delay threshold and is an important indicator for measuring the severity of the data transmission problem. By calculating the first delay difference, the real-time status of data transmission can be more accurately understood, so as to make a more reasonable adjustment decision. Adjusting the transmission priority can ensure that critical data is preferentially processed when the transmission delay is large, reducing the risk of data inconsistency caused by the transmission delay.

[0068] Specifically, according to the magnitude of the first delay difference, the transmission order of different data blocks can be dynamically adjusted, and those data blocks with larger delays and potentially greater impacts on data consistency are preferentially transmitted. This approach helps to maximize the efficiency and accuracy of data synchronization under limited resources. On the other hand, adjusting the size of the target data block by combining the first delay difference and the corresponding data block adjustment factor is also an effective coping strategy. The size of the data block directly affects the efficiency and reliability of data transmission. In the case of large transmission delays, appropriately reducing the size of the data block can reduce the risk of transmission errors and improve the success rate of data synchronization. The data block adjustment factor is a parameter preset according to system characteristics and performance requirements, which reflects the correlation between data block size adjustment and transmission delay. By comprehensively considering the first delay difference and the data block adjustment factor, the size of the data block can be dynamically adjusted to adapt to different transmission environments and requirements. After adjusting the data block size, perform the data synchronization verification step for the target data block to ensure data integrity and consistency, and through data verification and comparison, promptly detect and correct possible errors during transmission, thereby ensuring data accuracy and reliability.

[0069] Furthermore, before each data block is written, all relevant transmission delay values D can be measured and recorded in advance. Specifically, it includes pre-measuring the transmission delays between all hardware components involved in data transmission in the system and recording these delay data in the system's log file or a dedicated database. For example, in a Linux system, if a data block needs to be written from the main memory to an SSD storage device, the actual transmission time from the main memory to the SSD storage device is first measured and recorded as the transmission delay value D.

[0070] Check whether the transmission delay value D before writing is greater than the latest transmission delay threshold T_max. If it is greater, pause the writing operation. The transmission delay threshold T_max represents the maximum allowable transmission delay time set by the system, and its parameter range is usually between a few milliseconds and dozens of milliseconds. The optimal value depends on the real-time performance requirements of the system. In this step, the system will check whether the previously recorded transmission delay value D is greater than the current system-set transmission delay threshold T_max before each writing operation. If it is greater than T_max, the writing operation will be paused to avoid data inconsistency or other errors caused by writing in a high-latency environment. For example, if the path delay from the main memory to the SSD is too high, data transfer will be selected from another memory module or through the PCIe interface, bypassing the higher-latency path. After starting the writing operation through the alternate transmission path, the writing status will be continuously monitored until the writing operation is successfully completed, ensuring that even when there are problems with the main path, the data writing task can still be effectively completed, thereby improving the robustness of the system and the reliability of data synchronization. For example, in practical applications, if the first write through the alternate memory module is not successful, the system will wait for a few seconds and then try again until it is confirmed that the data has been successfully written.

[0071] Furthermore, according to the actual transmission delay value D, the formula for adjusting the data block size is: block_size = c * D, where c is a constant used to adjust the change in the data block size. Here, D represents the actually measured transmission delay value between hardware components, usually between a few microseconds and dozens of milliseconds. c is an adjustment factor, usually set between 0.5 and 2, and is selected according to actual application requirements. The choice of c affects the amplitude of the change in the data block size. When the value of c is larger, the data block size will increase rapidly with the increase of the actual transmission delay value D, and vice versa, the change is gentle. By adjusting the value of c, the balance between data transfer efficiency and system load can be controlled, so as to optimize the transfer efficiency by adjusting the data block size and avoid inefficient transfer or resource waste caused by a fixed size.

[0072] In addition, since different transmission delays may cause different data synchronization problems, it is necessary to dynamically select an appropriate verification strategy based on the actual transmission delay value D. For example, when the transmission delay value D is small (the transmission delay is short), a simpler verification algorithm, such as CRC (cyclic redundancy check), can be selected; when the transmission delay value D is large (the transmission delay is long), a more complex verification algorithm, such as SHA-256, needs to be selected to ensure the integrity and accuracy of the data. This strategy can effectively improve the reliability and efficiency of verification while reducing unnecessary computing overhead. During the actual operation process, the data block size and its corresponding transmission delay value D after each adjustment are recorded. These recorded data can help administrators understand the operating status of the system and make optimization adjustments when necessary. For example, in one embodiment, the administrator can analyze these records and find that the transmission delay value D in certain specific time periods is abnormally high, and then troubleshoot network bottlenecks or hardware failures.

[0073] If the data synchronization check fails, such as when a data error or transmission interruption is detected, the system will restore the data block size to the default value. The default value is usually the best setting that has been tested and verified many times. This can avoid continuous check failures caused by unreasonable data block sizes and ensure stable operation of the system. For example, in a specific Linux system repair scenario, when a data synchronization failure is detected, the system will automatically restore the data block size from the adjusted value to the default value of 128KB to quickly resume normal operation.

[0074] In some optional implementations, if the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, the backup transmission path of the target data block can also be obtained; based on the backup hardware component corresponding to the backup transmission path, the target data block is pre-synchronized, and after the pre-synchronization is successful, the step of performing data synchronization verification on the target data block is performed. The purpose of the pre-synchronization is to verify the feasibility and stability of the backup transmission path in advance before the formal synchronization, so as to reduce the problems that may be encountered during the formal synchronization.

[0075] Specifically, you can first try to transfer the target data block to the backup hardware component through the backup transmission path, and perform preliminary data consistency and integrity verification. Only after the pre-synchronization process is successful, the data synchronization verification step of the target data block will be formally executed to ensure that the data can be synchronized to the target hardware component safely and accurately. In this way, when the system faces transmission delay problems, the transmission path can be flexibly selected to improve the reliability and flexibility of data synchronization. At the same time, the pre-synchronization process also facilitates subsequent data recovery and troubleshooting, helping administrators to quickly locate and solve problems and ensure the stable operation of the system.

[0076] In some alternative embodiments, if the transmission delay value characterized by the delay comparison result is greater than the transmission delay threshold, the continuous transmission delay count of the target hardware component can also be obtained; if the continuous transmission delay count is greater than the delay count threshold, the target hardware component is marked as a potentially faulty component; the original kernel module corresponding to the target hardware component is obtained, and the transmission task of the target data block is scheduled to the target kernel module based on process affinity. Process affinity means that when the operating system schedules a process, it tries to arrange a certain process or its threads to run on one or more specific CPU cores as much as possible, so as to improve the hit rate of the CPU cache, reduce the overhead of process switching between different cores, and thus improve the overall performance of the system. In the data transmission scenario, by scheduling the transmission task of the target data block to the original kernel module corresponding to the target hardware component, the continuity and stability of data transmission can be ensured, and the risk of transmission delay and data loss caused by process switching can be reduced.

[0077] If the target hardware component is marked as a potentially faulty component, a hardware diagnostic program can be further triggered to perform a detailed inspection and test on the component to determine whether there is an actual hardware fault. If the diagnostic result shows that there is a hardware fault, a standby hardware component can be started, the administrator can be notified for maintenance, etc., to ensure the continuous and stable operation of the system and the security of data. In addition, the relevant information of the potentially faulty component can be recorded, including the time of the fault occurrence, the type of the fault, the scope of the fault impact, etc., for subsequent analysis and optimization. By comprehensively considering multiple factors such as transmission delay, data block size, and hardware component status, the data transmission strategy is dynamically adjusted to adapt to different operating environments and requirements, so as to improve the overall performance and stability of the system while ensuring data consistency and accuracy.

[0078] Specifically, in the Linux system, the transmission data and response time between hardware components can be continuously collected through kernel modules or user space tools. For example, the status information of the network interface can be obtained regularly by using the ethtool command or the sysfs interface, and the status of the CPU, memory, and other key components can be obtained by reading the relevant information of the / proc file system.

[0079] If the transmission delay value is greater than the transmission delay threshold T_max for N consecutive times, mark this component as a potential failure point. Here, N is a threshold for the number of consecutive detections, and the transmission delay threshold T_max is the set maximum allowable transmission delay time. N is usually between 3 and 5, and the transmission delay threshold T_max is set according to specific network and application requirements, generally ranging from 100 ms to 1 s. If a certain hardware component exceeds this time in consecutive transmissions, it will be regarded as having potential problems. For example, assume N = 5 and T_max = 500 ms. Once a hard disk controller exceeds 500 ms in consecutive 5 read / write operations, this hard disk controller will be marked as a potential failure point. Once a potential failure point is detected, the system will automatically adjust the task allocation strategy to avoid using the faulty component. This can be achieved through affinity settings in the Linux scheduler. For example, in one embodiment, when a certain CPU core is marked as a potential failure point due to excessive transmission delay, the system will migrate tasks to other healthy cores by setting process affinity, thus ensuring that the overall performance is not affected.

[0080] Record the failure point and its recovery situation. For the convenience of later maintenance and troubleshooting, the system will record the specific location, occurrence time, recovery time, and any relevant context information of the failure point in detail in the log. For example, in one embodiment, the above information can be recorded in a dedicated log file in the / var / log directory, and the format is as follows:

[0081] [2024-12-05 14:00:01] It is detected that the transmission delay of the eth0 network card is greater than 500 ms and is marked as a potential failure point.

[0082] [2024-12-05 14:05:30] The eth0 network card returns to normal and the failure mark is removed.

[0083] This data synchronization and verification mechanism can effectively improve the stability and reliability of the Linux system. Especially in large-scale distributed systems and high-performance computing environments, through real-time monitoring and dynamic scheduling of hardware components, failure points can be detected and isolated in a timely manner to ensure the efficient operation of the system.

[0084] Step 140, if the data synchronization verification fails, adjust the working frequency of the target hardware component, and perform data synchronization verification on the target data block based on the adjusted working frequency.

[0085] As described above, by adjusting the operating frequency of the target hardware component, the data transmission efficiency is improved, thereby enhancing the reliability of data synchronization verification. In practice, the operating frequency of the target hardware component is directly related to its data processing speed and energy consumption level. When the data synchronization verification fails, it may indicate that the current operating frequency is insufficient to support efficient data transmission, resulting in transmission errors or increased latency. In such cases, the operating frequency of the hardware component can be automatically changed according to the preset adjustment strategy to improve its processing performance and response ability.

[0086] In some alternative embodiments, after obtaining the transmission delay value when the target data block is transmitted between the target hardware components in the Linux system, the average transmission delay of the target hardware component can also be calculated; if the average transmission delay is greater than the system average transmission delay, and the second delay difference between the average transmission delay and the system average transmission delay is greater than the target error value, the task load of the target hardware component is adjusted, and the target error value is determined based on the load value of the Linux system.

[0087] In the specific operation process, first, the average transmission delay A of each target hardware component (hardware component, component) needs to be calculated; if the average transmission delay A of a certain target component exceeds the average delay T_mean of the entire system, and the exceeded value exceeds the set error value, that is, the target error value ε, then this component needs to improve its performance; then the optimization scheme is adjusted to reduce its task burden; and the optimization effect is regularly checked, and the target error value ε is flexibly adjusted. Calculating the average transmission delay A requires recording the delay time of all transmission requests of each hardware component in the system within a specific period and calculating the average value of these delay times. This process helps to understand the transmission efficiency of each component and ensure that the subsequent steps can accurately identify performance bottlenecks. For example, there are multiple network interface cards NIC in the Linux system, and the average transmission delay A of each NIC is calculated by monitoring the network packet transmission delay within a period of time.

[0088] If the average transmission delay A of a certain component exceeds the average delay T_mean of the entire system, and the exceeded value exceeds the target error value ε, then this component needs to improve its performance. Here, T_mean represents the average delay of all transmission requests of the entire system within the same period, and the target error value ε is a preset threshold used to determine whether the delay of a single component significantly deviates from the system average level. Usually, the target error value ε is set to 5% to 10% of T_mean, which depends on the requirements of the specific application scenario. If the average transmission delay A of a certain component exceeds 10% of T_mean, then it is considered that this component needs to improve its performance. This formula aims to balance the relationship between performance optimization and system resource consumption and avoid resource waste caused by over-optimization.

[0089] The adjustment and optimization plan to reduce its task burden means that after identifying the components that need to be optimized, corresponding measures are taken to reduce their working pressure. Specific optimization plans may include increasing resource allocation, reducing unnecessary data transmission, optimizing data paths, etc. For example, for a NIC that needs to be optimized, the network configuration can be adjusted to reduce the packet traffic on this NIC or transfer some traffic to other NICs to relieve the pressure.

[0090] Regularly checking the optimization effect and flexibly adjusting the target error value ε means that after implementing the optimization measures, the optimization effect is evaluated regularly to ensure that the performance is improved. According to the evaluation results, the value of the target error value ε is flexibly adjusted to adapt to the continuous changes in the system environment. Specifically, the transmission delay of this component can be measured again within a few hours after each optimization. If the delay is significantly reduced, the value of the target error value ε can be appropriately decreased to further improve the optimization standard; conversely, if the delay is still high, the value of the target error value ε may need to be adjusted to be more lenient to avoid frequent misjudgments. The purpose of doing this is to ensure that the system always maintains the best performance state while avoiding unnecessary performance overhead.

[0091] Furthermore, the calculation formula for the target error value ε is: ε = k * L + m, where L is the system load, usually represented by CPU utilization, memory usage, etc.; k and m are constants for adjusting the error value. The value range of k is usually between 0.01 and 0.1, and the value range of m is between 1 and 10. The optimal values depend on the actual application scenarios. For example, in a high-load system, k = 0.05 and m = 5 can be set to adapt to the higher dynamic changes. The purpose of this formula is to make the target error value ε change with the change of the system load to ensure the accuracy of data synchronization under different load conditions.

[0092] Next, after each detection is completed, the target error value ε is updated. This means that after each data synchronization detection between hardware components is completed, the error value under the current system load is recalculated to ensure the timeliness and accuracy of the error value.

[0093] If the delay difference of component Z is greater than the dynamically adjusted target error value ε, optimization processing is performed. The delay difference refers to the difference between the transmission delay of the current hardware component and the expected transmission delay. For example, in an embodiment, the actual transmission delay of component Z is 10 milliseconds, the expected transmission delay is 5 milliseconds, and the current dynamically adjusted target error value ε is 3 milliseconds. Then the delay difference is 5 milliseconds, which is greater than the target error value ε. Therefore, component Z needs to be optimized to reduce the delay.

[0094] Record the time and results of each optimization process. This step aims to track the optimization process of the system for subsequent analysis and improvement. Specifically, the specific time of the optimization process (such as 2024-12-06 15:00:00) and the optimization results (such as reducing the latency of component Z from 10 milliseconds to 7 milliseconds) can be recorded in the log file. Through these records, the system behavior can be better understood and continuous optimization can be carried out.

[0095] In some alternative embodiments, historical transmission latency data of all hardware components can also be collected in real time, including monitoring the network interfaces, disk controllers, processors, and other key hardware components of the system, and regularly recording the data transmission latency between these components to obtain a detailed history of transmission latency, providing a data basis for subsequent predictions.

[0096] Use a machine learning model to predict future transmission latency. After sufficient historical data is collected, the system uses machine learning algorithms such as random forest or LSTM (Long Short-Term Memory network) to predict future transmission latency. The input parameters of the machine learning model may include historical latency values, system load, timestamps, etc. By training the model, the system can predict the specific latency that may occur in the future under different conditions.

[0097] Dynamically adjust the transmission strategy according to the predicted values. Based on the prediction results, the system can adjust the way of data transmission, such as selecting different communication paths or optimizing the size and frequency of data packets. If the prediction shows that certain transmission paths will have high latency at a specific time, the system can choose to bypass these paths or send data in advance to avoid the impact of latency during peak periods.

[0098] When a significant increase in latency is detected, initiate preventive measures to avoid data consistency issues. When the actual monitored latency differs significantly from the predicted value or there is a significant increase in latency, the system will initiate a series of preventive measures. These measures may include data retransmission, adding redundant paths, temporarily reducing the system load, etc., to ensure data consistency and integrity.

[0099] For example, in a specific embodiment, a server cluster running the Linux system needs to perform data synchronization. The network latency between servers may fluctuate due to various factors, including changes in network bandwidth and increases or decreases in server load. The system collects real-time transmission latency data between each pair of servers and uses the LSTM model to predict future latency. When the prediction results show that a certain transmission path may have high latency in the future for a period of time, the system will adjust the data transmission path in advance and select a low-latency path. If a sudden increase in the actual transmission latency is detected during a certain period, the system will automatically start the retransmission mechanism to ensure data consistency. In this process, the input parameter range of the model may be the latency data collected every 1 second in the past hour, and the optimal parameter values are those that minimize the prediction error.

[0100] In some alternative embodiments, it is also possible to perform wear detection and automatic compensation on mechanical moving parts, that is, by regularly detecting the wear condition of the mechanical moving parts of devices such as hard disk drives and tape drives, and evaluating their health status in real time. When it is detected that the wear of a certain part of the mechanical component exceeds the set threshold, an automatic compensation mechanism is activated, such as increasing the cleaning frequency of the magnetic head, adjusting the read and write parameters, etc., to ensure its normal operation. Specifically, during the repair process of a data center, the quality of the magnetic head reading signal of the hard disk drive is monitored. Once an abnormal signal is detected, the magnetic head cleaning program will be automatically executed, and the read and write speed will be appropriately reduced to ensure the reliability of data reading and writing. In this way, the system can extend the service life of the device and reduce the repair failures caused by mechanical failures.

[0101] In some alternative embodiments, it is also possible to monitor the environmental temperature change and adjust the connection stability of the hardware contact points in real time. That is, through the environmental sensors equipped in the system, the temperature change in the data center is monitored in real time. When the temperature changes, the possible thermal expansion or contraction amount of the hardware components is calculated through a preset algorithm, and the connection state of the relevant contact points is automatically adjusted to ensure a stable electrical connection. For example, when the temperature rises, the connection between the expansion card and the motherboard is appropriately pressurized by a robotic arm to prevent poor contact caused by thermal expansion and contraction. This can ensure the stability of the hardware device and the normal operation of the system under extreme temperature conditions, and avoid the risk of data damage and repair failure.

[0102] In summary, for the problem of signal transmission delay between hardware modules in a complex multi-component system. The present invention accurately measures the transmission delay between each hardware component during the system repair process, and dynamically adjusts the data synchronization strategy according to these delay data. For example, when a certain storage device fails to complete a write operation in time due to transmission delay, the system will postpone the read operation of another device to ensure that the read operation is performed after all related devices have completed the write operation, thereby avoiding data inconsistency.

[0103] For devices with mechanical moving parts (such as hard disk drives and tape drives) that are prone to wear and tear during long-term use, resulting in read / write errors or failures. The present invention integrates high-precision sensors to monitor the wear condition of mechanical moving parts and automatically triggers a compensation mechanism when excessive wear is detected. For example, for a hard disk drive, if wear of the read / write head is detected, the system will adjust the position and force of the read / write head to ensure the accuracy of data read / write; for a tape drive, if the magnetic head is worn, the system will automatically perform calibration or prompt the user to replace the component to ensure the reliability of the repair operation.

[0104] Regarding that changes in environmental temperature may cause thermal expansion or contraction of hardware components, which in turn leads to poor electrical connection contacts. The present invention integrates an environmental temperature sensor to monitor the temperature changes in the system operating environment in real time, and when the detected temperature exceeds the safe range, corresponding measures are taken to adjust the fastening degree of the hardware connection points. For example, in a data center, the system will automatically adjust the connection tightness between the server motherboard and the expansion card according to the temperature changes to ensure that even under large temperature fluctuations, the hardware can maintain good electrical contact, thereby preventing repair failures or data damage caused by poor contacts.

[0105] Furthermore, to ensure the integrity and reliability of the system, the present invention regularly performs data consistency verification during the system repair process. Specifically, the system compares the consistency of multiple copy data. If data inconsistency is detected, the system will automatically perform data repair to restore the inconsistent data to the correct state. For example, in a distributed storage system, if the data between the primary node and the secondary nodes is out of sync, the system will preferentially select the latest data from reliable copies and synchronize it to other nodes to ensure data consistency, thereby effectively solving the problems that may occur in complex multi-component systems due to transmission delays, mechanical component wear, and environmental temperature changes, and ensuring the stability of the system and the consistency of data.

[0106] Figure 2 The structural schematic diagram of an embodiment of a data synchronization device based on the Linux system according to the present invention is shown. As Figure 2 shown, the device includes:

[0107] A data acquisition module 210, configured to acquire the transmission delay value when a target data block is transmitted between target hardware components in the Linux system;

[0108] A delay comparison module 220, configured to compare the transmission delay value with a transmission delay threshold to obtain a delay comparison result;

[0109] The synchronization verification module 230 is used to perform data synchronization verification on the target data block if the transmission delay value characterized by the delay comparison result is greater than the transmission delay threshold;

[0110] The data synchronization module 240 is used to adjust the working frequency of the target hardware component if the data synchronization verification fails, and perform data synchronization verification on the target data block based on the adjusted working frequency.

[0111] In an alternative embodiment, the data acquisition module 210 includes:

[0112] The historical data acquisition sub-module is used to acquire the historical transmission delay value of the target hardware component within the target time period;

[0113] The data statistical analysis sub-module is used to perform statistical analysis on the historical transmission delay value to obtain the statistical delay value of the target hardware component;

[0114] The first delay value determination sub-module is used to determine the transmission delay value based on the statistical delay value and the delay standard deviation.

[0115] In an alternative embodiment, the data acquisition module 210 further includes:

[0116] The defined block reading sub-module is used to determine the initial transmission delay value of the target hardware component based on the statistical delay value and the delay standard deviation;

[0117] The load value acquisition sub-module is used to acquire the load value of the Linux system at the current moment;

[0118] The second delay value determination sub-module is used to determine the transmission delay threshold based on the load value and the initial transmission delay value.

[0119] In an alternative embodiment, the data acquisition module 210 further includes:

[0120] The confirmation information acquisition sub-module is used to acquire the confirmation information fed back by the target hardware component based on the heartbeat signal;

[0121] The third delay value determination sub-module is used to determine the transmission delay threshold based on the feedback information of the target hardware component based on the test data packet if the confirmation information is abnormal.

[0122] In an alternative embodiment, the synchronization verification module 230 includes:

[0123] The transmission path acquisition sub-module is used to acquire the alternative transmission path of the target data block;

[0124] The data pre-synchronization processing sub-module is used to perform pre-synchronization processing on the target data block based on the standby hardware components corresponding to the standby transmission path, and after the pre-synchronization processing is successful, execute the step of performing data synchronization verification on the target data block.

[0125] In an alternative embodiment, the synchronization verification module 230 further includes:

[0126] The first delay difference calculation sub-module is used to calculate the first delay difference between the transmission delay value and the transmission delay threshold;

[0127] The transmission priority determination sub-module is used to adjust the transmission priority of the target hardware component based on the first delay difference to preferentially process data blocks with larger transmission delays; or,

[0128] The target data block adjustment sub-module is used to adjust the size of the target data block based on the first delay difference and the corresponding data block adjustment factor, and after the adjustment is completed, execute the step of performing data synchronization verification on the target data block.

[0129] In an alternative embodiment, the synchronization verification module 230 further includes:

[0130] The continuous transmission delay times acquisition sub-module is used to acquire the continuous transmission delay times of the target hardware component;

[0131] The potential failure component marking sub-module is used to mark the target hardware component as a potential failure component if the continuous transmission delay times are greater than the delay times threshold;

[0132] The transmission task scheduling sub-module is used to acquire the original kernel module corresponding to the target hardware component and schedule the transmission task of the target data block to the target kernel module based on process affinity.

[0133] In an alternative embodiment, the delay comparison module 220 includes:

[0134] The average transmission delay calculation sub-module is used to calculate the average transmission delay of the target hardware component;

[0135] The task load adjustment sub-module is used to adjust the task load of the target hardware component if the average transmission delay is greater than the system average transmission delay and the second delay difference between the average transmission delay and the system average transmission delay is greater than the target error value, and the target error value is determined based on the load value of the Linux system.

[0136] In an alternative embodiment, the synchronization verification module 230 further includes:

[0137] The duration acquisition sub-module is used to acquire the duration during which the transmission delay value continuously exceeds the transmission delay threshold;

[0138] An alarm level determination sub-module, configured to determine the alarm level corresponding to the current transmission delay based on the duration;

[0139] A data synchronization verification sub-module, configured to determine the verification method for data synchronization verification of the target data block based on the alarm level.

[0140] The further function descriptions of the above-mentioned various modules and units are the same as those in the corresponding method embodiments above, and will not be elaborated here.

[0141] Through the above device and its components, the technical solution provided by the embodiments of the present invention has the following advantages:

[0142] Please refer to Figure 3 , Figure 3 which is a schematic structural diagram of a computer device provided by an optional embodiment of the present invention. As Figure 3 shown, the computer device includes: one or more processors 310, a memory 320, and interfaces for connecting various components, including a high-speed interface and a low-speed interface. Each component communicates with each other using different buses and can be installed on a common main board or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in the memory or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a set of blade servers, or a multi-processor system). Figure 3 In

[0143] FIG. 3, a single processor 310 is taken as an example.

[0144] The processor 310 may be a central processing unit, a network processor, or a combination thereof. Among them, the processor 310 may further include a hardware chip. The above hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The above programmable logic device may be a complex programmable logic device, a field programmable gate array, a generic array logic, or any combination thereof.

[0145] The memory 320 may include a program storage area and a data storage area. The program storage area may store an operating system and application programs required for at least one function. The data storage area may store data created according to the use of the computer device presented by a kind of mini-program landing page, etc. In addition, the memory 320 may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 320 may optionally include a memory remotely provided with respect to the processor 310, and these remote memories may be connected to the computer device through a network. Examples of the above network include but are not limited to the Internet, an intranet, a server cluster, a mobile communication network, and combinations thereof.

[0146] The memory 320 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, a hard disk, or a solid-state drive; the memory 320 may also include a combination of the above types of memory.

[0147] The computer device further includes a communication interface 330 for communicating the computer device with other devices or a communication network.

[0148] An embodiment of the present invention further provides a computer-readable storage medium storing at least one executable instruction, which, when running on a computer device / a data synchronization device based on a Linux system, causes the computer device / a data synchronization device based on a Linux system to execute the data synchronization method based on a Linux system in any of the above method embodiments.

[0149] An embodiment of the present invention further provides a computer program product including computer instructions for causing a computer to execute the data synchronization method based on a Linux system in the first aspect above or any corresponding embodiment thereof.

[0150] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. In addition, embodiments of the present invention are not directed to any particular programming language.

[0151] In the specification provided herein, a large number of specific details are set forth. However, it can be understood that embodiments of the present invention may be practiced without these specific details. Similarly, in order to streamline the present invention and assist in understanding one or more of the various inventive aspects, in the above description of the exemplary embodiments of the present invention, the various features of the embodiments of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. Among them, the claims following the specific implementation manners are hereby expressly incorporated into the specific implementation manners, where each claim itself serves as a separate embodiment of the present invention.

[0152] Those skilled in the art can understand that the modules in the devices in the embodiments can be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments can be combined into one module or unit or component, and in addition, they can be divided into multiple sub-modules or sub-units or sub-components. Except that at least some of such features and / or processes or units are mutually exclusive.

[0153] It should be noted that the above embodiments illustrate the present invention rather than limit the present invention, and those skilled in the art can design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present invention can be implemented by means of hardware including several different elements and by means of a suitably programmed computer. In a unit claim listing several devices, several of these devices can be embodied by the same item of hardware. The use of the words first, second, and third, etc. does not denote any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A data synchronization method based on the Linux system, characterized in that, The method includes: Obtaining a transmission delay value when a target data block is transmitted between target hardware components in a Linux system; Comparing the transmission delay value with a transmission delay threshold to obtain a delay comparison result; If the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, performing data synchronization verification on the target data block; If the data synchronization verification fails, adjusting the operating frequency of the target hardware component and performing data synchronization verification on the target data block based on the adjusted operating frequency.

2. The method according to claim 1, wherein Obtaining the transmission delay threshold includes: Obtaining historical transmission delay values of the target hardware component within a target time period; Performing statistical analysis on the historical transmission delay values to obtain a statistical delay value of the target hardware component; Determining the transmission delay value based on the statistical delay value and a delay standard deviation.

3. The method according to claim 2, wherein Obtaining the transmission delay threshold further includes: Determining an initial transmission delay value of the target hardware component based on the statistical delay value and the delay standard deviation; Obtaining a load value of the Linux system at the current moment; Determining the transmission delay threshold based on the load value and the initial transmission delay value.

4. The method according to claim 1, wherein Obtaining the transmission delay threshold further includes: Obtaining confirmation information fed back by the target hardware component based on a heartbeat signal; If the confirmation information is abnormal, determining the transmission delay threshold based on feedback information of the target hardware component based on test data packets.

5. The method according to claim 1, characterized in that, If the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, the method further includes: Obtaining an alternative transmission path of the target data block; Performing pre-synchronization processing on the target data block based on an alternative hardware component corresponding to the alternative transmission path, and after the pre-synchronization processing is successful, performing the step of performing data synchronization verification on the target data block.

6. The method according to claim 1, characterized in that, If the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, the method further includes: Calculating a first delay difference between the transmission delay value and the transmission delay threshold; Adjusting the transmission priority of the target hardware component based on the first delay difference to preferentially process data blocks with larger transmission delays; or, Adjusting the size of the target data block based on the first delay difference and a corresponding data block adjustment factor, and after the adjustment is completed, performing the step of performing data synchronization verification on the target data block.

7. The method according to claim 1, characterized in that, If the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, the method further includes: Obtaining the number of consecutive transmission delays of the target hardware component; If the number of consecutive transmission delays is greater than a delay number threshold, marking the target hardware component as a potentially faulty component; Obtaining an original kernel module corresponding to the target hardware component and scheduling the transmission task of the target data block to the target kernel module based on process affinity.

8. The method according to claim 1, characterized in that, After obtaining the transmission delay value when the target data block is transmitted between the target hardware components in the Linux system, the method further includes: Calculating an average transmission delay of the target hardware component; If the average transmission delay is greater than the system average transmission delay, and the second delay difference between the average transmission delay and the system average transmission delay is greater than the target error value, the task load of the target hardware component is adjusted, and the target error value is determined based on the load value of the Linux system.

9. The method according to claim 1, characterized in that, If the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold, the method further includes: Obtaining the duration during which the transmission delay value continuously exceeds the transmission delay threshold; Determining the alarm level corresponding to the current transmission delay based on the duration; Determining the verification method for data synchronization verification of the target data block based on the alarm level.

10. A data synchronization device based on the Linux system, characterized in that, The device includes: A data acquisition module, configured to acquire the transmission delay value when the target data block in the Linux system is transmitted between target hardware components; A delay comparison module, configured to compare the transmission delay value with a transmission delay threshold to obtain a delay comparison result; A synchronization verification module, configured to perform data synchronization verification on the target data block if the delay comparison result indicates that the transmission delay value is greater than the transmission delay threshold; A data synchronization module, configured to adjust the operating frequency of the target hardware component if the data synchronization verification fails, and perform data synchronization verification on the target data block based on the adjusted operating frequency.

Images