Synchronization method and system based on state change log

Abstract

The invention discloses a synchronization method and system based on a state change log, and the method comprises the steps: a main device obtains an alarm state change event, records the state change log, and adds the state change log into a log queue; the slave device initiates a synchronization request to the master device, and the master device judges the consistency of the configuration version based on the synchronization request; if the configuration versions are consistent, the master device performs incremental synchronization condition judgment based on the synchronization request; if yes, the master device sends incremental update data to the slave device; otherwise, the master device sends the total update data to the slave device; the slave device performs incremental synchronization or full synchronization according to the received update data. Under the condition of the existing redundancy deployment master-slave mode, the log of the alarm state change is used as the basis of the alarm state synchronization, and the incremental synchronization and the full-amount synchronization between the master device and the slave device are judged, so that the data transmission pressure caused by frequently adopting the full-amount synchronization is effectively reduced, and the data transmission efficiency is improved. And the logic complexity of data synchronization is reduced.

Description

Technical Field

[0001] The present invention relates to the field of data management technology, and in particular to a synchronization method and system based on state change logs. Background Art

[0002] Data synchronization is a basic task in the field of data management. It is usually used to transfer data between different data systems to maintain the consistency and integrity of data between different systems. The application scenarios of data synchronization are very wide. For example, within an enterprise, data synchronization can be used to synchronize data from a production environment to a test environment or a development environment; in large websites or mobile applications, data synchronization can be used to synchronize user data from one server to another. In industrial systems, the current data synchronization generally adopts a 1:n redundant deployment mode, that is, a master device and corresponding multiple slave devices, and the slave device initiates a synchronization request to the master device for data synchronization. In this mode, each redundant node needs to ensure the consistency of external data, especially stateful data such as alarms. However, in the existing technical solutions, there is still a probability that the alarms will be inconsistent for different terminals, and the consistency of redundant nodes cannot be guaranteed externally. At the same time, data synchronization is mainly performed by regular full synchronization. When the amount of data accumulated is large, the full synchronization mode will increase the network burden of the system and increase the pressure of data transmission.

[0003] The "method and device for state synchronization between user devices" disclosed in the Chinese patent literature has a publication number of CN105530593A and a publication date of 2016-04-27, which is used to achieve state synchronization between user devices through SMS signaling. The technology provides a method for state synchronization between user devices, including: when the first user device determines that it needs to synchronize state with the second user device, it sends a state synchronization request to the second user device through SMS signaling, which carries state synchronization information; when the first user device receives the state synchronization response fed back by the second user device, it determines whether the state synchronization between the first user device and the second user device is successful according to the state synchronization response. This technology describes the synchronization of device status, not the alarm state synchronization method in the industrial system, and it is mainly used to synchronize with other devices in full synchronization mode, which is not suitable for the synchronization mode of honor deployment in the industrial system, and cannot guarantee the consistency of redundant nodes to the outside. At the same time, only using full synchronization is easy to increase the network burden of the system and increase the pressure of data transmission. Summary of the invention

[0004] The present invention aims to overcome the problem that the data synchronization methods of redundant deployment modes in industrial systems in the prior art cannot guarantee the consistency of redundant nodes to the outside world, and most of them only adopt a full synchronization method, which will increase the network burden of the system and increase the pressure of data transmission. A synchronization method and system based on a state change log are provided.

[0005] In order to achieve the above object, the present invention adopts the following technical solutions: A synchronization method based on a state change log, comprising: The main device obtains the alarm status change event, records the status change log and adds it to the log queue; The slave device initiates a synchronization request to the master device, and the master device determines the consistency of the configuration version based on the synchronization request; If the configuration versions are consistent, the master device performs incremental synchronization condition determination based on the synchronization request; If the conditions are met, the master device sends incremental update data to the slave device; otherwise, the master device sends full update data to the slave device; the slave device performs incremental synchronization or full synchronization based on the received update data.

