Integrated hardware peer-to-peer deployment-oriented cluster configuration synchronization system and method

Abstract

A cluster configuration synchronization system and method oriented to integrated hardware peer-to-peer deployment adopts a master-slave architecture, mainly comprises a request identification and forwarding unit, a synchronization resource abstraction and cluster synchronization unit, an input and output unit and the like, and adopts a read-write separation solution based on a request forwarding mode. According to the method, abstracted synchronization resources are extracted as a solution of synchronization log sharing, so that the purpose of data synchronization is achieved, the form of peer-to-peer deployment of multiple integrated hardware can be met, a general database is covered, the synchronization resources are flexibly defined, the fault detection efficiency is improved, and the configuration consistency of clusters is ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of computer data security, and in particular to a cluster configuration synchronization system and method for integrated hardware peer-to-peer deployment. Background Art

[0002] Hot standby refers to configuring two servers (primary server and backup server) in the system, which are connected through a high-speed network for real-time data synchronization and status synchronization. The primary server is responsible for processing user requests and business operations, while the backup server is on standby and synchronized with the primary server at all times. Under normal circumstances, the user's request will be processed by the primary server and the result will be returned, and the backup server will be in a silent state. However, once the primary server fails or becomes unavailable, the backup server will immediately take over the function of the primary server, become the new primary server, and continue to process user requests and business operations. The switching speed of this process is usually completed within a few seconds, which is almost imperceptible to the user, thus achieving high availability.

[0003] Real-time data synchronization technology is an important part of ensuring the normal operation of the system. Through continuous state synchronization, the backup server can completely replicate the operating status of the primary server, maintain data consistency, and be ready to take over the responsibilities of the primary server at any time.

[0004] The database read-write separation solution can be used to solve the configuration synchronization requirements. The well-known MySQL bin-log log synchronization is the current mainstream configuration synchronization solution. Its synchronization principle is master-slave replication. The master database (Master) saves all data change operation records in the bin-log and sends them to one or more slave databases (Slave) through the network. The slave database then applies the bin-log of the master database to its own database to achieve data synchronization. This solution recommends a separation deployment mode in which the application service is deployed first and the database service is deployed later to avoid the great security risks caused by the exposure of the database service. Therefore, it is not suitable for the form of multiple integrated hardware peer deployment of network security devices. Even if the database service is exposed to allow them to access each other, since the application service and the database service are deployed on the same platform, it will also lead to complex deployment topology and difficult problem troubleshooting. It is also not suitable for scenarios where network security devices need to perform additional operations after receiving synchronization data, such as additional inter-process communication and hardware operation requirements after synchronization data.

[0005] Secondly, the MySQL bin-log log synchronization solution only supports the MySQL database and has certain version requirements for the MySQL database, which does not meet the current localization needs; the port needs to be exposed and the database needs to be restarted during configuration; the definition of synchronization resources is not flexible enough, and it is impossible to control the database table synchronization blacklist and whitelist, and it is impossible to synchronize data other than the database; the current synchronization progress cannot be obtained externally, and some synchronization performance indicators cannot be obtained and counted; due to network delays, the slave database synchronization may not be able to immediately read the data after the write operation; the synchronization fault detection method is complex and cannot handle the abnormal scenario of cluster brain split.

[0006] Some other solutions implement configuration synchronization requirements by adding independent software services or hardware services, which greatly increases resource costs. In order to ensure the high availability of the additional services, additional resource consumption is inevitably brought about, and the difficulty of implementing and deploying operation and maintenance is greatly increased. Summary of the invention

[0007] The present disclosure provides a general configuration synchronization method and system for a multi-integrated hardware peer deployment mode, which can meet the needs of a multi-integrated hardware peer deployment mode, cover a general database and flexibly define synchronization resources, improve fault detection efficiency and ensure cluster configuration consistency.

[0008] The main functions realized by this disclosure are:

[0009] (1) Improve database coverage:

[0010] By utilizing MyBatis and JDBC, the dependency on database types is decoupled, and all databases that support JDBC connections are supported, such as Oracle, MS SQL, MySQL, Renda Jincang, DAMO, and other databases.

[0011] (2) Simplify the configuration management process:

[0012] Configuration synchronization can be enabled without deploying any additional software or hardware services, exposing any additional ports, or restarting any processes. This solves the problem that MySQL bin-log log synchronization configuration requires restarting the database process and opening the database access port, which increases security risks.

[0013] (3) Improve system flexibility and scalability:

[0014] You can customize the synchronization resources, which can be database data, file data, or even method calls. You can also customize the synchronization data blacklist, which improves the flexibility and scalability of the system to adapt to changing configuration requirements.

[0015] (4) Enhance the reliability of configuration synchronization:

[0016] By utilizing the message confirmation mechanism of the MQTT protocol, the reliability of configuration synchronization is improved to solve the configuration data conflict problem caused by a "split brain" failure in the cluster.

[0017] (5) Improve the maintainability of configuration synchronization:

[0018] By abstracting the synchronization data and managing it as a synchronization resource, we can solve problems such as the inability to view the current synchronization progress, the difficulty in statistically analyzing cluster synchronization performance, the complexity of synchronization fault detection methods, and the inability to actively report synchronization faults.

[0019] (6) Ensure the security of configuration data:

[0020] In the process of synchronizing configuration information, data security is an important consideration. The present disclosure includes security measures such as encrypted transmission and access control to protect configuration data from unauthorized access or tampering.

[0021] By solving the above technical problems, the present disclosure aims to provide an efficient, reliable, easy-to-manage and secure configuration synchronization solution suitable for software and hardware systems in a high-availability deployment mode of a cluster of multiple hardware devices.

[0022] 2. An overview of the overall concept or technical solution to solve the above technical problems

[0023] The present disclosure adopts a master-slave architecture to design a configuration synchronization solution: in a cluster, there will only be one master device (Master) and multiple slave devices (Slave) at the same time. In business interaction, user read and write operations are separated: all devices can process read operations, but at the same time only the master device (Master) can process read and write operations at the same time, and the remaining slave devices (Slave) can only process read operations. The master device (Master) can synchronize data to the slave device (Slave) in real time, and the slave device (Slave) can also actively obtain data from the master device (Master) for synchronization.

[0024] 2.1. Request forwarding

[0025] The first aspect of the present disclosure provides a read-write separation solution based on the "request forwarding" mode. Each time a device receives a request, it decides whether to process the request on the device itself or forward it to the master device (Master) to process the request based on the request type. Compared with the mainstream database read-write separation solution, it can more flexibly control the response timing to avoid the problem of not being able to read the data after the write operation due to synchronization delay from the slave device (Slave), and decouple the database. At the same time, the configuration is simple, and there is no need to expose the database service or restart the database process.

[0026] The core technologies of this technical solution are two-fold:

[0027] The first is to dynamically identify the request type and use the adapter pattern to achieve dynamic identification of requests. Two built-in adapters are provided: 1. The default design follows the RESTful API style and identifies the request type based on the HTTP protocol method. The GET method is used to read data, and the POST, PUT, and DELETE methods are used to write data. 2. Whitelist adapter. Requests matched by the URI whitelist will be identified as requests to read data to make up for special business situations that do not follow the RESTful API style. At the same time, it provides high scalability that complies with the open-closed principle, and developers can flexibly expand the adapter that best meets their own business needs.

[0028] The second is to forward the request to the master device (Master), by defining a Servlet container filter (Filter) to intercept and forward the request, identify the write operation in the filter (Filter), and create a long connection to send the request to the master device (Master), and wait for the response result. After receiving the response result, wait for the local data to be synchronized before responding to the front-end request. This technology can solve the problem that the slave device (Slave) cannot query the latest data when the data has not been synchronized after responding to the front-end request. Compared with setting up a load balancer on the front end of the Web service to forward requests, it is simpler to implement, has higher compatibility, and can save hardware resources. The use of long connections can effectively save network IO overhead.

[0029] 2.2. Abstract synchronization resources

[0030] The second aspect of the present disclosure provides a solution for sharing synchronization logs using abstract synchronization resources, including the definition of synchronization data, synchronization data encryption, and decentralized synchronization log sharing transmission. When processing a write operation, the master device (Master) serializes the synchronization resources generated by the write operation into a synchronization log, and encrypts and sends it to other slave devices (Slave). After receiving the synchronization log, the slave device (Slave) decrypts and writes it to achieve the purpose of data synchronization.

[0031] The core technologies of this technical solution are three points:

[0032] First, the data to be synchronized is abstracted as synchronization resources. In the present invention, synchronization resources are no longer limited to database data. Developers can customize synchronization resources, which can be database data, file data, synchronous execution code blocks, or developer-defined data types and synchronize customized data by developing data consumers based on the adapter mode. This technology can greatly improve the limitation of only synchronizing database data. The advantage is that it supports almost all databases that support the JDBC standard.

[0033] A blacklist can be defined for each synchronization resource, and the data resources of each device can be logically divided into a private area and a synchronization area. The logical architecture is clear. Compared with MySQL bin-log log synchronization, it can effectively avoid the impact of the lack of independence of device operation on the calculation of asynchronous data.

[0034] It supports executing custom pre- and post-business logic before and after data synchronization, greatly reducing the difficulty of developing hardware devices that need to synchronize hardware operations after synchronizing data.

[0035] The second is decentralized storage. The high availability of synchronized log data is ensured through the message confirmation mechanism. The minimum reachable number threshold (the minimum number of devices that successfully receive a synchronized log data) is configured to increase appropriate cluster fault tolerance while ensuring high availability of the cluster, thereby improving user experience.

[0036] At the same time, when the cluster configuration synchronization does not meet the minimum reachable number threshold, it supports active alarms, more timely notifications for operation and maintenance, and supports reminders such as emails, text messages, and Feishu.

[0037] By placing synchronized log data copies on different nodes to avoid single point failure problems, compared with using middleware storage and forwarding, it uses less resources, has simpler deployment and configuration, is less prone to errors, and does not require additional guarantees for the high availability of the middleware.

[0038] The third is self-recovery of offline devices. When the device starts, it can automatically identify the master device (Master) and other slave devices (Slave) in the cluster, and support automatic acquisition of missing synchronization log data from the master device (Master) or other slave devices (Slave) (the master device (Master) takes priority), and then provide services to the outside world after restoring to the same state as the cluster; if self-recovery fails, an alarm will be issued actively, supporting reminder methods such as email, SMS and Feishu.

