Equipment monitoring data synchronization method, system and device based on Redis registration

Abstract

The invention belongs to the technical field of Internet of Things, and discloses an equipment monitoring data synchronization method, system and device based on Redis registration, which can reduce the waste of system resources, abandon the mode of dual data acquisition by a center and sub-nodes, and realize the synchronization of the equipment monitoring data through the modes of sub-node acquisition, Redis registration and center synchronization. The redundant consumption of calculation, storage and network bandwidth is reduced; the problem that the center cannot acquire the data when the partial node fails is solved, and the center end can actively update the state based on the equipment information stored in the relational database through a lease renewing timeout processing mechanism, so that the continuity of the monitoring data is guaranteed; through Redis registration information (partial nodes and equipment) and a UUID unique identifier, accurate synchronization of data of the center end and the partial end is realized, and data conflict or confusion is avoided; and the method is suitable for a complex Internet of Things monitoring system with a distributed structure, and can flexibly meet the state information synchronization requirement of large-scale Internet of Things equipment.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) technology, and in particular relates to a Redis-based device monitoring data synchronization method, system, and apparatus. Background Technology

[0002] Existing complex IoT monitoring systems mostly adopt a distributed architecture, which leads to synchronization problems between the central and branch monitoring data:

[0003] The existing solution 1 (data collection from the center and branch nodes simultaneously) has the problem of wasting system resources, and repeated collection leads to redundant consumption of computing, storage and bandwidth resources;

[0004] The existing solution 2 (data collection by sub-nodes and reception by the center) has reliability flaws. If a sub-node fails (such as going offline or crashing), the center will be unable to obtain the device monitoring data of that sub-node, resulting in monitoring interruption.

[0005] The present invention aims to solve the problems of resource waste and insufficient reliability in data synchronization in the above-mentioned distributed IoT monitoring system.

[0006] Existing complex IoT monitoring systems, due to their distributed structure, have two main solutions for synchronizing status monitoring data, but both have significant drawbacks: Simultaneous data collection by the central and branch nodes: This solution achieves data "synchronization" by repeatedly collecting the same device status data from both the central and branch nodes, but it wastes system resources (such as computing power, storage space, and network bandwidth), especially in large-scale IoT device scenarios where redundancy is significant. Branch node collection, central reception: This solution involves branch nodes collecting device status data and then sending it to the central storage. While this reduces redundant collection, it relies entirely on the normal operation of the branch nodes. If a branch node fails (e.g., network interruption, hardware failure), the central node will be unable to receive data, leading to interruption of device status monitoring and affecting system reliability.

[0007] Therefore, there is an urgent need for a method that can both avoid resource waste and ensure data synchronization when node failures occur.

[0008] Based on the above analysis, the problems and shortcomings of the existing technology are as follows:

[0009] (1) Data collection by the center and branch nodes: This scheme achieves data "synchronization" by repeatedly collecting the status data of the same device through the center and branch nodes, but it will waste system resources (such as computing power, storage space, network bandwidth), especially in the scenario of large-scale IoT devices, the redundancy consumption is significant.

[0010] (2) Data collection by sub-nodes and data reception by the center: This scheme is responsible for collecting device status data by sub-nodes and then sending the data to the center for storage. Although it reduces redundant collection, it is completely dependent on the normal operation of the sub-nodes. If a sub-node fails (such as network interruption or hardware failure), the center will not be able to receive data, resulting in interruption of device status monitoring and affecting system reliability. Summary of the Invention

[0011] To address the problems existing in the prior art, this invention provides a Redis-based device monitoring data synchronization method, system, and apparatus.

[0012] This invention is implemented as follows: A device monitoring data synchronization method based on Redis registration includes:

[0013] Step 1, Node and Device Registration Process;

[0014] Step 2: Synchronize data between the central server and Redis;

[0015] Step 3, renewal timeout handling mechanism.

[0016] Furthermore, the node and device registration process:

[0017] After the sub-node starts up, it automatically sends a registration request to the Redis service and submits the sub-node registration information; at the same time, the sub-node synchronizes the registration information of the devices under its jurisdiction to Redis;

[0018] Redis receives and stores the registration information of sub-nodes and devices, forming a global node and device registry.

[0019] Furthermore, the central endpoint synchronizes data with Redis:

[0020] The central node polls the registration information in Redis at a preset period:

[0021] Regarding the registration information of sub-nodes: The central node extracts the service address and name information, updates the sub-node table in the local relational database, and ensures that the central end knows the location of all active sub-nodes;