[0006] The present invention proposes an alarm status synchronization method based on the characteristics of industrial field systems. In the case of the existing master-slave mode of redundant deployment, the log of alarm status changes is used as the basis for alarm status synchronization, and the incremental synchronization and full synchronization between the master device and the slave device are judged, which effectively reduces the data transmission pressure caused by the frequent use of full synchronization and reduces the logical complexity of data synchronization. Compared with the existing synchronization method in which the slave node unconditionally uses the content of the synchronized master node and cannot guarantee the consistency requirement, the present invention limits the consistency requirement of the configuration in the industrial scenario, and prioritizes whether the configuration version is consistent during the synchronization process. Only when the configuration version of the master and slave devices is consistent will the subsequent synchronization processing be performed, thereby ensuring the external consistency of the redundant nodes.

[0007] Preferably, the synchronization request initiated by the slave device to the master device includes the current configuration version of the slave device and the latest log sequence number held by the slave device; If the configuration version of the slave device is consistent with that of the master device, the master device performs an incremental synchronization condition judgment; Otherwise, the master device replies to the slave device that the configuration versions are inconsistent.

[0008] Preferably, the incremental synchronization condition judgment includes: If the latest log sequence number held by the slave device in the synchronization request is less than the earliest log sequence number held by the master device, or greater than the latest log sequence number currently recorded by the master device, the slave device does not meet the incremental synchronization condition; Otherwise, the slave device meets the incremental synchronization condition.

[0009] Preferably, after the slave device initiates a synchronization request to the master device, the master device receives the synchronization request and determines the current state; If the master device is in a reload state, it responds to the slave device that it is reloading, and the slave device receives the response and makes a full synchronization request; If the master device is not in the reload state, the master device performs a consistency check of the configuration version based on the synchronization request.

[0010] Preferably, the master device responds to the slave device that the configuration versions are inconsistent. After receiving the response that the configuration versions are inconsistent, the slave device synchronizes the configuration version archive of the master device with the master device, or issues an alarm for version inconsistency.

[0011] Preferably, the slave device performs incremental synchronization or full synchronization according to the received update data, including: If the slave device receives full update data, the current cache of the slave device is cleared, the cache is rebuilt using the full update data, and the latest log sequence number is updated; If incremental update data is received from the device, the alarm status is updated based on the incremental update data, and the latest log sequence number is updated at the same time.

[0012] Preferably, the state change log includes: Configuration version: the updated configuration version after receiving the configuration release instruction to add, delete and modify the alarm configuration; Log sequence number, the log sequence number of the current state change log, used to determine the incremental synchronization conditions during synchronization; Event types, including the generation and modification of alarms, and the creation of alarm configurations during synchronous operation; Change content, records the changed alarm attribute fields in the alarm status change event.

[0013] A synchronization system based on a state change log comprises: a master device and a plurality of slave devices synchronized with the master device; The master device obtains the alarm status change event, records the status change log and adds it to the log queue, and accepts the synchronization request of the slave device for response; The slave device sends a synchronization request to the master device, and synchronizes the configuration version archive or the alarm data based on the response of the master device.

[0014] Preferably, the main device comprises: A synchronization request processing module, processing synchronization requests from slave devices and responding to them; The alarm processing main module obtains the alarm data and saves it to the cache alarm main module; The event recording main module obtains the alarm status change event from the alarm data, records the status change log, and adds it to the log queue main module; The cache alarm main module and the log queue main module send update data to the slave device according to the synchronization response result of the synchronization request processing module.

[0015] Preferably, the slave device comprises: A synchronization request module, sending a synchronization request to the master device and receiving a response message from the master device; The alarm processing slave module synchronizes the update data from the master device to the alarm cache slave device; Event logging slave module, updates or retrieves log information from the log queue slave module.