[0039] Compared with users discovering node failures during use, this technology can significantly improve the efficiency of cluster fault detection, increase the exposure rate of abnormal phenomena, and reduce the difficulty of maintaining the cluster system.

[0040] 2.3. Resource Monitoring and Master Election

[0041] The third aspect of the present disclosure provides a solution for software and hardware resource monitoring and high-performance Master election, including: customized software and hardware resource monitoring, cluster heartbeat and Master election, brain split fault identification and other modules. Cluster heartbeat is one of the important mechanisms to maintain the healthy operation of the cluster; when the master device (Master) is offline, it is necessary to elect a new master device (Master) to take over the processing of write operations to ensure the high availability of the cluster; when a brain split fault is detected in the cluster, it is necessary to immediately suspend the service and actively issue an alarm notification, and continue to provide services after the cluster is manually or automatically restored to health.

[0042] The core technologies of this technical solution are three points:

[0043] First, it supports customized monitoring of software and hardware resources. In the integrated hardware deployment mode, whether the cluster node fails depends not only on whether the network is normal, but also on the resource load of CPU memory, disk IO, core process running status, network port connection status, etc. It supports customized monitoring probes, health value scores and exception handlers for objects that need to be monitored. The monitoring module will automatically trigger all monitoring probes to count the health status of the current node at regular intervals. When the health value reaches different indicators, it will automatically trigger different exception handlers, such as built-in alarm notifications, exit elections, node offline and other exception handlers. Compared with the use of the Prometheus monitoring framework, the advantages are that it is lighter to use and simpler to implement, and can achieve on-demand software and hardware monitoring at the lowest cost.

[0044] Second, there is a high-performance Master election without a global service center. The Master node sends heartbeats to all Slave nodes. The default heartbeat frequency is 1 second / time (ADVERTISEMENT_INTERVAL). When the Slave node has not received the heartbeat of the Master node after three consecutive default timeouts (MASTER_DOWN_INTERVAL), it is considered that the Master node is offline, and a new Master election is required. Master election principles: the highest synchronization resource version number is given priority, followed by the lower priority, and then the lower IP address is given priority. When the node switches to the election state, it actively sends heartbeats to all other nodes, carrying its own maximum synchronization resource version number, priority, IP and other information in the heartbeat. If the node receives a heartbeat from a node that is more suitable as a Master than itself, it will no longer send a heartbeat; if the node does not receive a heartbeat from a more suitable node within the MASTER_DOWN_INTERVAL time, it will promote itself as a Master node. Compared with MySQL bin-log log synchronization, the heartbeat and election mechanism is clearer and more controllable, and can complete more suitable business customization, such as counting heartbeat records, transmitting a small amount of information in the heartbeat, and customizing the heartbeat interval and fault detection threshold according to the network environment and business scenarios; compared with relying on the global service center for elections, it has lower resource usage, no need to deploy additional services, and no need to ensure the high availability of other services; after the election, it supports email, SMS, Feishu and other reminder methods to send alarms, increase the exposure rate of abnormal phenomena, and notify operation and maintenance to repair abnormal devices in the cluster in time.

[0045] The third is the identification and recovery of cluster split-brain failures. Split-brain failures refer to the situation where multiple devices in the cluster cannot communicate with each other due to network failures, and each device becomes the master and provides services to the outside world. This module supports automatic identification of whether the cluster is in a split-brain failure. Compared with MySQL bin-log log synchronization, which does not support split-brain failure identification, this technology can significantly improve the robustness of the cluster, can promptly and proactively issue alarms when the cluster fails, and notify operations and maintenance more promptly. It supports reminders such as emails, SMS, and Feishu. At the same time, when a cluster split-brain failure is detected, the service will be suspended immediately to avoid the expansion of configuration differences. At the same time, it supports configuration priority and full synchronization methods for automatic recovery of cluster failures.

[0046] Based on the above general idea, the cluster configuration synchronization method for integrated hardware peer deployment provided by the present disclosure mainly includes the following steps:

[0047] S1, identifies the user's write operation request;

[0048] S2 forwards the write operation request received from the slave node to the master node of the cluster for processing and waits for the response result;

[0049] S3: When processing a write operation, the master node generates a synchronization resource by parsing the write operation request, and uses the synchronization resource to drive data synchronization of all slave nodes in the cluster.

[0050] S4, after waiting for the data of the slave device nodes in the cluster that meet the quantity requirements to be synchronized, the node that initially receives the write operation request responds to the front-end request with the result of the write operation request.

[0051] Furthermore, the step S1 includes:

[0052] S11, receiving an operation request from a user;

[0053] S12, identifying whether the request is a read operation or a write operation, a read operation is processed by itself, and a write operation proceeds to step S2 for subsequent processing;

[0054] Wherein, in the step S12, an adaptation method is used to realize dynamic identification of the request type, and the adapter used includes: one or more of a RESTful API adapter, a URI whitelist adapter, and a custom adapter.

[0055] Furthermore, step S3 specifically includes:

[0056] S31, when processing a write operation, the Master node generates a synchronization resource by parsing the write operation request, encrypts it and delivers it to all other Slave nodes;

[0057] S32, the slave node receives the encrypted synchronization resource, persists it after decryption, and returns the operation result;

[0058] S33, after the Master node completes the delivery, it will count the delivery results;