[0022] Regarding device registration information: The central node distinguishes different devices based on their UUIDs and synchronizes the device model and the information of the branch node to which it belongs to the device table in the local relational database to ensure the consistency of device information;

[0023] Regarding device status information: The central node synchronizes the latest device status from Redis to MySQL in real time, ensuring that the status data stored at the central end is consistent with the real-time data collected by the branch nodes.

[0024] Furthermore, the renewal timeout handling mechanism:

[0025] The sub-nodes need to periodically send renewal requests to Redis to update the renewal time;

[0026] If the central node finds that a sub-node has exceeded the lease renewal timeout (exceeding a preset threshold, such as 5 minutes without renewal) during polling, it determines that the sub-node may be malfunctioning. At this time, the central node will proactively initiate a status update request based on the device information under the jurisdiction of the sub-node stored in the relational database, to ensure that even if the sub-node fails, the central node can still maintain the validity of the device status information.

[0027] Another objective of this invention is to provide a Redis-registered device monitoring data synchronization system, comprising:

[0028] Redis service: As a node registration and state information storage center, it stores three types of registration information;

[0029] Sub-node registration information: includes sub-node service address, service name, registration time, and renewal time;

[0030] Device registration information: includes the UUID, device model, and sub-node to which each device belongs;

[0031] Equipment status information: includes the equipment's real-time operating status and status update time;

[0032] Central node: Responsible for polling registration information in Redis, synchronizing data to the local relational database, and handling node renewal timeout logic;

[0033] Sub-nodes are responsible for collecting the status information of the devices under their jurisdiction, completing registration and renewal in Redis, and updating the device status information.

[0034] Relational database (central end): Stores synchronized sub-node information, device information, and status data, serving as the data benchmark for the central end.

[0035] Another object of the present invention is to provide a computer device including a memory and a processor, the memory storing a computer program, which, when executed by the processor, causes the processor to perform the steps of the Redis-based device monitoring data synchronization method.

[0036] Another object of the present invention is to provide a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the Redis-based device monitoring data synchronization method.

[0037] Another objective of this invention is to provide an information data processing terminal for implementing the Redis-based device monitoring data synchronization system.

[0038] Based on the above technical solutions and the technical problems solved, the advantages and positive effects of the technical solution to be protected by this invention are as follows:

[0039] Compared to the existing solution 1 (dual collection), this solution avoids duplicate data collection between the central and branch nodes by adopting the mode of "segmented node collection + Redis registration + central synchronization", which reduces the waste of system resources (computing, storage, bandwidth);

[0040] 2. Compared with the existing solution 2 (sending from multiple nodes + receiving from the center), this solution uses the Redis registration mechanism and lease renewal timeout handling to enable the center to actively update the status based on the historical device information stored in the relational database when a node fails, thus solving the problem of data acquisition interruption caused by node failure and improving system reliability.

[0041] 3. By managing Redis registration information and using UUID device unique identifiers, the accuracy and uniqueness of node and device information are ensured, avoiding conflicts or confusion during data synchronization.

[0042] 4. Automated synchronization and maintenance of device information: When a new device is added to a sub-node, the sub-node will synchronize the registration information (including UUID, etc.) of the new device to Redis. The central node can automatically identify and synchronize the device to the local relational database during the polling process. There is no need for manual input of the new device information at the central end, which greatly reduces the workload of system maintenance. Especially in the scenario of large-scale device addition, it can significantly improve maintenance efficiency.

[0043] 5. Reduce system resource waste: Abandon the dual data collection mode of central and branch nodes, and reduce redundant consumption of computing, storage and network bandwidth by collecting data at branch nodes, registering in Redis and synchronizing with the central node;

[0044] 6. Improve system reliability: The problem of "the center being unable to obtain data when a sub-node fails" has been solved. Through the lease renewal timeout handling mechanism, the center can actively update the status based on the device information stored in the relational database, ensuring the continuity of monitoring data.

[0045] 7. Ensure data consistency: By using Redis registration information (nodes, devices) and unique UUID identifiers, accurate synchronization of data between the central and branch ends is achieved, avoiding data conflicts or confusion;

[0046] 8. High adaptability: It is suitable for complex IoT monitoring systems with distributed structures and can flexibly meet the needs of synchronizing status information of large-scale IoT devices.

[0047] (1) The expected benefits and commercial value of the technical solution of this invention after transformation are as follows:

[0048] This technical solution can significantly reduce the operation and maintenance costs of IoT monitoring systems, minimize the waste of computing, storage, and bandwidth resources caused by redundant data collection and transmission, and improve system reliability and data consistency. It has high commercialization value in large-scale equipment monitoring scenarios such as smart cities, industrial IoT, and smart homes. It is expected to save enterprises more than 20% in resource costs and improve the availability of monitoring systems to over 99.9%, demonstrating strong market competitiveness and economic potential.

[0049] (2) The technical solution of this invention fills a technical gap in the industry both domestically and internationally:

[0050] Currently, there is no dual-protection solution combining Redis registration mechanism and lease renewal timeout handling in distributed IoT monitoring systems, either domestically or internationally. This invention introduces Redis as the registration center, combined with a central active polling and failover mechanism, effectively solving the problems of resource waste and single point of dependency, and filling the technological gap in this field for efficient and reliable data synchronization.

[0051] (3) The technical solution of the present invention solves a technical problem that people have long wanted to solve but have never been able to solve successfully:

[0052] Traditional solutions present a contradiction between "resource conservation" and "reliability assurance," making it impossible to achieve both simultaneously. This invention, through a triple mechanism of "segmented node registration + central proactive synchronization + lease renewal timeout handling," achieves, for the first time, uninterrupted data synchronization in the event of segmented node failures while ensuring low resource consumption, thus solving a long-standing technical problem that has not been adequately addressed.

[0053] (4) The technical solution of the present invention overcomes technical bias:

[0054] Traditional technical biases hold that a central endpoint must actively collect data to avoid relying on branch nodes, otherwise data continuity cannot be guaranteed. This invention, through Redis registration and renewal mechanisms, enables the central endpoint to maintain state updates based on historical information even when branch nodes fail. This overcomes the traditional technical biases of "the central endpoint must actively collect data" or "complete dependence on branch nodes," providing a new data synchronization paradigm. Attached Figure Description

[0055] Figure 1 This is a flowchart of a device monitoring data synchronization method based on Redis registration provided in an embodiment of the present invention.

[0056] Figure 2 This is a node registration diagram provided in an embodiment of the present invention.

[0057] Figure 3 This is a node device status diagram provided in an embodiment of the present invention.

[0058] Figure 4 This is a node online status diagram provided in an embodiment of the present invention.

[0059] Figure 5 This is a central node polling and status acquisition diagram provided in an embodiment of the present invention.

[0060] Figure 6 This is a block diagram of a Redis-registered device monitoring data synchronization system provided in an embodiment of the present invention.

[0061] Figure 7 This is a resource consumption reduction monitoring report graph provided in an embodiment of the present invention.

[0062] Figure 8 This is a network bandwidth usage monitoring report diagram provided in an embodiment of the present invention.

[0063] Figure 9 This is a system reliability monitoring report diagram provided in an embodiment of the present invention.

[0064] Figure 10 This is a data consistency assurance monitoring report diagram provided in an embodiment of the present invention.

[0065] Figure 11 This is a monitoring report diagram for improving operation and maintenance efficiency provided in an embodiment of the present invention.

[0066] Figure 12 This is a system response time monitoring report diagram provided in an embodiment of the present invention. Detailed Implementation

[0067] In existing equipment monitoring systems, the registration of distributed nodes and the maintenance of equipment information generally rely on single-machine databases or message queues. This is prone to access bottlenecks and consistency issues as the number of nodes expands. Especially in the Industrial Internet of Things (IIoT) environment, hundreds or thousands of sensor devices need to report their status information in real time. If relying solely on traditional database write methods, the central endpoint cannot guarantee rapid updates of registration data and high-frequency synchronization of device status, leading to delays or data loss in monitoring data and affecting the accuracy of fault warnings and maintenance decisions. This problem is particularly prominent in large-scale deployments, directly restricting the reliable application of monitoring systems in energy, manufacturing, and smart city industries.

[0068] This method introduces Redis as a registration and state caching layer, unifying the registration data of sub-nodes and devices into a high-performance in-memory database. Redis has fast key-value pair access and expiration control mechanisms, naturally capable of handling the dynamic registration needs of a large number of nodes. Sub-nodes submit registration requests upon startup and write the unique identifier and model information of their managed devices into Redis, forming a real-time updated global registry. Compared to centralized architectures relying on a single relational database, this registration model significantly improves write efficiency and query concurrency, ensuring low latency and high reliability in the registration process.