[0016] The present invention has the following beneficial effects: in the case of the existing master-slave mode of redundant deployment, the log of alarm status changes is used as the basis for alarm status synchronization, and incremental synchronization and full synchronization between the master device and the slave device are judged, which effectively reduces the data transmission pressure caused by the frequent use of full synchronization and reduces the logical complexity of data synchronization; compared with the existing synchronization method in which the slave node unconditionally uses the content of the synchronized master node and cannot guarantee the consistency requirement, the present invention limits the consistency requirement of the configuration in an industrial scenario, and prioritizes whether the configuration version is consistent during the synchronization process. Only when the configuration version of the master and slave devices is consistent will the subsequent synchronization processing be performed, thereby ensuring the external consistency of the redundant nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a flow chart of the synchronization method based on the state change log in the present invention.

[0018] Figure 2 It is a schematic diagram of a synchronization system based on a state change log in the present invention.

[0019] Figure 3 It is a flow chart of a synchronization method in one embodiment of the present invention.

[0020] In the figure: 1. master device; 2. first slave device; 3. second slave device; 4. nth slave device; 11. alarm processing master module; 12. cache alarm master module; 13. event recording master module; 14. log queue master module; 15. synchronization request processing module; 21. alarm processing slave module; 22. cache alarm slave module; 23. event recording slave module; 24. log queue slave module; 25. synchronization request module. DETAILED DESCRIPTION

[0021] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments.

[0022] In industrial systems, the 1:n redundant deployment mode is commonly used. In this mode, each redundant node needs to ensure external consistency, especially stateful data such as alarms. However, the existing technical solutions cannot guarantee the external consistency of redundant nodes. At the same time, the alarm data between the master and slave devices is basically synchronized in a regular full synchronization manner, which increases the pressure of data transmission. In order to solve the problem of high data transmission pressure using the regular full synchronization method, the redis master-slave synchronization technology can be used. However, the redis technology only supports simple data such as integers and strings at the synchronization data level. The data is in the form of kv, and there is no configuration design. During synchronization, the slave node can unconditionally use the content of the master node. This feature makes the redis technology unsuitable for alarm data synchronization in industrial use scenarios with high requirements for configuration consistency. Therefore, it is necessary to provide a method for synchronizing alarm data for industrial systems, which can not only ensure the external consistency of redundant nodes, but also reduce the data transmission pressure caused by frequent full synchronization, and reduce the logical complexity of synchronization.

[0023] In order to solve the above problems, the following are provided: Figure 1 A synchronization method based on a state change log is shown, comprising: The main device obtains the alarm status change event, records the status change log and adds it to the log queue; The slave device initiates a synchronization request to the master device, and the master device determines the consistency of the configuration version based on the synchronization request; If the configuration versions are consistent, the master device performs incremental synchronization condition determination based on the synchronization request; If the conditions are met, the master device sends incremental update data to the slave device; otherwise, the master device sends full update data to the slave device; the slave device performs incremental synchronization or full synchronization based on the received update data.

[0024] It should be noted that the present invention proposes an alarm status synchronization method based on the characteristics of industrial field systems. In the case of the existing master-slave mode of redundant deployment, the alarm status change log is used as the basis for alarm status synchronization to perform incremental synchronization and full synchronization judgment between the master and slave devices, effectively reducing the data transmission pressure caused by frequent full synchronization and reducing the logical complexity of data synchronization; compared with the existing synchronization method in which the slave node unconditionally uses the content of the synchronized master node and cannot guarantee the consistency requirements, the present invention limits the consistency requirements of the configuration in the industrial scenario, and prioritizes whether the configuration version is consistent during the synchronization process. Only when the configuration versions of the master and slave devices are consistent will the subsequent synchronization processing be performed, thereby ensuring the consistency of the redundant nodes to the outside. It can not only reduce the synchronization scale of the master and slave devices in the normal mode, but also ensure the full recovery of the master and slave devices when they are abnormal.