[0059] S34, the Master node confirms the transaction status: if the delivery result does not meet the minimum reachable number threshold, the transaction is rolled back directly; otherwise, the business logic is attempted to be executed: if the execution is successful, the transaction is committed; otherwise, the transaction is rolled back;

[0060] S35, after the Master node confirms the transaction status, it synchronizes the transaction status to all Slave nodes;

[0061] S36, the slave node executes the task of consuming synchronization resources according to the received synchronization resource transaction status, including: if the transaction status is committed, parsing the synchronization resources and writing them into the device to achieve data synchronization.

[0062] Furthermore, the step S3 further comprises the following steps:

[0063] The slave node detects whether there are any unconsumed synchronization resources at set time intervals;

[0064] If it is found that the current node is missing some synchronization resources, it will obtain the missing synchronization resources from the master device and / or other slave devices to restore to the same state of the cluster;

[0065] If it is detected that there are synchronization resources that have not been consumed, the task of consuming the synchronization resources is started.

[0066] Furthermore, the method also includes: customizing the steps of software and hardware resource monitoring, cluster heartbeat and Master election, and split-brain fault identification;

[0067] The Master election specifically includes:

[0068] The master node sends heartbeats to all slave nodes at a certain frequency. If a slave node has not received the heartbeat of the master node after the default number of consecutive timeouts, it is considered that the master node is offline and a new master election is required. The master election principles include: the highest synchronization resource version number is given priority, followed by the lowest priority, and then the lowest IP address is given priority.

[0069] When a node switches to the election state, it actively sends heartbeats to all other nodes, carrying its own maximum synchronization resource version number, priority, and IP information in the heartbeat;

[0070] If a node receives a heartbeat from a node that is more suitable as the Master than itself, it will no longer send heartbeats; if a node does not receive a heartbeat from a more suitable node within a certain period of time, it will promote itself to the Master node.

[0071] The cluster configuration synchronization system for integrated hardware peer-to-peer deployment based on the above method mainly includes:

[0072] The request identification and forwarding unit is used to identify the user's write operation request, forward the write operation request received by the slave node to the master node of the cluster for processing, and then wait for the response result;

[0073] Synchronous resource abstraction and cluster synchronization unit, used for: when the master node processes a write operation, it generates a synchronization resource by parsing the write operation request, and uses the synchronization resource to drive the data synchronization of all slave nodes in the cluster;

[0074] The input and output unit is used to receive and respond to the user's read and write operation requests. For write operation requests, the result of the write operation request needs to be responded to the front-end request after the data of the slave device nodes that meet the quantity requirements in the cluster are synchronized.

[0075] Furthermore, the request identification and forwarding unit includes:

[0076] A request identification module, used to identify whether the request is a read operation or a write operation;

[0077] The status management module includes three sub-modules: request forwarding, node status monitoring, and Master election. They are used to forward write operation requests received by the Slave node to the Master node for processing; node status monitoring; and election of a new Master node in the cluster when the Master node fails.

[0078] Furthermore, the request identification module uses an adapter to realize dynamic identification of requests, including: one or more of a RESTful API adapter, a URI whitelist adapter, and a custom adapter.

[0079] Furthermore, the synchronization resource abstraction and cluster synchronization unit includes:

[0080] (1) Delivery / receiving synchronization resource module, used to generate synchronization resources and synchronize them to all nodes in the cluster, preparing for data synchronization; including:

[0081] The Master node delivery synchronization resource module is used to parse the request information to extract the synchronization content, add relevant information to assemble it into a synchronization resource, and then encrypt the synchronization resource and deliver it to all Slave nodes. After the delivery is completed, the delivery results are counted;

[0082] The slave node receives the synchronization resource module, which is used to receive the encrypted synchronization resource, persist it after decryption, and return the operation result;

[0083] (2) Confirm the synchronization resource transaction module, which is used to unify the distributed transaction: commit or rollback; it includes two sub-modules: Master synchronization transaction status and Slave receiving transaction status, among which:

[0084] The Master synchronization transaction status submodule is used to determine whether the delivery result meets the minimum reachable number threshold. If not, the transaction is rolled back directly. Otherwise, the business logic is attempted to be executed: if the execution is successful, the transaction is committed, otherwise the transaction is rolled back. After the Master node confirms the transaction status, the transaction status is synchronized to all Slave nodes at the same time to ensure cluster transaction consistency.

[0085] The slave receives the transaction status submodule, which is used to receive and update the synchronization resource transaction status;

[0086] (3) The slave node consumption synchronization resource module is used to execute the consumption synchronization resource task according to the received synchronization resource transaction status.

[0087] Furthermore, the method for the slave node consumption synchronization resource module to perform the consumption synchronization resource task includes:

[0088] The slave node detects whether there are any unconsumed synchronization resources at set time intervals;

[0089] If it is found that the current node is missing some synchronization resources, it will obtain the missing synchronization resources from the master device and / or other slave devices to restore to the same state of the cluster;

[0090] If it is determined that there are synchronization resources that have not been consumed, the task of consuming synchronization resources is started: if the transaction status is committed, the synchronization resources are parsed and written to the device to achieve data synchronization, otherwise the synchronization resources are abandoned.

[0091] Compared with the prior art, the beneficial effects of the present invention are:

[0092] 1. Supports the deployment of multiple integrated hardware devices in a cluster mode. In the past, multiple hardware devices could only provide services independently without correlation and fault tolerance. In the current cluster deployment mode, multiple devices jointly provide services, and the failure of some devices does not affect the normal use of users, ensuring the risk resistance and high availability of the user environment; at the same time, the cluster deployment mode does not increase the difficulty of deployment, and there is no need to deploy any other hardware or services. You only need to deploy multiple devices one by one and enable the cluster configuration just like deploying a single device.

[0093] 2. Based on customizable synchronization resources and data consumers, synchronization of any data or operation is achieved, such as synchronous execution of database data, file data or code blocks. At the same time, a blacklist can be defined for each synchronization resource. For example, the configuration data of scheduled tasks can be run independently on each device without synchronization. It supports the execution of custom pre- and post-business logic before and after data synchronization, such as log printing, data decryption, hardware linkage, time-consuming statistics and other operations, which can solve the need to operate hardware or communicate with other processes after synchronizing data. Developers can customize data types and data consumers to meet the needs of their own business scenarios, greatly improving the flexibility of the system.

[0094] 3. Supports customized software and hardware resource monitoring and alarms, which is of great help to the stable operation of the cluster: In the integrated hardware equipment deployment mode, the failure of a single node is no longer just whether the network can communicate normally, but is usually also related to the system memory utilization rate, system CPU utilization rate, disk IO, core process running status, network port connection status, etc. When the system health value reaches different indicators, different exception handlers will be automatically triggered. When serious problems such as node abnormalities occur, timely alarms can be issued, transforming from passive reception and processing of abnormalities to early detection of potential cluster problems, effectively improving the robustness and stability of the cluster. BRIEF DESCRIPTION OF THE DRAWINGS

[0095] The above and other objects, features and advantages of the present disclosure will become more apparent through a more detailed description of exemplary embodiments of the present disclosure in conjunction with the accompanying drawings, wherein like reference numerals generally represent like components throughout the exemplary embodiments of the present disclosure.

[0096] Figure 1 It is a schematic diagram of the overall structure of an exemplary embodiment according to the present disclosure, wherein a and b are spliced;

[0097] Figure 2 A request identification module flow chart of an exemplary embodiment;

[0098] Figure 3 A request forwarding submodule flow chart of an exemplary embodiment;

[0099] Figure 4 is a flowchart of a node status monitoring submodule of an exemplary embodiment;

[0100] Figure 5 is a flowchart of the Master election submodule of an exemplary embodiment;

[0101] Figure 6 A flow chart of a pre-processing module of an exemplary embodiment;

[0102] Figure 7 A flow chart of a delivery synchronization resource module of an exemplary embodiment;

[0103] Figure 8 A flowchart of a receiving synchronization resource module of an exemplary embodiment;

[0104] Fig. 9 A flowchart of the Master synchronization transaction status submodule of an exemplary embodiment;

[0105] Fig.10 A flow chart of a slave receiving transaction status submodule of an exemplary embodiment;

[0106] Fig.11A flow chart of a Slave node consumption synchronization resource module of an exemplary embodiment;

[0107] Fig.12 A flow chart of a post-processing module of an exemplary embodiment. DETAILED DESCRIPTION

[0108] The preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the preferred embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0109] The present disclosure provides a cluster configuration synchronization method and system for hardware-integrated peer-to-peer deployment. According to an exemplary embodiment of the present disclosure, the system composition structure and overall processing process are as shown in the attached Figure 1 shown.

[0110] The system mainly includes:

[0111] 1. Input user request module

[0112] This module is used to receive user operation requests on the browser, such as adding new user operations.

[0113] 2. Request identification module

[0114] This module is used to identify whether the request is a read operation or a write operation (including adding, editing and deleting). Read operations are processed by themselves, otherwise the request is handed over to the state management module for further processing to complete the read-write separation preprocessing. Supports identification methods such as RESTfulAPI, URI whitelist and custom adapter to improve flexibility.

[0115] 3. State Management Module

[0116] This module is used to identify the current node status (Master or Slave). The Slave node needs to forward the request to the Master for processing, and the Master node processes the request itself to achieve the read-write separation effect. At the same time, this module is responsible for node status monitoring, cluster new Master node election and status abnormality alarm notification when the Master node fails.

[0117] 4. Pre-processing module

[0118] This module is used to mark the starting time point and to count the time consumption of each stage. It also supports custom pre-processors to complete custom services and improve flexibility.

[0119] 5. Delivery / receiving synchronization resource module

[0120] This module is used to parse requests to generate synchronization resources, such as SQL statements, files, code block synchronization execution signatures and other synchronization resources. The Master node is then responsible for delivering synchronization resources to all Slave nodes. At the same time, the Slave nodes receive synchronization resources. After the Master node completes the delivery, the delivery results are counted and the next module is moved to.

[0121] 6. Confirm the synchronization resource transaction module

[0122] This module is used to confirm the transaction status of the synchronization resource: commit or rollback. If the delivery result of the Master node does not meet the minimum reachable number threshold, the transaction is rolled back directly. Otherwise, the transaction status is determined according to the business execution result of the Master node: if the execution is successful, the transaction is committed; if the execution fails, the transaction is rolled back. After the Master node confirms the transaction status, the transaction status is synchronized to all Slave nodes at the same time to ensure the consistency of the set transaction.

[0123] 7.Slave node consumption synchronization resource module