[0069] During data synchronization, the central endpoint no longer passively relies on node pushes but actively pulls the latest registration information and device status from Redis through a preset polling cycle. This approach ensures the integrity of the central database while leveraging Redis's high-speed query capabilities to keep data synchronization latency within milliseconds. Through periodic comparisons, the central relational database can maintain a consistent device list and status information with the distributed nodes at all times, thereby providing accurate data support for upper-layer applications and enabling a global understanding of the dynamic topology of the distributed nodes and the operational status of the devices.

[0070] The introduction of a lease renewal mechanism addresses the industry pain point of untimely identification of distributed node failures. Sub-nodes need to periodically update their lease renewal timestamps, and the central endpoint can quickly detect any nodes that have not renewed their leases during polling. If a sub-node has not renewed its lease for more than 5 minutes, the system automatically determines that the node may be offline or has malfunctioned, and initiates a status update request based on the node's device information stored in the relational database. This process ensures that the monitoring system maintains the validity of device status even in the event of node failure, avoiding gaps in critical monitoring data, and is of great significance for ensuring the continuity and safety of industrial production processes.

[0071] The core principle of this method lies in unifying the registration, renewal, and status reporting of distributed nodes through Redis, forming a lightweight dynamic registry center. Redis's in-memory storage capabilities ensure high concurrency for data writing and reading, while the central database assumes the responsibility for eventual consistency, achieving layered management of hot and cold data. As a globally visible index structure, the registry maintains data integrity and rapid response even under concurrent access from multiple nodes, providing a technical foundation for real-time performance and stability in large-scale device monitoring scenarios.

[0072] At the industrial application level, this method effectively supports the real-time monitoring needs of large-scale distributed equipment in scenarios such as power dispatching, rail transit operation and maintenance, and smart factory production line monitoring. Through the Redis registration architecture, enterprises can achieve rapid synchronization of high-frequency data at a lower cost, reducing data latency and consistency risks caused by database performance bottlenecks. Meanwhile, the lease renewal timeout mechanism ensures the high availability of the monitoring system, enabling the central terminal to maintain continuous recording of equipment operation data even in the event of node anomalies, providing solid data support for subsequent fault diagnosis, energy consumption analysis, and predictive maintenance.

[0073] like Figure 1 As shown in the figure, the device monitoring data synchronization method based on Redis registration provided by this embodiment of the invention includes the following steps:

[0074] S101, Node and device registration process;

[0075] S102, data synchronization between the central terminal and Redis;

[0076] S103, Renewal Overtime Handling Mechanism.

[0077] like Figure 2 , Figure 3 , Figure 4 As shown, the node and device registration process provided in this embodiment of the invention is as follows:

[0078] After the sub-node starts, it automatically sends a registration request to the Redis service, submitting the sub-node registration information (service address, name, etc.); at the same time, the sub-node synchronizes the registration information of the devices under its jurisdiction (using UUID as a unique identifier, including device model, etc.) to Redis;

[0079] Redis receives and stores the registration information of sub-nodes and devices, forming a global node and device registry.

[0080] The device monitoring data synchronization method based on Redis registration provided in this invention first achieves unified system management through the registration process between nodes and devices. Specifically, when a sub-node starts up, it automatically sends a registration request to the Redis service and submits registration data containing basic information such as the sub-node service address and name, so that Redis can identify and manage the sub-node globally.

[0081] Secondly, each node not only needs to register itself, but also actively synchronizes the registration information of the devices under its jurisdiction to Redis. Device registration information uses a UUID as a unique identifier, and also includes key data such as device model, configuration parameters, and running role. This method ensures the uniqueness and traceability of devices in the system, avoiding problems such as duplicate registration or identification confusion.

[0082] Secondly, Redis, acting as a central high-speed cache database, receives and stores the registration information of individual nodes and devices, forming a global node and device registry. This registry not only provides a unified index but also lays the data foundation for subsequent status queries, task scheduling, and data synchronization. Leveraging Redis's in-memory capabilities, the registry enables fast read and write operations, thereby improving the overall system response efficiency.

[0083] Meanwhile, the node and device registration process also involves a synchronization mechanism with the central endpoint. The central endpoint can dynamically detect newly added or changed nodes and devices in the system based on the registration information in Redis, thereby enabling centralized monitoring and management. This synchronization mechanism ensures that the central endpoint always has a view consistent with the actual operating environment, facilitating unified scheduling and cross-node task coordination.

[0084] Finally, after registration, the entire system forms a multi-level registration relationship of "sub-nodes—devices—Redis—central terminal". This process not only lays the foundation for device monitoring data synchronization, but also achieves globally consistent data registration and management through Redis's efficient processing capabilities, thus providing solid support for subsequent status detection, fault handling, and lease renewal mechanisms.