[0025] It is worth noting that in industrial usage scenarios, there are requirements for the consistency of configuration versions. In the synchronization of the master-slave devices of the present invention, it is necessary to first determine whether the configuration versions of the master device and the slave device are compatible and consistent. Only when they are compatible and consistent can the synchronization mechanism continue; if they are not compatible and consistent, other business processing is required. In addition to the requirements for configuration consistency, there are also specific requirements for the alarm data synchronized in the industrial system, so it cannot be achieved through simple master-slave synchronization. Since the alarm data itself is a structured data, an alarm object itself contains dozens of attribute fields, and in the actual usage scenario, it contains alarm processing that is not defined in the configuration version. This requires the alarm data to additionally process the following content during synchronization: the construction of alarm definitions that are not defined in the configuration version, and the design of the synchronization information format for updating some attributes of the alarm. Thereby completing the synchronization of alarm data between the master device and the slave device.

[0026] Specifically, after the master device obtains the alarm data and receives the alarm state change event, it will record the state change log in a pre-set log record format and add it to the log queue of the master device. Every time the alarm information changes, the corresponding alarm state change event will be recorded, and the log queue in the master device will be continuously updated. The newly recorded state change log is added to the end of the log queue, and the slave device does not need to process the alarm state change at this time.

[0027] At the same time, the slave device sends a synchronization request to the master device. The synchronization request needs to carry information that can be used to determine the consistency of the configuration version and the incremental synchronization condition in the master device, so that the master device can process the received synchronization request and reply to the slave device with response information. The interval time can be set as needed so that the slave device can send synchronization requests to the master device regularly.

[0028] After receiving the synchronization request, the master device first performs a configuration version consistency judgment based on the information in the synchronization request. If the configuration version of the slave device in the synchronization request is inconsistent with the configuration version of the master device, the master device responds to the slave device that the configuration version is inconsistent. After receiving the response of inconsistent configuration version, the slave device synchronizes the configuration version archive of the master device with the master device to make the configuration version of the slave device consistent with that of the master device, and then makes the corresponding synchronization request. If the configuration version of the slave device in the synchronization request is consistent with that of the master device, the subsequent incremental synchronization condition judgment is performed.

[0029] When judging the incremental synchronization conditions, the master device judges whether the slave device meets the incremental synchronization conditions based on the information carried in the synchronization request sent by the slave device. If the slave device meets the incremental synchronization conditions, the master device sends incremental update data to the slave device, and the slave device updates the alarm status after receiving the incremental update data; if the slave device does not meet the incremental synchronization conditions, the master device sends full update data to the slave device, and the slave device rebuilds the cache based on the full update data. After completing the current data synchronization, the slave device continues to regularly send synchronization requests to the master device at the previously set time interval.

[0030] As a specific embodiment, the state change log includes: Configuration version: the configuration version updated after receiving the configuration release instruction to add, delete and modify the alarm configuration; Log sequence number, the log sequence number of the current state change log, used to determine the incremental synchronization conditions during synchronization; Event types, including the generation and modification of alarms, and the creation of alarm configurations during synchronous operation; Change content, records the changed alarm attribute fields in the alarm status change event.

[0031] It should be noted that the alarm status refers to the status of the current alarm in the system, including generation, confirmation, elimination and recovery, etc. The status change log is information that records the changes in the alarm status. This information is in chronological order and can be used to re-deduced the alarm status. That is, the alarm data is sorted out and its corresponding alarm status change events are recorded as a status change log in the set format. When synchronizing the slave device and the master device, data synchronization can be performed based on the status change log, so that the status change log and the corresponding alarm data after the synchronization are completed can be obtained from the slave device.

[0032] Specifically, the format of the state change log extracted from the alarm state change event record is protocol version + configuration version + log sequence number + alarm identifier + event type + change content, where the protocol version is the version of the data transmission communication protocol, the configuration version is the configuration version of the current main device, the log sequence number corresponds to the sequence mark of the state change log, the alarm identifier is the specific alarm mode, the event type corresponds to the specific event of the alarm, and the change content corresponds to the change amount in the alarm state change time. In this embodiment, since the alarm data is structured data, an alarm object itself contains dozens of attribute fields, so the change content is the changed alarm attribute field. The change content uses the kv storage method. The kv format is only used to describe the change content, not to describe the entire alarm data, because kv stores data and cannot use one alarm key to identify multiple alarm attribute data.