[0124] This module is used by the slave node to write synchronization resources after receiving synchronization resources and transaction status: if the transaction status is committed, the synchronization resources are parsed and written to the device to achieve the purpose of data synchronization; otherwise, the synchronization resources are abandoned.

[0125] 8. Post-processing module

[0126] This module is used for counting time consumption, hardware linkage, waiting for writing and other functions. It also supports custom post-processors to complete custom services and improve flexibility.

[0127] 9. Output response result module

[0128] This module is used to respond to the results of user operations on the browser, such as successfully adding a new user.

[0129] The processing flow of each module is as follows:

[0130] 1. Request identification module

[0131] The core of the request identification module is to implement request identification through a Servlet container filter.

[0132] When a request enters this module, each identifier is used to identify whether it is a write operation. Once a certain identifier is identified as a write operation, other identifiers are stopped. Otherwise, other identifiers are continued until all identifiers are executed. If it is finally identified as a read operation, the request is processed by the local machine; otherwise, it is handed over to the next module to continue processing the request.

[0133] Preferably, the present embodiment has built-in URI whitelist identifier and RESTfulAPI identifier to support developers to customize adapters.

[0134] The exemplary processing flow of this module is shown in the attached Figure 2 shown.

[0135] 2. State Management Module

[0136] The status management module includes three sub-modules: request forwarding, node status monitoring, and Master election, which jointly maintain the status of cluster nodes.

[0137] (1) Request forwarding submodule

[0138] When the request enters this module, it is identified as a write request by the request identification module. If it is not a Master node, it obtains the current Master node of the cluster and forwards the request to the Master node; otherwise, it obtains the current number of online nodes in the cluster and determines whether it meets the minimum reachable number threshold. If it does, it is handed over to the next module for processing; if it does not, it prompts a cluster abnormality.

[0139] An exemplary flow chart is attached. Figure 3 shown.

[0140] (2) Node status monitoring submodule

[0141] It is used to monitor and detect whether the software and hardware modules of the device are normal, such as the resource load of CPU memory, disk IO, core process running status, network port connection status, etc. If the device health value is lower than the threshold level, the corresponding exception handler needs to be triggered: such as alarm notification, exit election, node offline or custom exception handler.

[0142] An exemplary flow chart is attached. Figure 4 shown.

[0143] (3)Master election submodule

[0144] It is used to quickly elect a "most suitable" new Master (the one with the largest synchronization resource version number is preferred, the one with the smallest priority is preferred, and the one with the smallest IP address is preferred) to continue providing services and ensure the high availability of the cluster. In this embodiment, the specific process is as follows:

[0145] The Master node sends heartbeats to all Slave nodes. The default heartbeat frequency is 1 second / time (ADVERTISEMENT_INTERVAL). When the Master node fails (network failure or automatic offline), it will not be able to send heartbeats to other nodes. Other nodes will try to run for Master if they have not received heartbeats for three consecutive times (MASTER_DOWN_INTERVAL) by default:

[0146] Each node sends heartbeats to all other nodes, carrying the maximum version number, priority, and IP address of the synchronization resource in the heartbeat. When a heartbeat that is "more suitable" than its own is received, it will no longer send election heartbeats; otherwise, it will continue to send heartbeats. When it is the only one sending heartbeats within the MASTER_DOWN_INTERVAL time, it will be promoted to Master.

[0147] Flowchart attached Figure 5 shown.

[0148] 3. Pre-processing module

[0149] This module is usually used to mark the starting time point and to count the time consumption of each stage. It also supports custom pre-processors to complete custom services and improve flexibility.

[0150] Flowchart as attached Figure 6 shown.

[0151] 4. Delivery / receiving synchronization resource module

[0152] This module generates synchronization resources and synchronizes them to all nodes in the cluster, preparing for data synchronization.

[0153] When a request enters this module, the Master is responsible for parsing the request information to extract the synchronization content, and then adding unique ID, version number, type (such as SQL statement, file, code block synchronization execution signature, etc.), transaction status (default, commit, rollback), time and source and other information to assemble the synchronization resource, and then encrypt the synchronization resource and deliver it to all Slave nodes;

[0154] The slave node receives the encrypted synchronization resource, persists it after decryption, and returns the operation result.

[0155] After the Master node completes the delivery, it counts the delivery results and moves on to the next module.

[0156] The flow chart of Master node delivery synchronization resource module is as follows Figure 7 The Slave node receives the synchronous resource module flow chart as shown in the attached Figure 8 shown.

[0157] 5. Confirm the synchronization resource transaction module

[0158] The core of this module is to unify distributed transactions: commit or rollback, including two sub-modules: Master synchronization transaction status and Slave receiving transaction status.

[0159] If the delivery result of the front-end module does not meet the minimum reachable number threshold, the transaction is rolled back directly, otherwise the business logic is tried to be executed: if the execution is successful, the transaction is committed, otherwise the transaction is rolled back;

[0160] After the Master node confirms the transaction status, it will synchronize the transaction status to all Slave nodes to ensure cluster transaction consistency.

[0161] The flowchart of the Master synchronization transaction status submodule is as follows Fig. 9 The Slave receiving transaction status submodule flow chart is shown in the attached Fig.10 shown.

[0162] 6.Slave node consumption synchronization resource module

[0163] The core of this module is to achieve data synchronization by consuming synchronization resources.