[0085] like Figure 5 As shown in the embodiment of the present invention, the central terminal synchronizes data with Redis:

[0086] The central node polls the registration information in Redis at a preset period:

[0087] Regarding the registration information of sub-nodes: The central node extracts information such as service address and name, updates the sub-node table in the local relational database, and ensures that the central end knows the location of all active sub-nodes;

[0088] Regarding device registration information: The central node distinguishes different devices based on their UUIDs and synchronizes information such as device model and associated sub-node to the device table in the local relational database to ensure the consistency of device information;

[0089] Regarding device status information: The central node synchronizes the latest device status (such as running parameters and online status) from Redis to MySQL in real time, ensuring that the status data stored at the central end is consistent with the real-time data collected by the branch nodes.

[0090] The renewal timeout handling mechanism provided in this embodiment of the invention:

[0091] The sub-nodes need to periodically send renewal requests to Redis (e.g., every 30 seconds) to update the renewal time;

[0092] If the central node finds that a sub-node has exceeded its lease renewal timeout (exceeding a preset threshold, such as 5 minutes without renewal) during polling, it determines that the sub-node may be malfunctioning. At this time, the central node will proactively initiate a status update request based on the device information under the jurisdiction of the sub-node stored in the relational database (such as attempting to connect through historical service addresses or inferring the temporary status based on the device's status model before it went offline), to ensure that even if the sub-node fails, the central node can still maintain the validity of the device status information.

[0093] like Figure 6 As shown in the figure, an embodiment of the present invention provides a device monitoring data synchronization system based on Redis registration, comprising:

[0094] Redis service: As a node registration and state information storage center, it stores three types of registration information;

[0095] Sub-node registration information: includes sub-node service address, service name, registration time, renewal time, etc.;

[0096] Device registration information includes each device's UUID (Unique Identifier), device model, and associated sub-node.

[0097] Device status information includes the device's real-time operating status (such as online / offline, parameter values, etc.) and status update time.

[0098] Central node: Responsible for polling registration information in Redis, synchronizing data to the local relational database, and handling node renewal timeout logic;

[0099] Sub-nodes are responsible for collecting the status information of the devices under their jurisdiction, completing registration and renewal in Redis, and updating the device status information.

[0100] Relational database (central end): Stores synchronized sub-node information, device information, and status data, serving as the data benchmark for the central end.

[0101] Another object of the present invention is to provide a computer device including a memory and a processor, the memory storing a computer program, which, when executed by the processor, causes the processor to perform the steps of the Redis-based device monitoring data synchronization method.

[0102] Another object of the present invention is to provide a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the Redis-based device monitoring data synchronization method.

[0103] Another objective of this invention is to provide an information data processing terminal for implementing the Redis-based device monitoring data synchronization system.

[0104] 1. Redis, acting as the registry center, employs a key-value storage structure, combined with hash types to organize registration information for different nodes and devices, ensuring both efficient querying and atomic updates. The specific design is as follows:

[0105] 1) Storage of sub-node registration information

[0106] Key format: node:{node_id}

[0107] Value type: Hash

[0108] Field definition:

[0109] address: Service address of the sub-node (e.g., 192.168.1.10:8080) name: Sub-node name register_time: Registration time lease_time: Lease renewal time

[0110] Example:

[0111] HSET node:1001address"192.168.1.10:8080"HSET node:1001name"factory-1"

[0112] HSET node:1001register_time 1695000000

[0113] HSET node:1001lease_time 1695000300

[0114] 2) Storage of equipment registration information

[0115] Key format: device:{device_uuid}

[0116] Value type: Hash

[0117] Field definition:

[0118] model: Device model; node_id: ID of the associated sub-node; register_time: Registration time.

[0119] Example:

[0120] HSET device:a1b2c3d4 model"sensor-001"HSET device:a1b2c3d4 node_id"1001"

[0121] HSET device:a1b2c3d4 register_time 1695000010

[0122] 3) Storage of device status information

[0123] Key format: device_status:{device_uuid}

[0124] Value type: Hash

[0125] Field definition:

[0126] status: Device status (e.g., online / offline)

[0127] params: Runtime parameters (JSON string, such as {"temp":25.3,"humidity":60})

[0128] update_time: Status update time (Unix timestamp)

[0129] Example:

[0130] HSET device_status:a1b2c3d4 status "online"