[0033] In actual implementation, event type definition examples include: alarm generation; alarm modification (when the alarm is modified to restore, the alarm object will naturally be removed from the existing cache, so there is no need to define alarm elimination), the modification content forms a change table in the format of changed attributes and attribute post-values; runtime alarm configuration creation, some alarms do not need to be defined in the released configuration version, they belong to alarms that need to be defined internally, such alarms need to be processed by the master device to create the configuration and synchronized to all slave devices. For the alarm configuration constructed by the master device itself, it means that there are a number of special alarms that inform the master device when the lower-level generation source generates an alarm. The alarm does not need to find the configuration in the configuration version, and the alarm configuration can be directly constructed during runtime. Therefore, it does not affect the update of the configuration version.

[0034] Alarm data is a structured data. Compared with the existing Redis synchronization technology that only supports simple data such as integers and strings, the alarm data synchronization process in the present invention will include alarm processing that is not defined in the configuration version in its actual usage scenario. This requires that the alarm data needs to additionally process the following content during synchronization: the construction of alarm definitions that are not defined in the configuration version; and the design of the synchronization information format for updating some alarm attributes.

[0035] Specifically, an alarm that is not defined in the configuration version does not mean that a certain attribute of the alarm is not defined, but that the alarm object is not defined in the configuration version archive. When creating an alarm object, the corresponding alarm configuration needs to be built at the same time, and the slave device also needs to synchronize this configuration configuration. Since there are alarm definitions that are not defined in the configuration version archive, at this time, the master device needs to establish the alarm configuration of the alarm object by itself, and serialize the configuration information, marked as a configuration build log, and push it into the log queue of the master device.

[0036] When designing the synchronization information format for updating some alarm attributes, it is necessary to combine the specific alarm business attribute definition. Some attributes will be defined based on different scenarios, but generally speaking, when defining some attribute changes of alarms, the id of the current alarm, the changed attribute identifier and the changed attribute value are serialized into a binary data, and the data is identified as the alarm status update log and pushed into the log queue.

[0037] As a specific embodiment, the synchronization request initiated by the slave device to the master device includes the current configuration version of the slave device and the latest log sequence number held by the slave device; If the configuration version of the slave device is consistent with that of the master device, the master device performs an incremental synchronization condition judgment; Otherwise, the master device replies to the slave device that the configuration versions are inconsistent.

[0038] It should be noted that the inconsistent configuration version means that the user has modified the alarm in the configuration software (mainly adding or deleting the alarm configuration), and due to some reasons, the configuration versions of the master and slave devices are incompatible. At this time, when the slave device requests synchronization with the master device, it will carry the configuration version information. The master device needs to first determine whether the configuration version information is consistent and then perform the corresponding logic. When the master device finds that the configuration version of the slave device is inconsistent with the configuration version of the master device, it needs to reject the synchronization request and inform the slave device of the error.

[0039] Furthermore, the master device responds to the slave device that the configuration version is inconsistent. After receiving the response that the configuration version is inconsistent, the slave device synchronizes the configuration version archive of the master device with the master device, or issues an alarm for version inconsistency.

[0040] Specifically, the configuration version in the present invention is a version update generated after the user modifies the alarm in the configuration software, which corresponds to the configuration release instructions from the engineer site or other sources during the operation process, and is the addition, modification or elimination of the alarm at the archive level; relative to the alarm configuration constructed by the main device itself, it refers to a batch of special alarms that inform the main device when the lower-level source generates an alarm. The alarm does not need to find the configuration in the configuration version archive, and the alarm configuration can be directly constructed during operation, so it does not affect the update changes of the configuration version.