[0164] The slave node checks every second whether there are any unconsumed synchronization resources. If it detects that there are unconsumed synchronization resources, it starts the task of consuming synchronization resources:

[0165] (1) Batch loading of unconsumed synchronization resources;

[0166] (2) Traverse the list of synchronized resources to prepare for consumption. If the traversal and consumption are completed, the task is terminated;

[0167] (3) Determine whether the synchronization resource version number is less than the maximum version number of the current node. If so, proceed to the next step. Otherwise, it means that the current node is missing some synchronization resources and the following operations are required:

[0168] 1) Obtain the missing synchronization resources from the Master node;

[0169] 2) Return to step (1);

[0170] (4) Determine whether the transaction status of the synchronization resource has been determined. If so, proceed to the next step; otherwise, wait for one second and ask the Master about the transaction status of the synchronization resource, and re-execute step (3);

[0171] (5) Determine whether the synchronous resource transaction status is in the committed state. If it is in the committed state, proceed to the next step; otherwise, go to step (7) to continue execution;

[0172] (6) Traverse the consumer list to obtain the data consumer adapted by the synchronization resource;

[0173] (7) Use the data consumer to write the synchronization resource content to complete data synchronization;

[0174] (8) Update the synchronization resource to the consumed state;

[0175] (9) Update the maximum version number of the current node, and then return to step (2) to continue consuming the next synchronization resource.

[0176] The flow chart of the slave node consumption synchronization resource module is as follows Fig.11 shown.

[0177] 7. Post-processing module

[0178] This module is used for counting time consumption, hardware linkage, waiting for writing and other functions. It also supports custom post-processors to complete custom services and improve flexibility.

[0179] Waiting for write: The slave node needs to wait for the synchronization resources of the request to be consumed before responding to the request to avoid the problem of not being able to query the latest data due to consumption delays.

[0180] The post-processing module flow chart is as attached Fig.12 shown.

[0181] It can be seen that the solution described in the present disclosure is different from the prior art mainly in that:

[0182] 1. Based on the plug-in method, services are integrated and multiple integrated hardware peer deployment is supported. Its main features are: cluster configuration synchronization can be achieved without destroying the existing service deployment structure and without adding additional services; the cluster is not perceived by users, and all devices in the cluster can be used without distinction; there is no need to transform the integrated hardware deployment method, and there is no difference between cluster deployment and single deployment; multiple hardware combinations can be clustered and cluster split and independent, all of which can be switched with one click on the interface without operating the hardware, and the original performance of the device will not be affected after the cluster is split.

[0183] 2. Based on customizable synchronization resources, driven by the producer-consumer model, and in the adapter design mode, it supports synchronization of any type of data or operation. Its main features are: built-in support for database data synchronization, file data synchronization, and synchronous execution of code blocks, while solving the problem of obtaining historical data due to delays in reading data from the slave device (Slave) after the write operation is completed; supports developers to customize data types and develop data consumers based on the adapter mode to synchronize custom data; supports the definition of blacklists for each synchronization resource; supports the execution of custom pre- and post-business logic before and after data synchronization.

[0184] 3. Based on customizable software and hardware resource monitoring, it runs under a decentralized architecture and supports any device to become a central node. Its main features are: all devices are in a peer state, and data copies are placed in different nodes without relying on external middleware, thereby avoiding single point failures; it supports custom monitoring detectors, health value scores and exception handlers for objects that need to be monitored. When the health value reaches different indicators, it will automatically trigger different exception handlers such as alarm notifications, withdrawal from the election, and node offline. Alarm notifications support reminders such as emails, SMS and Feishu.

[0185] The above technical scheme is only an exemplary embodiment of the present invention. For those skilled in the art, it is easy to make various types of improvements or modifications based on the application methods and principles disclosed in the present invention, and it is not limited to the method described in the above specific embodiment of the present invention. Therefore, the method described above is only preferred and does not have a restrictive meaning.

Claims

1. A cluster configuration synchronization method for integrated hardware peer deployment, characterized in that: The cluster adopts a master-slave architecture: in the cluster, there is only one master device Master and multiple slave devices Slave at the same time; in business interaction, user read and write operations are separated: all devices can process read operations, but at the same time only the master device Master can process read and write operations at the same time, and the other slave devices Slave can only process read operations; the master device Master can synchronize data to the slave device Slave in real time, and the slave device Slave can also actively obtain data from the master device Master for synchronization; The method comprises the following steps: S1, identifies the user's write operation request; S2 forwards the write operation request received from the slave node to the master node of the cluster for processing and waits for the response result; S3: When processing a write operation, the master node generates a synchronization resource by parsing the write operation request, and uses the synchronization resource to drive data synchronization of all slave nodes in the cluster. S4, after waiting for the data of the slave device nodes in the cluster that meet the quantity requirements to be synchronized, the node that initially receives the write operation request responds to the front-end request with the result of the write operation request.

2. The method according to claim 1, characterized in that The step S1 comprises: S11, receiving an operation request from a user; S12, identifying whether the request is a read operation or a write operation, a read operation is processed by itself, and a write operation proceeds to step S2 for subsequent processing; Wherein, in the step S12, an adaptation method is used to realize dynamic identification of the request type, and the adapter used includes: one or more of a RESTful API adapter, a URI whitelist adapter, and a custom adapter.

