Data synchronization method and device, electronic equipment and readable storage medium
By monitoring network performance metrics and prioritizing data based on multi-dimensional factors, and by storing data in a structured and categorized manner, the problem of data inconsistency caused by network disconnection in IoT systems has been solved. This has enabled efficient and reliable data synchronization and ensured consistency between cloud and local data.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-22
- Publication Date
- 2026-03-31
AI Technical Summary
In IoT systems, unstable network environments can cause intermittent disconnections between gateway devices and cloud servers. Existing technologies cannot promptly identify momentary network outages, leading to delayed data caching, inconsistencies between cloud and local states, a lack of flexibility, an inability to process critical data in a timely manner, and security risks.
By monitoring network performance metrics between gateway devices and cloud servers, dynamically adjusting thresholds, determining the priority of terminal devices by combining multi-dimensional factors, structuring and classifying data stored during network outages, prioritizing the synchronization of important data, and introducing a master node-based collaborative adjudication process to resolve data inconsistency issues.
It improves data integrity during network outages and data consistency after network recovery, enhances synchronization efficiency and system reliability, ensures timely processing of critical data, and avoids data redundancy and state chaos.
Smart Images

Figure CN121771199A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of computer technology, and specifically relates to a data synchronization method, apparatus, electronic device, and readable storage medium. Background Technology
[0002] In IoT systems, terminal devices typically communicate with cloud servers through gateway devices to enable remote monitoring, control, and data analysis. However, due to network instability, the connection between the gateway device and the cloud server may intermittently drop. During network outages, terminal devices continue to operate and generate data. Ensuring that this data is consistently synchronized to the cloud after the network is restored is a key challenge to the reliability of IoT systems.
[0003] In existing technologies, connection status is usually determined by heartbeat packets, which has high response latency and cannot promptly identify momentary network outage events, resulting in delayed cache triggering. Furthermore, when multiple users or devices operate on the same target during a network outage, the cloud and local states are inconsistent, and they cannot automatically coordinate after the network is restored, posing a risk of state chaos. In addition, there is a lack of flexibility in synchronizing data from multiple devices, making it impossible to process important data in a timely manner. Summary of the Invention
[0004] The purpose of this application is to provide a data synchronization method, apparatus, electronic device, and readable storage medium to ensure the integrity of data on terminal devices during network outages and to ensure the consistency of cloud and local data after network recovery.
[0005] In a first aspect, embodiments of this application provide a data synchronization method, the method comprising: The network connection status between the gateway device and the cloud server is determined based on the network performance indicators of the gateway device at multiple times. When the network connection is disconnected, the first operating data generated by all terminal devices connected to the gateway device is structured and classified for storage. When the network connection is restored, the priority of each terminal device is determined based on multi-dimensional factors, and the first running data and the second running data stored in the cloud server of each terminal device are synchronized in sequence according to the priority; the multi-dimensional status factors are used to indicate the operating status of the terminal device.
[0006] Secondly, embodiments of this application provide a data synchronization device, which specifically includes: The status determination module is used to determine the network connection status between the gateway device and the cloud server based on the network performance indicators of the gateway device at multiple times. The storage module is used to structure and classify the first operating data generated by all terminal devices connected to the gateway device when the network connection is disconnected. The synchronization module is used to determine the priority of each terminal device based on multi-dimensional factors when the network connection state is restored to connection, and to synchronize the first running data of each terminal device and the second running data stored in the cloud server in sequence according to the priority; the multi-dimensional status factors are used to indicate the operating status of the terminal device.
[0007] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.
[0008] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.
[0009] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.
[0010] This application proposes a system architecture that integrates network status monitoring, local caching, priority scheduling, data synchronization, and conflict detection and resolution, forming a closed-loop processing flow. By using dynamic thresholds and a continuous anomaly judgment mechanism, combined with the device's historical network performance, thresholds are adaptively adjusted to effectively filter out false judgments caused by brief network jitter, improving the accuracy of network outage determination. Data generated during network outages is stored in structured buckets according to service type, improving cache management efficiency. A weighted fusion model based on multi-dimensional status factors is introduced to calculate and dynamically adjust the synchronization order of each device in real time. Furthermore, a hierarchical conflict resolution rule is provided, considering multiple dimensions such as user-defined preferences, timestamps, and data generation sources. In multi-gateway scenarios, a master node-based collaborative adjudication process is introduced to effectively solve data inconsistency problems, ensuring the correctness of business logic and eventual data consistency. Attached Figure Description
[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0012] Figure 1 This is a flowchart illustrating the steps of an embodiment of the data synchronization method of the present invention; Figure 2 This is a flowchart illustrating the steps of another embodiment of the data synchronization method of the present invention; Figure 3 This is a flowchart illustrating the steps of another embodiment of the data synchronization method of the present invention; Figure 4 This is a structural block diagram of a data synchronization device according to the present invention; Figure 5 This is a structural block diagram of an electronic device provided by the present invention. Detailed Implementation
[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0014] 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, not all, of the embodiments of the present invention. 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.
[0015] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, the first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In embodiments of this invention, the term "multiple" refers to two or more, and other quantifiers are similar.
[0016] Before describing the present invention, the application scenarios of the present invention will be explained first: In IoT systems, gateways act as a bridge between local devices and cloud services, and the stability of their network connectivity is crucial. However, environments such as home Wi-Fi and mobile networks inevitably experience fluctuations and interruptions. When the connection is lost, local devices continue to operate and generate data, such as user commands, device status updates, and event logs. Once the network is restored, efficiently, reliably, and intelligently synchronizing this offline data with the cloud status is a core challenge for ensuring user experience and system consistency.
[0017] Existing common solutions to this problem have the following limitations: They typically rely on fixed threshold anomaly detection mechanisms, which cannot distinguish between long-term weak network environments and sudden failures, easily leading to misjudgments or omissions of network events. Furthermore, most devices rely solely on heartbeat packets to determine connection status, resulting in high response latency and an inability to promptly identify momentary network outages, causing delayed cache triggering. Various types of data generated during network outages are often stored mixed in a single queue or file. Current data storage only temporarily stores a small number of instructions, without distinguishing data types or importance levels, making critical operations easily overwritten. After network recovery, the system struggles to quickly identify and differentiate data of different natures, leading to low processing efficiency. After network recovery, full synchronization or blind retries are often performed directly, easily causing data redundancy, device state oscillations, and network congestion. When multiple users or devices operate on the same target during network outages, inconsistencies between cloud and local states cannot be automatically coordinated after recovery, posing a risk of state chaos.
[0018] Furthermore, during data synchronization, all devices are often treated equally without distinguishing between critical devices such as security and temperature control equipment. This leads to delayed processing of high-priority commands, posing security risks. Alternatively, the synchronization order often relies solely on a preset, static device priority list. There is a lack of context awareness, making it unable to dynamically respond to real-time situations. For example, it cannot recognize the urgency of synchronizing a common light fixture that has recently been frequently operated by the user, nor can it prioritize the synchronization of a timed command that is about to expire.
[0019] Method Implementation Examples Reference Figure 1 The diagram illustrates a flowchart of an embodiment of a data synchronization method according to the present invention, the method comprising: Step 101: Determine the network connection status between the gateway device and the cloud server based on the network performance indicators of the gateway device at multiple times; Step 102: When the network connection is disconnected, the first operating data generated by all terminal devices connected to the gateway device is structured and classified for storage. Step 103: When the network connection status is restored to connection, the priority of each terminal device is determined based on multi-dimensional factors, and the first running data and the second running data stored in the cloud server of each terminal device are synchronized in sequence according to the priority; the multi-dimensional status factors are used to indicate the operating status of the terminal device.
[0020] For steps 101 to 103, this solution proposes a systematic data synchronization method that determines network outages based on network performance metrics at multiple time points. Instead of simply checking for timeouts at the current moment, the determination of a network outage event is not based on a single instance of exceeding the limit, but requires that metrics remain consistently abnormal across multiple consecutive time points. Continuous evaluation effectively filters out brief network fluctuations; only when network quality truly and continuously deteriorates is a network outage event confirmed, thereby improving the accuracy and stability of the determination.
[0021] A gateway device refers to a core control node and aggregation device deployed in a local network, such as a home or factory, possessing certain computing, storage, and communication capabilities. The gateway device is responsible for managing all terminal devices connected to it and acts as the primary communication proxy for data exchange between the terminal devices and the remote cloud server. In this application, the gateway device is responsible for communicating with the cloud, managing the caching of local data during network outages, and scheduling and executing the synchronization process after network connectivity is restored.
[0022] Terminal devices refer to various IoT front-end devices that connect to the gateway device via wired or wireless means, such as smart sensors, actuators, home appliances, and security equipment. A terminal device is the physical entity that actually generates business data and executes control commands. In this embodiment, the terminal device is the producer of the first operational data and also the target object that needs to synchronize its local data with cloud data. One of the tasks of this solution is to solve the problem of data synchronization when the terminal device loses connection with the gateway and the cloud.
[0023] Network performance metrics refer to technical parameters used to quantitatively evaluate the quality of the communication link between the gateway device and the cloud server. Network performance metrics are measurable data, typically including but not limited to round-trip latency, packet loss rate, connection establishment success rate, and signal strength. In this embodiment, network performance metrics serve as the objective basis and input data for determining network connection status. Only through continuous monitoring and analysis of network performance metrics can a determination of network connection or disconnection be made.
[0024] Multi-dimensional factors refer to a set of evaluation parameters or characteristics used to comprehensively assess the urgency or importance of data synchronization for a terminal device after network outage recovery from multiple different aspects or perspectives. These multi-dimensional factors collectively constitute a dynamic evaluation system, serving as the decision-making basis for the system to achieve intelligent and dynamic prioritization. Multi-dimensional factors are not a single standard, but rather integrate information from multiple dimensions such as device attributes, user behavior, event characteristics, and temporal context, aiming to make the synchronization order more closely match the real-time needs of actual scenarios.
[0025] The first operational data refers to the operational data newly generated and reported to the gateway by all terminal devices connected to it during the period when the gateway device determines that the network connection status is disconnected. Because the network is down, the first operational data cannot be uploaded to the cloud temporarily and is stored locally.
[0026] Secondary operational data refers to the historical or latest status data corresponding to each terminal device, stored on the cloud server. This secondary operational data represents data about the terminal device recorded in the cloud and obtained from other sources before or during a network outage. Synchronizing the local primary operational data with the cloud-based secondary operational data aims to resolve inconsistencies that may arise due to network disconnection, ensuring that the cloud records ultimately match the actual local conditions.
[0027] Operational status refers to the comprehensive state of a terminal device within a specific context related to network connectivity, especially during network outages and recovery periods. Operational status includes not only the device's physical or logical state but also, and more importantly, attributes related to data synchronization behavior during this specific period, such as the activity level of data generation, the importance level of the generated data, and the closeness of interaction with users. Multi-dimensional factors measure the comprehensive performance of a terminal device from various dimensions to provide information input for prioritization.
[0028] It's important to note that a lightweight monitoring process continuously runs on the gateway device, performing a time-series observation-based state decision-making process. Based on a series of network performance indicators reflecting the network quality between the gateway device and the cloud server collected over time, it determines whether the network connection status is disconnected or connected. This approach abandons the simplistic method of making judgments based on a single detection, aiming to identify a persistent trend of connection degradation rather than instantaneous fluctuations by introducing observations at multiple points in time. Its core function is to improve the accuracy and reliability of state transitions, avoiding frequent and erroneous triggering of subsequent complex caching and synchronization processes due to brief network jitter, thereby improving overall system stability. It ensures that subsequent fault-tolerance mechanisms are only activated when a truly meaningful connection interruption occurs.
[0029] Data is stored in a structured and categorized manner. Structured storage refers to attaching standardized, machine-readable descriptive information to the raw data. It also involves encapsulating each piece of raw data with standardized metadata, forming a unified record format. The system implements categorized storage based on the business nature and synchronization goals of the data. This ensures that the data is organized systematically from its inception, laying a solid foundation for subsequent differentiated synchronization processing. By assigning standardized tags to the data, data that might have been disorganized in an offline environment can be clearly identified, distinguished, and processed sequentially by the system in subsequent processing.
[0030] Categorized storage refers to allocating data to different logical or physical storage units based on some inherent attribute. Categorized storage categorizes data according to its type or purpose, achieving initial differentiation and isolation of data. This provides the physical basis and management possibility for differentiated synchronization strategies that may be implemented after network recovery.
[0031] When network recovery is detected, data transmission does not begin immediately. Instead, a priority scheduling calculation is initiated. This calculation, targeting each terminal device that generated cached data during the network outage, collects its recent operational status from multiple predefined dimensions and integrates these data to calculate a dynamic priority score. The role of these multi-dimensional factors is to construct a comprehensive evaluation perspective, breaking away from a single evaluation system that relies solely on fixed device types. This allows the system to introduce more variables reflecting the real-time context, generating a more reasonable synchronization order that better suits current needs.
[0032] Prioritization transforms multi-dimensional assessments into an executable sequence of actions. It's a dynamic calculation process that generates a dynamic priority order for each device based on real-time factors. Its fundamental purpose is to optimize the synchronization sequence, ensuring that in the limited bandwidth and time available during the initial network recovery phase, the system can prioritize processing the most urgent and important data based on the comprehensive assessment, thereby improving synchronization efficiency and the timeliness of critical data. Based on this dynamically calculated priority score, the system sorts all devices to be synchronized, generating a task queue for this synchronization. Subsequently, strictly following this queue order, the system compares and synchronizes the cached data with the cloud data for each device one by one. Therefore, the synchronization operation is not concurrent or chaotic, but strictly adheres to the sequence defined by the aforementioned priorities. This sequential processing ensures that system resources are allocated in an orderly manner, avoiding contention and ensuring that high-priority tasks are not blocked by low-priority tasks.
[0033] In this embodiment, by continuously identifying and filtering out brief network jitters through consistently abnormal indicators across multiple time points, the accuracy and stability of the judgment are improved. By structuring and classifying the first operational data, data that might otherwise be disorganized in an offline environment can be clearly identified, distinguished, and processed sequentially by the system in subsequent processing. By determining the priority of terminal devices based on real-time multi-dimensional factors, the system ensures that, within the limited bandwidth and time available during the initial network recovery phase, it can prioritize processing the most urgent and important data based on a comprehensive assessment, thereby improving synchronization efficiency and the timeliness of critical data.
[0034] It systematically improves the overall reliability, efficiency, and intelligence level of data synchronization for IoT devices in unreliable network environments. Reference Figure 2 The diagram illustrates a flowchart of another embodiment of the data synchronization method of the present invention, the method comprising: Step 201: Determine the preset threshold value corresponding to each network performance indicator based on the network operation status of the gateway device; Step 202: At preset time intervals, compare each network performance indicator with its corresponding preset indicator threshold; the preset time interval is dynamically changing. Step 203: Determine the network connection status based on the results of multiple consecutive comparisons.
[0035] For steps 201 to 203, this embodiment introduces a dynamic baseline and debouncing mechanism based on historical learning. The system continuously learns the historical network performance of a specific gateway in its deployment environment. For example, for a gateway with a weak clock signal, the system adaptively increases its latency threshold for determining anomalies. This avoids generating meaningless and frequent network outage alarms in environments where devices are not functioning properly, reducing false alarms.
[0036] Network performance refers to the historical and current network communication performance of a gateway device. It includes two key aspects: historical statistical characteristics, such as average latency and typical packet loss rate, and real-time environmental conditions, such as the current Wi-Fi signal strength (Received Signal Strength Indicator, RSSI).
[0037] The preset threshold values are the critical values used to determine whether a single network performance indicator is abnormal. These thresholds are not applied uniformly to all devices, but are dynamically calculated based on the gateway's unique historical network performance. For example, for a gateway that has long operated in a weak network environment, its Round-Trip Time (RTT) threshold might be set to "historical average RTT + 50ms". Dynamically adjusting these preset threshold values avoids frequent false alarms caused by overly strict fixed thresholds in scenarios with already poor network conditions, making the judgment logic more closely reflect the actual operating environment of the devices.
[0038] The preset time interval refers to the period during which the system samples network performance indicators and compares them against thresholds. Dynamic variation means that this sampling period is not fixed but can be shortened or extended based on the real-time network environment. The sampling frequency is not constant; for example, when extremely low Wi-Fi signal strength is detected, indicating a very fragile physical layer connection, the system will reduce its tolerance and trigger accelerated sampling (i.e., shorten the time interval). This allows the system to capture abnormal signs more quickly and intensively when network quality deteriorates rapidly, thus providing more sufficient warning and preparation time for potential impending network outages and improving the system's sensitivity to high-risk states.
[0039] Multiple consecutive comparison results refer to a series of closely spaced sampling comparisons over time, such as three. Determining a network outage between the gateway and the cloud server is not based on a single abnormal comparison, but rather requires multiple consecutive sampling results to meet the abnormal conditions. This constructs a state filter that effectively filters out instantaneous metric exceedances caused by brief network jitter or sudden interference. Only when the abnormal state persists for a period of time is it confirmed as a trend of quality degradation, thus formally determining it as a network outage event. This improves the robustness and reliability of state determination and avoids frequent and erroneous switching between online and offline modes due to instantaneous fluctuations.
[0040] In this embodiment, a reasonable anomaly detection baseline is set based on historical learning to avoid frequent false alarms due to overly strict fixed thresholds. This makes the judgment logic more closely match the actual operating environment of the device and adapt to individual differences in terminal devices. The monitoring frequency is adjusted according to the real-time environment to balance resource consumption and risk perception. Through a continuous confirmation mechanism, instantaneous index exceedances caused by brief network jitter and sudden interference are effectively filtered out, resisting instantaneous interference and ensuring the reliability of the judgment conclusion.
[0041] Step 204: For each piece of the first running data, the first running data is structured according to the timestamp of the first running data generation and the identifier of the terminal device; Step 205: Store the structured instruction data in the first cache queue, store the structured device status data in the second cache queue, and store the structured log data in the third cache queue.
[0042] Regarding steps 204 and 205, structuring refers to assigning traceable identities and time tags to data, standardizing and encapsulating the original data, and transforming the first running data from a simple business record into a structured data object with complete descriptive information.
[0043] Each structured record must contain the following core metadata: a timestamp and a device identifier. The timestamp, accurate to milliseconds, ensures that once the network is restored, the system can accurately reconstruct the true chronological order of events across all devices and data types. The unique device identifier acts as a data ownership identifier. In an environment where a gateway connects multiple terminal devices, it clearly identifies which specific device generated each piece of data. This ensures that data is correctly collected and processed during subsequent prioritization and synchronization by device.
[0044] When storing the first piece of running data into the corresponding cache queue, a unique sequence number is assigned to each piece of first running data, ensuring the internal data order within the same cache queue. The sequence number, combined with the device identifier and timestamp, forms a combined index, supporting more granular breakpoint resumption and deduplication. When the synchronization process is unexpectedly interrupted, the system can quickly locate the breakpoint based on the sequence number of the last successfully synchronized data, avoiding duplicate transmissions.
[0045] Categorized storage, also known as bucketed storage, isolates data streams according to business logic. Based on data structuring, it physically or logically distributes data into different, independent storage queues or buckets according to the data's business type and purpose. The first cache queue, also known as the instruction cache bucket, stores control commands triggered by users or automated scenarios, such as "turn on the air conditioner." The second cache queue, also known as the status cache bucket, stores objective status snapshots reported by devices, such as "current temperature 26℃," used to update the cloud's understanding of device status. The third cache queue, also known as the log cache bucket, stores context logs of operations and events, such as "who did what, when, and how." It is primarily used for auditing, debugging, and scenario reconstruction, providing a complete chain of contextual evidence for conflict resolution and problem investigation.
[0046] The three queues are managed separately in terms of storage path, using naming conventions such as command / device_001 and status / device_001. This avoids interleaving byte streams of different data types during writing, preventing confusion during parsing. Within each queue, data is strictly arranged in ascending order according to timestamps. Efficient sequential append and sequential read operations are supported, which is crucial for ensuring data consistency and synchronization efficiency.
[0047] The purpose of categorized storage is to achieve refined data management and differentiated synchronization strategies. It separates mixed data according to their purpose, enabling the system to implement different management strategies for different queues. It also enables the subsequent synchronization engine to quickly locate and extract specific types of data.
[0048] It should be noted that persistent storage can also be used when storing the initial running data. Specifically, the data is written to Flash or SD card, ensuring that the cached data will not be lost even if the device unexpectedly loses power and restarts, thus guaranteeing the data's long-term reliability. The cached content is encrypted using the Advanced Encryption Standard-256-bit (AES-256) encryption algorithm to prevent the leakage of sensitive user information in the event of device loss or unauthorized access, thereby protecting user privacy and security.
[0049] In this embodiment, a unified metadata model solves the issues of data identity and timing, and business-based bucketing optimizes data management and scheduling. This provides a solid, orderly, and efficient data foundation for subsequent multi-dimensional factor prioritization and implicit conflict resolution. This fundamentally improves the speed, accuracy, and reliability of the system's recovery from network failures.
[0050] Step 206: Determine the weights corresponding to each dimension factor; Step 207: For each terminal device, determine the first score of each dimension factor based on the first running data within the specified time window; Step 208: Determine the priority of each terminal device based on the weight of each dimension factor and the first score.
[0051] For steps 206 to 208, the multi-dimensional factors refer to evaluation indicators from different aspects used to assess the urgency of terminal device synchronization, with each factor representing an evaluation perspective. The weight refers to an importance coefficient assigned to each dimension factor, quantifying the proportion of that factor in the final decision. By assigning different weights to different factors, system designers or adaptive algorithms can define which considerations are more important. For example, the weight of "device security-related factors" can be set higher than the weight of "user convenience-related factors." The existence of weights ensures that the final priority order reflects a pre-set or learned business strategy, rather than a simple numerical summation.
[0052] A specified time window refers to a specific and limited historical time range that is examined during the evaluation, such as "the last 24 hours", "the last 7 days", or "during this network outage".
[0053] The first score refers to a numerical result calculated based on the initial operational data of a specific terminal device within a specified time window. This score quantifies the device's performance on a particular dimension factor. By limiting the scope of the evaluation data through a specified time window, the calculation ensures that it is based on recent and relevant behavioral data, avoiding the interference of outdated historical data in assessing the urgency of the current situation. The abstract performance on each dimension factor is transformed into a concrete and comparable numerical value. For example, for the factor of "user interaction activity," the score might be the number of operations within the time window; for the factor of "data timeliness," the score might be the remaining valid time of the synchronization command. This provides standardized input for subsequent comprehensive calculations.
[0054] It's important to note that the system has a built-in device priority mapping table. Based on the device's functional attributes and security level, different priorities are assigned: security devices such as door locks, cameras, and smoke detectors are classified as Level 1; environmental control devices such as thermostats and air purifiers are Level 2; and non-critical devices such as lighting, audio equipment, and curtains are Level 3. When the synchronization process starts, the system processes data sequentially according to priority, ensuring that instructions from Level 1 devices are uploaded and processed first. Furthermore, the system also has a dynamic priority adjustment function. Determining priority refers to calculating a final value or level for each terminal device using a clear mathematical or logical rule. Typically, this is represented by a function that calculates a comprehensive score, for example, a weighted sum: Comprehensive Score = (Factor A Weight × Factor A First Score) + (Factor B Weight × Factor B First Score) + ...). It should be noted that the weights are dynamically changed; they can be specified by the user or updated automatically by the system based on historical network performance. Since the data used during each synchronization may differ, the priority also changes dynamically, and the priority of each terminal device may change within different synchronization cycles.
[0055] In this embodiment, a key transformation from multi-dimensional, heterogeneous evaluation to single-dimensional, comparable ranking is achieved. This allows for the simultaneous consideration of signals from different, even potentially contradictory, perspectives, and harmonizes them into a unified decision-making criterion based on pre-defined importance. Ultimately, all terminal devices are ranked according to this comprehensive result, generating a synchronization sequence that reflects both multi-dimensional real-time status and conforms to a predetermined strategy.
[0056] Optionally, determining the priority of each terminal device based on multi-dimensional factors includes: Step S11: During the process of determining the priority, when the multi-dimensional factors of the terminal device meet the preset conditions, the duration for which the multi-dimensional factors meet the preset conditions is counted; the preset conditions are the conditions for adjusting the priority of the terminal device. Step S12: When the duration exceeds the preset duration, adjust the priority of the terminal device; Step S13: After the priority of the terminal device is adjusted, the priority of the terminal device is maintained unchanged until the data synchronization of the terminal device is completed.
[0057] For steps S11 to S13, the preset conditions refer to the specific rules or logical judgments that trigger the adjustment of the priority of a terminal device. For example, "temporarily increasing priority due to 'event severity' or 'network disconnection activity'" are two typical preset conditions. It should be noted that priority change refers to comparing with the latest priority, recalculating the priority during the current synchronization process, and determining whether the priority needs to be changed.
[0058] The duration for meeting the preset conditions refers to the length of time from the first detection that a terminal device meets the above adjustment conditions to the current moment, during which the conditions remain valid. By introducing time persistence as a threshold for priority changes, the conditions triggering priority adjustments cannot be merely met instantaneously, but must persist for a certain period. This is the first line of defense in the anti-vibration mechanism. For example, a user might only briefly light up their phone screen, causing a device's "user behavior heat" factor to spike instantly. Without duration statistics, the system might immediately respond and increase the device's priority. However, by requiring "duration exceeding the preset duration," for example, the heat must last for more than 30 seconds, such brief, accidental operational fluctuations can be filtered out, preventing unnecessary priority jumps due to instantaneous interference and avoiding frequent priority switching caused by short-term user operations.
[0059] Maintaining priority until data synchronization is complete means that once a terminal device's priority is adjusted according to rules (usually by increasing priority), the new priority is fixed and remains unchanged in subsequent scheduling decisions until all data cached by the device during the network outage is successfully synchronized to the cloud. Locking is not about the calculation process, but the calculation result, used to ensure the continuity of critical tasks. For example, for a device raised to the highest priority due to a smoke alarm, the locking mechanism ensures it remains at the head of the queue throughout the synchronization process. Even if its "user behavior heat" score decreases due to calculation cycle updates during synchronization, it will not be downgraded, thus ensuring that high-risk alarms are processed continuously and without interruption. For a device temporarily elevated due to high "network outage activity," the locking mechanism prevents it from being downgraded before the synchronization is complete due to other factors, such as a temporary low heat, ensuring that devices identified as critical paths can have their backlog data cleared in one go. Locking priorities keeps the execution queue of synchronization tasks relatively stable within a single synchronization cycle, avoiding the scheduler complexity and unpredictability that could result from task reordering mid-execution.
[0060] Exponential decay weighting is another important smoothing technique applied to the calculation of factor scores. For example, the "user behavior popularity" score is not a simple count of frequency, but rather an exponential decay weighting of historical operations over time, giving greater weight to recent operations and less weight to older operations. Thus, even if a user operated frequently yesterday, if they don't operate today, their popularity score will decrease smoothly and quickly, rather than plummet. This inherent smoothness in the score calculation reduces the possibility of drastic jumps in priority from the outset, forming a comprehensive shock-absorbing system together with time interval constraints.
[0061] In this embodiment, priority is smoothly adjusted by calculating the exponential decay of factor scores. Requiring conditions to be met continuously for a certain duration ensures a minimum change interval, filtering out momentary interference. Once a reasonable priority change occurs, the result is locked until the task is completed, preventing interference with the execution process and avoiding the scheduler complexity and unpredictability that could result from task reordering mid-execution.
[0062] Optionally, step 207 may specifically include the following steps: Step S21: Determine the first score of the abnormal event factor based on whether the first operating data of the terminal device carries a warning tag; the warning tag is used to indicate that the terminal device has an abnormality. Step S22: Determine the first score of the device activity factor based on the data generation frequency of the terminal device; the data generation frequency refers to the frequency at which the terminal device generates data within the specified time window and when the network connection is disconnected. Step S23: Determine the first score of the user behavior heat factor based on the number of times the terminal device is used within the specified time window; Step S24: Determine the first score of the data time information based on the timestamp of the first running data generated in the terminal device; Step S25: Determine the first score of the device dependency relationship based on the association relationship between the terminal device and the other terminal devices.
[0063] The multi-dimensional factors include at least three of the following: abnormal event factors, device activity factors, user behavior popularity factors, data time information, and device dependency relationships.
[0064] For steps S21 to S25, the core dimensions considered by the priority calculation model are clearly defined in this application embodiment, and the basic calculation basis for the score of each dimension is defined. These multi-dimensional factors together constitute a multi-perspective perception system for evaluating the urgency of device synchronization. It should be noted that the multi-dimensional factors for determining the terminal device include, but are not limited to, the factors illustrated above.
[0065] Anomaly factors are used to quantify the urgency and danger of events occurring on terminal devices. The evaluation object is whether the data contains specific identifiers characterizing device malfunction, security threats, or system alarms. Its initial score depends on whether the first running data carries a warning label. The system scans the first running data, especially event log data or metadata, looking for predefined warning labels such as "alarm," "anomaly," and "urgent," for example, "smoke concentration exceeding limits" or "illegal intrusion detection." Once such a label is detected in a device's data, not only is the score of that anomaly factor set to the highest value, but more importantly, a special rule in the dynamic weighted scoring model is triggered: within the current synchronization cycle, the weight of the anomaly factor is temporarily set to 100%, or an equivalent "forced priority escalation" logic is executed. In other words, when a synchronization task occurs on a terminal device due to an anomaly, its priority will disregard the evaluation results of all other factors, be directly elevated to the highest level, and prioritized for scheduling. This ensures that events related to personal and property safety receive immediate responses.
[0066] The device activity factor measures the frequency of business logic or user interaction on a terminal device under specific adverse conditions of network disconnection, reflecting whether the device is "busy" during offline periods. The system not only considers the frequency during a single network outage but also tracks the device's data generation behavior over the "last three or more network outage cycles." If a device remains active despite multiple consecutive network outages, the system determines that it is either on the core path of high-frequency user operations or located at the network edge. For such devices, the system increases their initial score or temporarily raises their synchronization priority by one level to prevent them from accumulating too many important states due to prolonged periods at the back of the queue, thus avoiding critical path backlog risks. Therefore, the initial score calculation of the device activity factor incorporates this cross-cycle trend analysis.
[0067] User behavior heat factor is used to characterize the recent attention and interaction intensity of users on specific terminal devices, allowing users to perceive the importance of the device. The system constructs a "device heat index," whose data sources are not limited to direct operations, but also include the density of remote access by users on the application (APP) and the number of times the device is invoked by smart scenarios, thus comprehensively evaluating heat from multiple dimensions. For example, the system focuses on the recent window of "the past 24 hours" or "5 minutes before network disconnection," ensuring the timeliness of the evaluation and capturing the user's current operational intent. When the number of operations exceeds a preset threshold, such as more than 5 times in 24 hours, or there is an operation in the very short time before network disconnection, the system will mark the device as a "currently watched device" and increase its first score or priority in this synchronization. This makes the calculation of the first score not a simple linear increase, but also includes a non-linear increase based on the threshold, ensuring a rapid response to the user's real-time intent.
[0068] The data time information factor assesses the business timeliness or effective lifecycle of the first running data, rather than simply the age of the timestamp. It determines whether data is "about to expire" or "currently in a critical period of effectiveness." The system not only reads the timestamp but, more importantly, combines it with the business semantics of the data for judgment. For example, for a "timed control instruction," the system extracts its preset execution time window. By comparing the current time with the data's effective time point, such as the execution time of a scheduled task, it calculates their proximity. If the current time is close to or slightly beyond the execution window—for example, if the instruction is set to execute at 10:00 and the current time is 10:05—the system determines that the data has strong timeliness, its score will be significantly increased, thereby raising the synchronization priority and preventing control instructions from failing or being executed out of order due to synchronization delays.
[0069] Device dependency factors are used to identify and quantify the logical coupling and linkage relationships between different terminal devices in terms of function or scenario, aiming to ensure the atomicity and consistency of cross-device collaborative services. Modeling the linkage relationships involves the system establishing a device dependency model through pre-configuration or learning, such as the scenario sequence "open door → turn on light → start welcome voice". When the master device, such as a door lock, gains high priority and is scheduled for synchronization due to other factors, such as user behavior intensity or abnormal events, the system will automatically increase the synchronization priority of its strongly associated subordinate devices, such as the entryway light, according to the dependency model. Data from subordinate devices can be processed in advance without waiting for their own static priority to be processed, thus ensuring that the entire linkage scenario can be completely and continuously restored and executed in the cloud, avoiding the logical disconnect of "the door has been opened and synchronized, but the light-on record is still in the queue".
[0070] In this embodiment, the priority of terminal devices is calculated using a sliding time window and exponentially decaying weights to ensure that recent behavior has a greater impact, while historical impacts decay smoothly. The first score is then input into a configurable, learnable, and Over-the-Air Remote Update (OTA) weighted scoring model for fusion. This weighted scoring model not only assigns initial weights to each factor but is also dynamically adjusted by the triggering mechanism of abnormal event factors and can be iteratively optimized based on system performance. Through multi-dimensional factors, a comprehensive and three-dimensional evaluation system is achieved that covers security emergency response, user experience, performance during network outages, business timeliness, and scenario integrity, thereby generating an intelligent, reasonable, and realistic synchronization priority order.
[0071] Step 209: During the synchronization of the first running data and the second running data, determine whether the first running data and the second running data are consistent; Step 210: In the event of inconsistency, determine the third running data from the first running data and the second running data according to a preset rule, and synchronize both the first running data and the second running data to the third running data.
[0072] Regarding steps 209 and 210, the first operational data refers to device data generated and cached locally on the gateway during the network outage. The second operational data refers to data corresponding to the same device stored on the cloud server. These two sets of data are compared to check for logical or numerical contradictions or differences in the device status, instruction content, or event information represented by the two sets of operational data. This aims to identify potential conflicts arising from the independent operation of both ends during the network outage. Such conflicts may stem from user operations on the local machine causing changes in device status, i.e., updating the first operational data, which is unknown to the cloud; or the cloud receiving instructions from other sources during the network outage, i.e., updating the second operational data, which is unknown to the local machine. The purpose of this step is to proactively identify discrepancies requiring coordination and to trigger the resolution process. This ensures that synchronization is not a simple data overwrite, but an intelligent process involving comparison and adjudication.
[0073] It should be noted that inconsistencies or conflicts mainly fall into three categories. Specifically, the first category is state conflict, such as the local record being "door lock open" while the cloud record is "door lock closed"; the second category is timestamp conflict, where the local timestamp is later than the cloud timestamp, but the state is reversed; and the third category is data anomaly conflict, such as the local sensor reporting a temperature of 28°C while the cloud record is 22°C, with a deviation exceeding 5°C.
[0074] Preset rules refer to a set of decision-making logics or algorithms predefined by the system for resolving data conflicts and selecting the final valid data. Third-running data refers to the data version selected or derived from the conflicting "first-running data" and "second-running data" according to the preset rules, and deemed authoritative or correct. Third-running data may be one of the two directly, or it may be new data generated by merging the two. Preset rules provide predictability and configurability for conflict resolution. Preset rules can be very simple, such as "always use local data," or very complex, such as combining timestamps, data source credibility, user preferences, and other factors. The significance of setting a preset rule mechanism is that the system can make decisions automatically without manual intervention, ensuring processing efficiency and allowing for adaptation to different business scenarios or security requirements by configuring different rules. Synchronization refers to a forced update action that changes the data stored both locally and in the cloud to the content defined by the third-running data.
[0075] In this embodiment, data synchronization is not a one-way overwrite, but a two-way unification. Regardless of how the conflict initially occurred, after performing this operation, the data about the device's state in the local cache and the cloud server will become completely consistent. This fundamentally eliminates data discrepancies caused by network outages, ensuring that after the system restores the connection, the local and cloud perceptions of the device's state are unified and accurate.
[0076] In this embodiment, a complete data conflict resolution closed loop is formed: the first step, detection, is responsible for identifying problems. The second step, resolution and synchronization, is responsible for resolving problems according to predetermined strategies and enforcing a consistent state. This gives the conflict resolution module a clear interface, good scalability, and fundamentally guarantees the ability of data in the distributed system to restore consistency after a network outage.
[0077] Optionally, step 210 may specifically include the following steps: Step S31: Determine whether there is a user instruction; if there is a user instruction, determine the third running data according to the user instruction. Step S32: In the absence of the user instruction, compare the timestamps carried by the first running data and the second running data, and use the data with the later timestamp as the third running data.
[0078] Regarding steps S31 and S32, this embodiment explicitly specifies the decision path the system should follow when data inconsistency is detected. The first-level decision follows user-defined preferences. User instructions refer to explicit choices or configuration rules regarding how to handle specific types of data conflicts, pre-set or specified in real-time by the user through system-provided interfaces, such as a mobile app. For example, a user can set "when there is a conflict in door lock status, always prioritize local manual operation."
[0079] When a conflict resolution is required, the system first checks if there are any pre-defined user instructions applicable to the current conflict scenario. If a valid user instruction is found, the system unconditionally adopts that instruction as the basis for resolution and directly determines the third operational data based on its content. For example, if the user instruction is "local as the standard," then the third operational data becomes the first operational data. This places the user's explicit intent at the top of the resolution system, setting preferences based on the user's personal understanding of home usage habits, device characteristics, or privacy and security, thus meeting the user's personalized needs.
[0080] The second-level adjudication is based on objective logic using timestamps. A timestamp is metadata embedded in the first and second running data, precisely recording the moment the data was generated or the event occurred. A later timestamp means the event described by the data occurred later in the time series. When the user's instruction does not provide a basis for adjudication, the system automatically proceeds to this level. Timestamp comparison refers to the system extracting and comparing the timestamps carried by two sets of data, identifying the data with the later timestamp as the third running data. In situations where the user's explicit intent is unknown, assuming that "later events" override "earlier events" is the most reasonable inference for maintaining state consistency. For example, if the local record says "unlocked at 10:05" and the cloud record says "locked at 10:00," then the 10:05 unlocking record is adopted as the current valid state. Timestamps are a ubiquitous, machine-comparable objective attribute, providing the system with a powerful tool for automatically and efficiently resolving conflicts without user intervention.
[0081] The state transitions of IoT devices are typically driven by ordered events. Adopting the latest timestamp data essentially rolls the device state back to the result after the last known event occurred, which is logically consistent and conforms to the event-driven state machine model.
[0082] It should be noted that since data from the same terminal device may reside in the cloud, a gateway device, or its own local cache, synchronization unifies all data related to that terminal device. In implementing the timestamp priority rule in this application embodiment, a crucial prerequisite is that the data being compared must be reliable and comparable. Therefore, when synchronizing local and cloud data of a terminal device without user instruction, the authority of the data source must first be determined. If one piece of data comes from the device's local physical sensors, it has higher authority; if another piece of data is a network-forwarded status, it has lower authority, even if the latter's timestamp is slightly later. Under more comprehensive rules, the system may need to weigh these factors. In standard scenarios, the main control device, such as a gateway or central control screen, typically has higher authority. For example, the physical state of a smart door lock is more reliable than its Wi-Fi reported state; therefore, the door lock itself is the authoritative source of its state. In special cases, simple timestamp comparison may lead to logical fallacies; for example, the timestamp of a manual unlocking command may be later than that of a remote locking command, but logically, manual operation should be respected.
[0083] In this embodiment, a multi-dimensional conflict detection and resolution mechanism based on user preferences, device authority, and timestamps is used to synchronize local and cloud data of terminal devices according to a hierarchical system that prioritizes user preferences, timestamps, and then device authority. This not only effectively identifies and coordinates conflicts between cloud and local states caused by concurrent operations of multiple devices and users, but also meets the personalized needs of users.
[0084] Optionally, step 210 may specifically include the following steps: Step S41: Collect the first operating data of the terminal devices stored in each of the gateway devices; Step S42: Determine whether the first operating data in each of the network devices is consistent. If they are inconsistent, the gateway device and other gateway devices shall make multiple rounds of decisions to determine the third operating data from the first operating data.
[0085] Regarding steps S41 and S42, in this embodiment, multiple gateway devices exist in the local network. First, these gateway devices jointly elect an edge hub as the master node. For example, the central control screen is the master node, and each gateway is a slave node. When conflicts arise in the first running data of a terminal device among the multiple gateway devices, the system initiates a consensus voting process. The master node collects local data from all slave nodes, performs consistency verification, and finally determines a unified and authoritative final state. The local and cloud data of the terminal data are synchronized according to this final state. If the current gateway device is elected as the master node, it executes the operation; otherwise, it accepts the control of the master node. In the lightweight distributed consensus mechanism, the central control screen is designated as the master node. The master node sends data query requests to all relevant slave nodes in the network, and each slave node reports its stored local cached data copy regarding the target terminal device.
[0086] When the master node detects data inconsistency, it does not make a unilateral decision, but rather organizes a distributed decision-making process. This process may involve multiple rounds, including preparation, proposal, voting, and submission phases, to ensure robust consensus is reached even in the event of network latency or brief node anomalies. The core of the decision-making process is the voting mechanism. The master node may distribute different versions of data as proposals to each slave node, and each node votes according to predetermined rules or reports the confidence level of the data it holds.
[0087] Through multiple rounds of adjudication, a consensus is ultimately reached among all participating gateway nodes on which data version should be adopted as the authoritative version. Typically, the master node determines the unified state based on voting results or a pre-defined adjudication algorithm, such as majority rule or priority of the latest timestamp. The final state is generated through a voting mechanism involving multiple nodes, enhancing the legitimacy and reliability of the result and avoiding problems caused by single points of failure or master node bias. After consensus is reached, the master node is responsible for synchronizing the unified state, i.e., the third-party running data, to the cloud and all user terminals, and generating a processing log covering this consensus process, thus achieving a complete closed loop from conflict detection and distributed adjudication to state synchronization and auditing.
[0088] In this embodiment, when a conflict detection indicates that a data inconsistency issue originates from the same device covered by multiple gateways, standardized single-gateway strategies such as "scenario rule priority and latest operation verification" may not be directly applicable. This is addressed by introducing a lightweight voting consensus protocol coordinated by the master node and involving multiple nodes. Through distributed collection, verification, and multi-round adjudication, the local perceptions of the same device from multiple gateways are merged into a globally recognized authoritative state. This ensures that even if a device generates several different cached data sets under the signal coverage of multiple gateways, the system can ultimately provide a unique and universally accepted state to the cloud and all relevant parties. This effectively solves the cross-gateway data disagreement problem unique to complex IoT deployments and guarantees eventual data consistency in distributed scenarios.
[0089] In summary, the data synchronization method provided in this application can adapt to the differences in network environments of different devices through dynamic thresholds and dynamic sampling intervals. Combined with a continuous multiple anomaly confirmation mechanism, it achieves intelligent network outage detection with high accuracy and low false alarm rate. Structured data ensures strict timeliness and globally unique traceability of data, while classified storage achieves physical data isolation and management according to business priorities, greatly improving the efficiency of cache access and synchronization scheduling. The multi-dimensional factor fusion model covers multiple levels, realizing a comprehensive evaluation that is three-dimensional and close to real business needs. Dynamically configurable and remotely updated weights enable the scheduling strategy to be continuously optimized with business development. The anti-oscillation mechanism and priority locking mechanism jointly ensure that the scheduling order will not frequently jump due to short-term fluctuations, achieving the ultimate smoothness and stability of the scheduling process. A hierarchical adjudication rule is established, which provides conflict resolution paths while respecting user autonomy and can identify sources with higher credibility. For complex multi-gateway scenarios, a lightweight distributed consensus mechanism coordinated by the master node is introduced to effectively resolve cross-gateway data disagreements and ensure the eventual consistency of global data in a distributed deployment.
[0090] Reference Figure 3 The diagram illustrates a flowchart of another embodiment of the data synchronization method of the present invention, the method comprising: Step A11: System startup and initialization; Step A12: Continuously collect network metrics; Step A13: Determine if there are three consecutive abnormalities; Step A14: In the event of three abnormal occurrences, determine the network outage event; Step A15: After confirming the network outage event, activate the local cache module; Step A16: Storing the three types of data in a structured manner; Step A17: Perform network recovery test; Step A18: Check if the network is available; Step A19: If the network is available, start the synchronization process; Step A20: Perform incremental synchronization and resume interrupted transmission; Step A21: Perform conflict detection and resolution; Step A22: Process logs and push applications; Step A23: Synchronization complete, clear cache; Step A24: Adjust the dynamic priority.
[0091] In this embodiment, after system initialization, network performance metrics are continuously monitored, and a dynamic threshold and continuous anomaly detection mechanism are employed. Only when network metrics exceed the dynamically adjusted threshold multiple times consecutively, such as three times, is the system ultimately determined to be a reliable network outage event, effectively avoiding false judgments caused by brief fluctuations. Upon triggering a network outage event, the system immediately activates its local cache. All data generated during this period is structured and categorized into different cache queues, ensuring data orderliness, traceability, and efficient management.
[0092] The system continuously monitors network recovery. Once a connection is available, the synchronization process begins, prioritizing incremental synchronization and breakpoint resumption to improve efficiency. During synchronization, conflict detection and intelligent adjudication are automatically performed to ensure eventual consistency between local and cloud data, and processing logs are generated. After synchronization is complete, the cache is cleared to release resources. Based on the data performance during this network outage and synchronization process, the system dynamically updates and optimizes the factor weights or parameters in the priority calculation model, forming a continuously self-optimizing closed-loop management system.
[0093] Device Examples Reference Figure 4 The diagram illustrates a logical block diagram of a data synchronization device according to an embodiment of the present invention. The device may include: The status determination module 310 is used to determine the network connection status between the gateway device and the cloud server based on the network performance indicators of the gateway device at multiple times. Storage module 320 is used to structure and classify the first operating data generated by all terminal devices connected to the gateway device when the network connection is disconnected. The synchronization module 330 is used to determine the priority of each terminal device based on multi-dimensional factors when the network connection state is restored to connection, and to synchronize the first running data of each terminal device and the second running data stored in the cloud server in sequence according to the priority; the multi-dimensional status factors are used to indicate the operating status of the terminal device.
[0094] Optionally, the state determination module includes: The threshold determination module is used to determine the preset threshold value corresponding to each network performance indicator based on the network operation status of the gateway device. The comparison module is used to compare each network performance indicator with the corresponding preset indicator threshold at preset time intervals; the preset time interval is dynamically changing. The status determination submodule is used to determine the network connection status based on the results of multiple consecutive comparisons.
[0095] Optionally, the storage module includes: The structuring module is used to struct the first running data for each piece of the first running data according to the timestamp of the first running data generation and the identifier of the terminal device; The storage submodule is used to store the structured instruction data in a first cache queue, store the structured device status data in a second cache queue, and store the structured log data in a third cache queue.
[0096] Optionally, the synchronization module includes: The weight determination module is used to determine the weight corresponding to each dimension factor; The scoring determination module is used to determine the first score of each dimension factor for each terminal device based on the first running data within a specified time window. The priority determination module is used to determine the priority of each terminal device based on the weight of each dimension factor and the first score.
[0097] Optionally, the score determination module includes: The first score determination submodule is used to determine the first score of the abnormal event factor based on whether the first operating data of the terminal device carries a warning tag; the warning tag is used to indicate that the terminal device has an abnormality. The second score determination submodule is used to determine the first score of the device activity factor based on the data generation frequency of the terminal device; the data generation frequency refers to the frequency at which the terminal device generates data within the specified time window and when the network connection is disconnected. The third score determination submodule is used to determine the first score of the user behavior heat factor based on the number of times the terminal device is used within the specified time window. The fourth score determination submodule is used to determine the first score of the data time information based on the timestamp of the first running data generated in the terminal device. The fifth score determination submodule is used to determine the first score of the device dependency relationship based on the association relationship between the terminal device and the other terminal devices.
[0098] Optionally, the synchronization module includes: The duration statistics module is used to, during the process of determining the priority, when the multi-dimensional factors of the terminal device meet the preset conditions, count the duration for which the multi-dimensional factors meet the preset conditions; the preset conditions are the conditions for adjusting the priority of the terminal device. The priority adjustment module is used to adjust the priority of the terminal device when the duration exceeds a preset duration; The priority locking module is used to maintain the priority of the terminal device unchanged after the priority of the terminal device is adjusted until the data synchronization of the terminal device is completed.
[0099] Optionally, the synchronization module includes: The judgment module is used to determine whether the first running data and the second running data are consistent during the synchronization process of the first running data and the second running data; The conflict resolution module is used to determine a third running data from the first running data and the second running data according to a preset rule in the event of inconsistency, and to synchronize both the first running data and the second running data as the third running data.
[0100] Optionally, the conflict resolution module includes: The judgment submodule is used to determine whether there is a user instruction, and if the user instruction exists, to determine the third running data according to the user instruction; The conflict resolution submodule is used to compare the timestamps carried by the first running data and the second running data in the absence of the user instruction, and to use the data with the later timestamp as the third running data.
[0101] Optionally, the conflict resolution module includes: A collection module is used to collect the first operating data of the terminal devices stored in each of the gateway devices; The adjudication module is used to determine whether the first operating data in each of the network devices is consistent. If they are inconsistent, the gateway device and other gateway devices shall conduct multiple rounds of adjudication to determine the third operating data from the first operating data.
[0102] In summary, the data synchronization device provided in this application can adapt to the differences in network environments of different devices through dynamic thresholds and dynamic sampling intervals. Combined with a continuous multiple anomaly confirmation mechanism, it achieves intelligent network outage detection with high accuracy and low false alarm rate. Structured data ensures strict timeliness and globally unique traceability of data, while classified storage achieves physical data isolation and management according to business priorities, greatly improving the efficiency of cache access and synchronization scheduling. The multi-dimensional factor fusion model covers multiple levels, realizing a comprehensive evaluation that is three-dimensional and close to real business needs. Dynamically configurable and remotely updated weights allow the scheduling strategy to be continuously optimized with business development. The anti-oscillation mechanism and priority locking mechanism jointly ensure that the scheduling order will not frequently jump due to short-term fluctuations, achieving the ultimate smoothness and stability of the scheduling process. A hierarchical adjudication rule is established, which provides conflict resolution paths while respecting user autonomy and can identify sources with higher credibility. For complex multi-gateway scenarios, a lightweight distributed consensus mechanism coordinated by the master node is introduced to effectively resolve cross-gateway data disagreements and ensure the eventual consistency of global data in a distributed deployment.
[0103] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.
[0104] Reference Figure 5 This is a structural block diagram of an electronic device for data synchronization provided in an embodiment of this application. Figure 5 As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store executable instructions, which cause the processor to execute the method of the aforementioned embodiment.
[0105] The processor can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable devices, transistor logic devices, hardware components, or any combination thereof. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.
[0106] The communication bus may include a path for transmitting information between the memory and the communication interface. The communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.
[0107] The memory may be ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or it may be EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory), magnetic tape, floppy disk, and optical data storage devices, etc.
[0108] This application also provides a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a processor of an electronic device (server or terminal), enables the processor to perform the methods of the foregoing embodiments.
[0109] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.
[0110] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.
[0111] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.
[0112] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0113] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0114] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0115] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0116] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.
[0117] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.
[0118] The above provides a detailed description of a data synchronization method, apparatus, electronic device, and readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A data synchronization method, characterized by, The method is applied to a gateway device, and comprises: determining a network connection state between the gateway device and a cloud server according to network performance indexes of the gateway device at multiple time points; in a case where the network connection state is disconnected, structuring and storing first running data generated by all terminal devices connected to the gateway device; when the network connection state is restored to connected, determining a priority of each terminal device based on multi-dimensional factors, and synchronizing the first running data of each terminal device and second running data stored in the cloud server in sequence according to the priority; the multi-dimensional state factors are used to indicate the running status of the terminal device.
2. The method of claim 1, wherein, The network performance indexes comprise multiple network performance indexes; the determination of the network connection state between the gateway device and the cloud server according to the network performance indexes of the gateway device at multiple time points comprises: determining a preset index threshold corresponding to each network performance index according to the network running status of the gateway device; comparing each network performance index and the corresponding preset index threshold every preset time interval; the preset time interval is dynamically changed; determining the network connection state according to the comparison results of multiple consecutive times.
3. The method of claim 1, wherein, The first running data comprises instruction data, device status data and log data; the structuring and storing of the first running data generated by all terminal devices connected to the gateway device in a case where the network connection state is disconnected comprises: for each first running data, structuring the first running data according to a time stamp at which the first running data is generated and an identifier of the terminal device; storing the structured instruction data to a first cache queue, storing the structured device status data to a second cache queue, and storing the structured log data to a third cache queue.
4. The method of claim 1, wherein, The determination of the priority of each terminal device based on multi-dimensional factors when the network connection state is restored to connected comprises: determining a weight corresponding to each dimension factor; for each terminal device, determining a first score of each dimension factor according to the first running data in a specified time window; determining the priority of each terminal device according to the weight of each dimension factor and the first score.
5. The method of claim 4, wherein, The multi-dimensional factors comprise at least three of an abnormal event factor, a device activity factor, a user behavior heat factor, data time information and a device dependency relationship; the determination of the first score of each dimension factor according to the first running data in a specified time window comprises at least three of the following: determining the first score of the abnormal event factor according to whether the first running data of the terminal device carries a warning label; the warning label is used to indicate that the terminal device has an abnormality; determining the first score of the device activity factor according to a data generation frequency of the terminal device; the data generation frequency refers to a frequency of data generation of the terminal device in the specified time window and when the network connection state is disconnected; determine a first score of the user behavior hotness factor according to a number of times the terminal device is used within the specified time window; determine a first score of the data time information according to time stamps at which the first running data is generated in the terminal device; determine a first score of the device dependency relationship according to an association relationship between the terminal device and the other terminal devices.
6. The method of claim 1, wherein, The method further includes: In the process of determining the priority, when the multi-dimension factors of the terminal device meet a preset condition, a duration that the multi-dimension factors meet the preset condition is counted; the preset condition is a condition for adjusting the priority of the terminal device; When the duration exceeds a preset duration, the priority of the terminal device is adjusted; After the priority of the terminal device is adjusted, the priority of the terminal device is maintained unchanged until data synchronization of the terminal device is completed.
7. The method of claim 1, wherein, The method further includes: In the process of synchronizing the first running data and the second running data, it is determined whether the first running data and the second running data are consistent; In the case of inconsistency, third running data is determined from the first running data and the second running data according to a preset rule, and the first running data and the second running data are both synchronized to the third running data.
8. The method of claim 7, wherein, The method further includes: It is determined whether there is a user indication, and in the case that the user indication exists, the third running data is determined according to the user indication; In the case that the user indication does not exist, time stamps carried by the first running data and the second running data are compared, and the data with the later time stamp is taken as the third running data.
9. The method of claim 7, wherein, The gateway device is connected with multiple gateway devices; The method further includes: The first running data of the terminal device stored in each of the gateway devices is collected; It is determined whether the first running data in each of the network devices is consistent, and in the case of inconsistency, multiple rounds of arbitration are performed by the gateway device and the other gateway devices to determine the third running data from the first running data.
10. A data synchronization apparatus, characterized by comprising: The apparatus includes: a state determining module configured to determine a network connection state between the gateway device and a cloud server according to network performance indexes of the gateway device at multiple time points; a storage module configured to, in the case that the network connection state is disconnected, structure and store first running data generated by all terminal devices connected with the gateway device. The synchronization module is configured to determine a priority of each terminal device based on a multi-dimensional factor when the network connection state is restored to connection, and to sequentially synchronize the first running data of each terminal device and the second running data stored in the cloud server according to the priority; the multi-dimensional state factor is configured to indicate the running state of the terminal device.
11. An electronic device, comprising: The electronic device includes a processor, a memory, a communication interface, and a communication bus, and the processor, the memory, and the communication interface complete communication with each other through the communication bus. The memory is configured to store executable instructions, and the executable instructions cause the processor to execute the method in any one of 1 to 9.
12. A readable storage medium, characterized by, When the instructions or transactions in the readable storage medium are executed by the processor of the electronic device, the electronic device can execute the method in any one of claims 1 to 9.
Citation Information
Cited By
A cold chain data double-flow adaptive alignment and intelligent evaluation method
CN122286099A