[0041] After the slave device receives a response indicating that the configuration version is inconsistent, in order to ensure the external consistency of the redundant node, it needs to synchronize the configuration version archive of the master device with the master device so that the configuration version of the slave device is consistent with that of the master device, so as to facilitate the subsequent synchronization process. Optionally, the slave device can also issue an alarm for inconsistent configuration versions to inform users or professionals of the abnormality of inconsistent configuration versions, so as to facilitate subsequent maintenance and correction.

[0042] As a specific embodiment, the incremental synchronization condition determination includes: If the latest log sequence number held by the slave device in the synchronization request is less than the earliest log sequence number held by the master device, or greater than the latest log sequence number currently recorded by the master device, the slave device does not meet the incremental synchronization condition; Otherwise, the slave device meets the incremental synchronization condition.

[0043] It should be noted that incremental synchronization will significantly reduce the amount of synchronized data compared to full synchronization. Therefore, when performing data synchronization, you can first determine whether incremental synchronization is possible. If incremental synchronization is not possible, then consider full synchronization. This method can not only reduce the scale of data synchronization between master and slave devices in normal mode, but also ensure full recovery in the event of master-slave abnormalities.

[0044] Specifically, when the slave device periodically initiates a synchronization request to the master device, the request must carry the latest log sequence number Nfrom currently held by the slave device. After receiving the request from the slave device, the master device determines whether the slave device meets the conditions for incremental synchronization. If the latest log sequence number Nfrom carried by the synchronization request from the slave device is less than the earliest log sequence number Noldest held by the master device or greater than the latest log sequence number Nlatest currently recorded by the master device, the slave device does not meet the conditions for incremental synchronization. The master device will serialize all current data and send it to the slave device. Otherwise, the slave device meets the incremental synchronization conditions, and the master device will transfer the lagging log records of the slave device to the slave device.

[0045] Further, performing incremental synchronization or full synchronization from the device according to the received update data includes: If the slave device receives full update data, the current cache of the slave device is cleared, the cache is rebuilt using the full update data, and the latest log sequence number is updated; If incremental update data is received from the device, the alarm status is updated based on the incremental update data, and the latest log sequence number is updated at the same time.

[0046] As another optional embodiment, Figure 3 As shown, before judging the consistency of the configuration version, the reload status of the master device must also be judged.

[0047] After the slave device initiates a synchronization request to the master device, the master device receives the synchronization request and determines the current state; If the master device is in a reload state, it responds to the slave device that it is reloading, and the slave device receives the response and makes a full synchronization request; If the master device is not in the reload state, the master device performs a consistency check of the configuration version based on the synchronization request.

[0048] It should be noted that when requesting synchronization, the slave device attaches the configuration version information currently loaded by the slave device in the request, and the master device needs to make a comparison when receiving it. For example, due to the timing of reloading, when the master device completes the reload, the slave device may not have executed the reload. In this case, the master device cannot send the synchronization content to the slave device. After the reload, the slave device will perform a full synchronization due to the failure of the previous partial synchronization request.

[0049] It is worth noting that in order to ensure configuration consistency, configuration release instructions from the engineer site will be received during project operation, in which the alarm definition may be added, deleted, or modified. At this time, after receiving the synchronization request from the slave device, the master device responds to the slave device that the master device is in a reloaded state. After receiving the response, the slave device begins to try the full synchronization request. After the master device is reloaded, the master device compares the configuration version carried by the synchronization request from the slave device. If the versions are inconsistent, the master device refuses to synchronize data to the slave device and responds to the error of inconsistent versions. After receiving the response of inconsistent versions, the slave device can choose to synchronize the configuration version with the master device or report a system alarm.

[0050] In addition to a synchronization method based on a state change log, the present invention also provides Figure 2 A synchronization system based on a state change log is shown, comprising: a master device 1 and a plurality of slave devices synchronized with the master device 1; The master device 1 obtains the alarm status change event, records the status change log and adds it to the log queue, and responds to the synchronization request from the slave device; The slave device sends a synchronization request to the master device 1 , and synchronizes the configuration version archive or the alarm data based on the response of the master device 1 .