3. The method according to claim 1, characterized in that Step S3 specifically includes: S31, when processing a write operation, the Master node generates a synchronization resource by parsing the write operation request, encrypts it and delivers it to all other Slave nodes; S32, the slave node receives the encrypted synchronization resource, persists it after decryption, and returns the operation result; S33, after the Master node completes the delivery, it will count the delivery results; S34, the Master node confirms the transaction status: if the delivery result does not meet the minimum reachable number threshold, the transaction is rolled back directly; otherwise, the business logic is attempted to be executed: if the execution is successful, the transaction is committed; otherwise, the transaction is rolled back; S35, after the Master node confirms the transaction status, it synchronizes the transaction status to all Slave nodes; S36, the slave node executes the task of consuming synchronization resources according to the received synchronization resource transaction status, including: if the transaction status is committed, parsing the synchronization resources and writing them into the device to achieve data synchronization.

4. The method according to claim 3, characterized in that The step S3 further comprises the following steps: The slave node detects whether there are any unconsumed synchronization resources at set time intervals; If it is found that the current node is missing some synchronization resources, it will obtain the missing synchronization resources from the master device and / or other slave devices to restore to the same state of the cluster; If it is detected that there are synchronization resources that have not been consumed, the task of consuming the synchronization resources is started.

5. The method according to any one of claims 1 to 4, characterized in that: Also includes: Customize the steps for software and hardware resource monitoring, cluster heartbeat and master election, and split-brain fault identification; The Master election specifically includes: The master node sends heartbeats to all slave nodes at a certain frequency. If a slave node has not received the heartbeat of the master node after the default number of consecutive timeouts, it is considered that the master node is offline and a new master election is required. The master election principles include: the highest synchronization resource version number is given priority, followed by the lowest priority, and then the lowest IP address is given priority. When a node switches to the election state, it actively sends heartbeats to all other nodes, carrying its own maximum synchronization resource version number, priority, and IP information in the heartbeat; If a node receives a heartbeat from a node that is more suitable to be the Master than itself, it will no longer send a heartbeat. If a node does not receive a heartbeat from a more suitable node within a certain period of time, it will promote itself to the Master node.

6. A cluster configuration synchronization system for integrated hardware peer-to-peer deployment using the method described in any one of claims 1 to 5, characterized in that: include: The request identification and forwarding unit is used to identify the user's write operation request, forward the write operation request received by the slave node to the master node of the cluster for processing, and then wait for the response result; Synchronous resource abstraction and cluster synchronization unit, used for: when the master node processes a write operation, it generates a synchronization resource by parsing the write operation request, and uses the synchronization resource to drive the data synchronization of all slave nodes in the cluster; The input and output unit is used to receive and respond to the user's read and write operation requests. For write operation requests, the result of the write operation request needs to be responded to the front-end request after the data of the slave device nodes that meet the quantity requirements in the cluster are synchronized.

7. The system according to claim 6, characterized in that The request identification and forwarding unit comprises: A request identification module, used to identify whether the request is a read operation or a write operation; The status management module includes three sub-modules: request forwarding, node status monitoring, and Master election. They are used to forward write operation requests received by the Slave node to the Master node for processing; node status monitoring; and election of a new Master node in the cluster when the Master node fails.

8. The system according to claim 7, characterized in that The request identification module uses an adapter to realize dynamic identification of requests, including: one or more of a RESTful API adapter, a URI whitelist adapter, and a custom adapter.

9. The system according to claim 6, characterized in that The synchronization resource abstraction and cluster synchronization unit includes: (1) Delivery / receiving synchronization resource module, used to generate synchronization resources and synchronize them to all nodes in the cluster, preparing for data synchronization; including: The Master node delivery synchronization resource module is used to parse the request information to extract the synchronization content, add relevant information to assemble it into a synchronization resource, and then encrypt the synchronization resource and deliver it to all Slave nodes. After the delivery is completed, the delivery results are counted; The slave node receives the synchronization resource module, which is used to receive the encrypted synchronization resource, persist it after decryption, and return the operation result; (2) Confirm the synchronization resource transaction module, which is used to unify the distributed transaction: commit or rollback; it includes two sub-modules: Master synchronization transaction status and Slave receiving transaction status, among which: The Master synchronization transaction status submodule is used to determine whether the delivery result meets the minimum reachable number threshold. If not, the transaction is rolled back directly. Otherwise, the business logic is attempted to be executed: if the execution is successful, the transaction is committed, otherwise the transaction is rolled back. After the Master node confirms the transaction status, the transaction status is synchronized to all Slave nodes at the same time to ensure cluster transaction consistency. The slave receives the transaction status submodule, which is used to receive and update the synchronization resource transaction status; (3) The slave node consumption synchronization resource module is used to execute the consumption synchronization resource task according to the received synchronization resource transaction status.

10. The system according to claim 9, characterized in that The method for the slave node consumption synchronization resource module to perform the consumption synchronization resource task includes: The slave node detects whether there are any unconsumed synchronization resources at set time intervals; If it is found that the current node is missing some synchronization resources, it will obtain the missing synchronization resources from the master device and / or other slave devices to restore to the same state of the cluster; If it is determined that there are synchronization resources that have not been consumed, the task of consuming synchronization resources is started: if the transaction status is committed, the synchronization resources are parsed and written to the device to achieve data synchronization, otherwise the synchronization resources are abandoned.

Images