[0131] HSET device_status:a1b2c3d4 params"{\"temp\":25.3,\"humidity\":60}"

[0132] HSET device_status:a1b2c3d4 update_time 1695000310

[0133] 4) Uniqueness Guarantee Mechanism

[0134] Node uniqueness: node_id is uniformly assigned by the system or generated based on the node's MAC / IP, ensuring global uniqueness; Redis's key uniqueness naturally guarantees that node information will not be duplicated.

[0135] Device uniqueness: The device_uuid uses a globally unique identifier (such as UUID v4), which is generated by the device or sub-node. Before writing to Redis, it is ensured that it is not written repeatedly by SETNX (SET ifNot eXists) or HSETNX.

[0136] Atomic update:

[0137] When renewing a lease for a node, use HSET atomically to update the lease_time field.

[0138] When updating device status, multiple fields are updated at once using HMSET to avoid data inconsistencies caused by partial updates.

[0139] 5) Global Registry Implementation

[0140] The "global node and device registry" is a logical concept, implemented through the following Redis data structure:

[0141] Node list: Uses a Set type to maintain all active sub-node IDs, with the key being active_nodes and the value being all node_ids.

[0142] SADD active_nodes 1001

[0143] Device list: Maintain all registered device UUIDs using a Set type, with the key being registered_devices and the value being all device_uuids.

[0144] SADD registered_devices a1b2c3d4

[0145] The association between sub-nodes and devices is established through the node_id field in the device registration information. The central node can traverse all devices and group them by node_id using SCAN or KEYS.

[0146] 2. Polling Implementation Method

[0147] To avoid the performance issues associated with the KEYS command, this invention employs the SCAN command for efficient, incremental traversal, combined with a preset key prefix to accurately scan the target data. The specific logic is as follows:

[0148] Polling of information by sub-node

[0149] Scanning Key prefix: node:

[0150] Example command:

[0151] SCAN 0MATCH node:*COUNT 100

[0152] The central node maintains a cursor, which iterates through the nodes at a preset interval (e.g., 10 seconds) to gradually acquire information about all the sub-nodes.

[0153] Equipment Information Polling

[0154] Scan Key prefix: device:

[0155] Example command:

[0156] SCAN 0MATCH device:*COUNT 100

[0157] Device status polling

[0158] Scanning Key Prefix: device_status:

[0159] Example command:

[0160] SCAN 0MATCH device_status:*COUNT 100

[0161] Note: The polling period can be configured according to the system size (e.g., 10 seconds to 1 minute). Using SCAN can avoid Redis blocking caused by traversing all keys at once, ensuring the stability of the production environment.

[0162] 1) Explanation of the relationship between "real-time synchronization" and polling

[0163] In this invention, "real-time synchronization" means that once the state data is updated in Redis, the central endpoint will complete the synchronization within the most recent polling cycle, rather than pushing it in real time at the millisecond level. If lower latency is required, the Redis Pub / Sub mechanism can be introduced as a supplement.

[0164] When a node updates its device status, it also publishes a message to the device_status_updates channel.

[0165] The central terminal subscribes to the channel, and once a message is received, it immediately triggers a state synchronization for that device, thereby achieving near real-time updates.

[0166] 2) Atomicity and consistency guarantees for data synchronization

[0167] To ensure data consistency during the Redis→MySQL synchronization process, this invention adopts a "log-first + transaction-based update" strategy:

[0168] Write Log (WAL)

[0169] After reading data from Redis, the central node first writes the data to be updated into the local transaction log table (such as sync_log), and marks the status as pending.

[0170] The log records include: device_uuid, status_data, version (optimistic locking version number), and timestamp.

[0171] MySQL transaction update

[0172] When executing MySQL UPDATE, version number control is used:

[0173] SQL

[0174] UPDATE device_state

[0175] SET status=? ,update_time=?

[0176] WHERE device_uuid=? AND version=? ;

[0177] If the update is successful, change the log status to "completed"; if it fails (version conflict), fetch the latest data from Redis again and try again.

[0178] Crash recovery mechanism

[0179] When the central node starts up or recovers from a failure, it first checks the records in the sync_log that are in a pending state;

[0180] Re-perform the synchronization operation on these records to ensure that no incomplete synchronization tasks are lost.

[0181] Deduplication and Idempotency

[0182] In Redis, device status is based on update_time as the version number.

[0183] During synchronization, updates are only performed if the update_time in Redis is greater than the time already recorded in MySQL, thus avoiding duplicate synchronization of old data.