[0051] It should be noted that the present invention is a technical improvement based on the currently commonly used 1:n redundant deployment mode, so the basic framework of the system is still the connection between the master device 1 and several slave devices, that is, Figure 2 The master device 1 shown in FIG. 1 is connected to the first slave device 2 , the second slave device 3 to the nth slave device 4 respectively, and each slave device can send a synchronization request to the master device 1 to synchronize the alarm data.

[0052] Specifically, the main device 1 includes: A synchronization request processing module 15, which processes synchronization requests from slave devices and responds to them; The alarm processing main module 11 obtains the alarm data and saves it to the cache alarm main module 12; The event recording main module 13 obtains the alarm state change event from the alarm data, and records the state change log, and adds it to the log queue main module 14; The cache alarm main module 12 and the log queue main module 14 can store corresponding data and send updated data to the slave device according to the synchronization response result of the synchronization request processing module 15.

[0053] Furthermore, since the structure of each slave device is substantially the same, the first slave device 2 is taken as an example for description, and the first slave device 2 includes: A synchronization request module 25, which sends a synchronization request to the main device 1 and receives a response message from the main device 1; The alarm processing slave module 21 synchronizes the updated data from the master device 1 to the alarm cache slave device 22; The event record slave module 23 updates or retrieves the log information in the log queue slave module 24 .

[0054] Specifically, the alarm processing main module of the master device saves the acquired alarm data to the cache alarm main module, and sends the alarm data to the event recording main module. After the event recording main module receives the alarm state change event of the alarm data, it records it as a state change log in a pre-set log record format and adds it to the log queue main module of the master device. Every time there is a change in alarm information, the corresponding alarm state change event is recorded, and the log queue in the log queue main module of the master device is continuously updated. The newly recorded state change log is added to the end of the log queue, and the slave device does not need to process the alarm state change at this time.

[0055] At the same time, the synchronization request module of the slave device sends a synchronization request to the synchronization request processing module of the master device. The synchronization request needs to carry information that can be used to determine the consistency of the configuration version and the incremental synchronization condition in the master device, so that the synchronization request processing module of the master device can process the received synchronization request and reply to the synchronization request module of the slave device. The interval time can be set as needed so that the slave device can send synchronization requests to the master device regularly.

[0056] After receiving the synchronization request, the synchronization request processing module of the master device first performs a configuration version consistency judgment based on the information in the synchronization request. If the configuration version of the slave device in the synchronization request is inconsistent with the configuration version of the master device, the master device replies to the slave device that the configuration version is inconsistent. After receiving the response of inconsistent configuration version, the slave device synchronizes the configuration version archive of the master device with the master device to make the configuration version of the slave device consistent with that of the master device, and then makes the corresponding synchronization request. If the configuration version of the slave device in the synchronization request is consistent with that of the master device, the subsequent incremental synchronization condition judgment is performed.

[0057] When judging the incremental synchronization conditions, the master device judges whether the slave device meets the incremental synchronization conditions based on the information carried in the synchronization request sent by the slave device. If the slave device meets the incremental synchronization conditions, the synchronization request processing module in the master device retrieves the incremental update data from the cache alarm master module and the log queue master module, and sends the incremental update data to the synchronization request module of the slave device. After receiving the incremental update data, the slave device updates the alarm status and saves it to the cache alarm slave module. At the same time, the log sequence number of the slave device is updated to the latest and saved to the log queue slave module.

[0058] If the slave device does not meet the incremental synchronization conditions, the synchronization request processing module in the master device retrieves the full update data from the cache alarm master module and the log queue master module, and sends the full update data to the synchronization request module of the slave device. The slave device rebuilds the cache based on the full update data, fully synchronizes the data in the cache alarm slave module, and updates the log sequence number of the slave device to the latest and saves it to the log queue slave module. After completing the current data synchronization, the slave device continues to make synchronization requests to the master device regularly at the previously set time interval.

[0059] The above embodiments are further elaborations and illustrations of the present invention for ease of understanding, and are not limitations of the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A synchronization method based on state change log, characterized in that: include: The main device obtains the alarm status change event, records the status change log and adds it to the log queue; The slave device initiates a synchronization request to the master device, and the master device determines the consistency of the configuration version based on the synchronization request; If the configuration versions are consistent, the master device performs incremental synchronization condition determination based on the synchronization request; If satisfied, the master device sends incremental update data to the slave device; Otherwise, the master device sends the full update data to the slave device; The slave device performs incremental synchronization or full synchronization based on the received update data.

2. A synchronization method based on state change log according to claim 1, characterized in that: The synchronization request initiated by the slave device to the master device includes the current configuration version of the slave device and the latest log sequence number held by the slave device; If the configuration version of the slave device is consistent with that of the master device, the master device performs an incremental synchronization condition judgment; Otherwise, the master device replies to the slave device that the configuration versions are inconsistent.

3. A synchronization method based on state change log according to claim 1 or 2, characterized in that: The incremental synchronization condition judgment includes: If the latest log sequence number held by the slave device in the synchronization request is less than the earliest log sequence number held by the master device, or greater than the latest log sequence number currently recorded by the master device, the slave device does not meet the incremental synchronization condition; Otherwise, the slave device meets the incremental synchronization condition.

4. A synchronization method based on state change log according to claim 1 or 2, characterized in that: After the slave device initiates a synchronization request to the master device, the master device receives the synchronization request and determines the current state; If the master device is in a reload state, it responds to the slave device that it is reloading, and the slave device receives the response and makes a full synchronization request; If the master device is not in the reload state, the master device performs a consistency check of the configuration version based on the synchronization request.

5. A synchronization method based on state change log according to claim 2, characterized in that: The master device responds to the slave device that the configuration version is inconsistent. After receiving the response that the configuration version is inconsistent, the slave device synchronizes the configuration version archive of the master device with the master device, or issues an alarm for version inconsistency.

6. A synchronization method based on state change log according to claim 1, 2 or 5, characterized in that: The slave device performs incremental synchronization or full synchronization according to the received update data, including: If the slave device receives full update data, the current cache of the slave device is cleared, the cache is rebuilt using the full update data, and the latest log sequence number is updated; If incremental update data is received from the device, the alarm status is updated based on the incremental update data, and the latest log sequence number is updated at the same time.

7. A synchronization method based on state change log according to claim 6, characterized in that: The state change log includes: Configuration version: the configuration version updated after receiving the configuration release instruction to add, delete and modify the alarm configuration; Log sequence number, the log sequence number of the current state change log, used to determine the incremental synchronization conditions during synchronization; Event types, including the generation and modification of alarms, and the creation of alarm configurations during synchronous operation; Change content, records the changed alarm attribute fields in the alarm status change event.

8. A synchronization system based on state change log, applicable to the synchronization method according to any one of claims 1 to 7, characterized in that: include: A master device and a plurality of slave devices synchronized with the master device; The master device obtains the alarm status change event, records the status change log and adds it to the log queue, and accepts the synchronization request of the slave device for response; The slave device sends a synchronization request to the master device, and synchronizes the configuration version archive or the alarm data based on the response of the master device.

9. A synchronization system based on state change log according to claim 8, characterized in that: The master device comprises: a synchronization request processing module, processing the synchronization request from the slave device and responding to it; The alarm processing main module obtains the alarm data and saves it to the cache alarm main module; The event recording main module obtains the alarm status change event from the alarm data, records the status change log, and adds it to the log queue main module; The cache alarm main module and the log queue main module send update data to the slave device according to the synchronization response result of the synchronization request processing module.

10. A synchronization system based on state change log according to claim 8 or 9, characterized in that: The slave device comprises: A synchronization request module, sending a synchronization request to the master device and receiving a response message from the master device; The alarm processing slave module synchronizes the updated data from the master device to the alarm cache slave device; Event logging slave module, updates or retrieves log information from the log queue slave module.

Images