[0184] 3.1) Renewal Parameter Design and Collaboration

[0185] Renewal interval: Each node sends a renewal request to Redis every 30 seconds (updating the lease_time field). This value is less than the subsequent timeout threshold to ensure that no false faults are detected under normal network jitter.

[0186] Timeout threshold: The timeout period for the central node to determine the failure of a branch node is 5 minutes (300 seconds). This threshold is designed to be 10 times the lease renewal interval, which can quickly detect the real node failure while ensuring a low false positive rate.

[0187] Collaborative relationships:

[0188] Renewal interval << timeout threshold

[0189] This reduces network overhead (moderate renewal frequency) and tolerates short-term network latency or node lag, avoiding unnecessary failover.

[0190] 2) Specific technical means of fault switching

[0191] When the central node detects that the lease_time of a certain branch node has expired through polling, it performs the following steps:

[0192] Try direct connection

[0193] Read the historical service address of this sub-node from the relational database;

[0194] Attempt to establish a TCP / HTTP connection and send a status fetch request;

[0195] If the connection is successful, immediately synchronize the latest status of all devices under this node and update the lease_time in Redis.

[0196] Degradation strategy after connection failure

[0197] If a direct connection fails, the central node initiates a status prediction mechanism:

[0198] Based on the device's five most recent historical status data (stored in MySQL), the current status is predicted using exponential smoothing.

[0199] Set reasonable fluctuation ranges for key indicators (such as temperature and voltage), and mark those that exceed the range as uncertain.

[0200] Write the predicted state to Redis and MySQL, and mark it with source:predicted for later verification.

[0201] Automatic calibration after node recovery

[0202] When the faulty sub-node recovers and re-registers, the central node will receive its new lease_time update;

[0203] Immediately trigger a full state synchronization, overwrite the previous speculative value with real data, and change the source back to actual.

[0204] 3) Details of the state prediction model

[0205] State prediction uses exponential smoothing, and the formula is as follows:

[0206] S_t=α*x_t+(1-α)*S_{t-1}

[0207] Where α = 0.6, S_t is the predicted value, and x_t is the most recent actual observation value; when the deviation between the predicted value and the previous actual value exceeds a preset threshold (e.g., 10%), the device status is marked as "uncertain".

[0208] 4) Conflict and Repetition Avoidance Strategies

[0209] To prevent conflicts between data actively acquired by the central node and data reported by the branch nodes:

[0210] Version control: All status data carries an update_time timestamp, and only the data with the latest timestamp is retained during synchronization;

[0211] Source tagging: Add a source field (actual / predicted) to MySQL and Redis to ensure that speculative data does not overwrite subsequent actual data;

[0212] Atomic updates: Using Redis HSET and MySQL UPDATE...WHERE... statements with conditional checks, ensure that writes are only performed when new data timestamps are updated.

[0213] 4.1) Redis node-based operations

[0214] Communication protocol: TCP

[0215] Interface: Redis Native Protocol (RESP)

[0216] Data format:

[0217] Node registration: Hash(node:{node_id})

[0218] Device registration: Hash(device:{device_uuid})

[0219] Device status: Hash(device_status:{device_uuid})

[0220] Core commands:

[0221] Registration: HMSET

[0222] Lease renewal: HSET node:{node_id}lease_time{timestamp}

[0223] Status update: HMSET device_status:{device_uuid}...

[0224] 2) Central node operations on Redis

[0225] Communication protocol: TCP

[0226] Interface: Redis Native Protocol (RESP)

[0227] Core commands:

[0228] Polling: SCAN (matches prefixes node:*, device:*, device_status:*)

[0229] Data retrieval: HGETALL

[0230] 3) Central Node relational database

[0231] Communication protocol: TCP / IP

[0232] Interface: JDBC

[0233] Data format: SQL

[0234] Transaction Guarantee:

[0235] Use database transactions (BEGIN / COMMIT / ROLLBACK)

[0236] 4) Central node operates branch nodes (in case of failure)

[0237] Communication protocol: HTTP

[0238] Interface: RESTful API

[0239] Data format: JSON

[0240] Core Interfaces:

[0241] GET / api / node / status (Retrieve device status)

[0242] I. Specific application areas or related products of this invention.

[0243] This invention can be widely applied to various distributed Internet of Things (IoT) monitoring systems, including but not limited to:

[0244] 1. Industrial Internet of Things (IIoT) device status monitoring and maintenance platform;

[0245] 2. Public facility monitoring systems in smart cities (such as smart streetlights, manhole covers, environmental monitoring equipment, etc.);

[0246] 3. Smart home and building management system (BMS);

[0247] 4. Sensor network monitoring in agricultural IoT;

[0248] 5. Synchronization of terminal device status in Vehicle-to-Everything (V2X) network;

[0249] Related products include, but are not limited to: equipment monitoring cloud platform, edge computing gateway, IoT middleware, intelligent operation and maintenance management system, etc.

[0250] II. Through actual deployment testing and simulation environment verification, the embodiments of the present invention demonstrate the following technical effects:

[0251] Table 1. Trend of synchronization delay as a function of equipment size

[0252]

[0253] Table 2. Comparison of the effects of active recovery and data completion at the central end after a node failure.

[0254]

[0255] 1. Reduced resource consumption: Compared to the dual-acquisition scheme, computational resources are reduced by approximately 35%, and network bandwidth usage is reduced by approximately 40%; for example... Figure 7 , Figure 8 ;

[0256] 2. Improved system reliability: Even under simulated fault scenarios at individual nodes, the central system can still maintain over 95% validity of its status data; for example... Figure 9 ;

[0257] 3. Data consistency guarantee: Through the unique UUID identifier and Redis registration mechanism, the accuracy of device information synchronization reaches 100%; such as Figure 10 ;

[0258] 4. Improved Operation and Maintenance Efficiency: New features include automatic device registration and synchronization, reducing manual intervention by over 90%; for example... Figure 11 ;

[0259] 5. System Response Time: The central polling cycle is configurable, and the status synchronization delay is controlled within seconds to meet real-time monitoring requirements; Figure 12 .

[0260] It should be noted that embodiments of the present invention can be implemented in hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by a suitable instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the above-described devices and methods can be implemented using computer-executable instructions and / or included in processor control code, for example, such code provided on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The devices and modules of the present invention can be implemented by hardware circuitry such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., or by software executed by various types of processors, or by a combination of the above-described hardware circuitry and software, such as firmware.

[0261] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications, equivalent substitutions, and improvements made by those skilled in the art within the scope of the technology disclosed in the present invention, and within the spirit and principles of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A device monitoring data synchronization method based on Redis registration, characterized in that, include: Step 1: After the sub-node starts up, it sends a registration request to the Redis service, submits the sub-node registration information, and synchronizes the registration information of the devices under its jurisdiction to Redis; Step 2: The central node polls Redis at a preset period to extract sub-node registration information, device registration information, and device status information, and synchronizes the information to the relational database at the central end. Step 3: The nodes periodically send renewal requests to Redis to update the renewal time; If the central node finds that a sub-node has not renewed its lease after exceeding a preset threshold during polling, it determines that the sub-node has failed and actively triggers a status update based on the device information of the sub-node already stored in the relational database.

2. The method as described in claim 1, characterized in that, The sub-node registration information includes the sub-node service address, service name, registration time, and renewal time.

3. The method as described in claim 1, characterized in that, The device registration information includes the device's unique identifier (UUID), device model, and the identifier of the sub-node to which it belongs.

4. The method as described in claim 1, characterized in that, The device status information includes the device's real-time operating status and status update time, and the central node synchronizes this status information to the MySQL database in real time.

5. A device monitoring data synchronization system based on Redis registration, characterized in that, include: Redis service is used to store node registration information, device registration information, and device status information. The central node is used to poll Redis, extract registration information and synchronize it to the relational database, and execute device status update logic when the lease renewal timeout occurs on the sub-nodes. Sub-nodes are used to collect status information of the devices under their jurisdiction and complete registration, lease renewal and status information updates. A relational database is used to store synchronized node information, device information, and device status data.

6. The system as described in claim 5, characterized in that, The central node is configured with a timed task, with a polling period of no more than 10 seconds.

7. An information data processing device, characterized in that, It includes a memory and a processor, wherein the memory stores program instructions, and when the processor executes the program instructions, it implements the device monitoring data synchronization method based on Redis registration as described in claim 1.

8. A computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the Redis-based device monitoring data synchronization method as described in claim 1.

9. An information data processing terminal, characterized in that, This is used to implement the Redis-registered device monitoring data synchronization system as described in claim 5.

10. The method as described in claim 1, characterized in that, The threshold for determining lease renewal timeout is 5 minutes. When the lease renewal time of a sub-node exceeds this threshold and is not updated, the central node automatically marks the sub-node as in a failed state and triggers the update operation of the corresponding device status in the relational database.

Images