A configuration information processing method, apparatus, and device

Abstract

This specification discloses a configuration information processing method, apparatus, and device applied to nodes in a distributed cluster. The scheme includes: determining a database for storing changed configuration-related information for nodes in the distributed cluster; disguising itself as a slave server corresponding to the master server of the database; obtaining the changed configuration-related information from the master server of the database based on the disguised slave server identity; and making corresponding changes in its own memory according to the changed configuration-related information to obtain the corresponding configuration data in the memory. This allows each node's local cache to efficiently update configuration data without having to assume the actual slave server workload, thus being effective and user-friendly for nodes, with low implementation costs.

Description

Technical Field

[0001] This specification relates to the field of distributed technology, and in particular to a configuration information processing method, apparatus, and device. Background Technology

[0002] Systems often contain a lot of configuration data, most of which changes infrequently but is accessed frequently. Therefore, using a local cache to store this configuration data can be considered. In a Java scenario, for example, a memory space can be allocated within the JVM to cache frequently accessed configuration data.

[0003] However, this approach introduces new problems in a distributed environment, namely that most machines in the cluster are unaware of each other, which can cause problems for updating configuration data in a single machine's local cache in a distributed environment.

[0004] Therefore, a solution is needed in a distributed environment that can update configuration data in a timely and effective manner for local cache on a single machine. Summary of the Invention

[0005] This specification provides one or more embodiments of a configuration information processing method, apparatus, device, and storage medium to solve the following technical problem: the need for a solution that can update configuration data in a timely and effective manner for local cache on a single machine in a distributed environment.

[0006] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows:

[0007] This specification provides a configuration information processing method according to one or more embodiments, applied to nodes in a distributed cluster, the method comprising:

[0008] Determine a database for storing configuration-related information for changes to nodes in the distributed cluster;

[0009] It disguises itself as a slave server corresponding to the master server of the database;

[0010] Based on the disguised identity of the slave server, obtain the configuration-related information of the changes from the master server of the database;

[0011] Based on the configuration information related to the changes, corresponding changes are made in its own memory so that the corresponding configuration data can be obtained in the memory.

[0012] This specification provides one or more embodiments of a configuration information processing device applied to nodes in a distributed cluster, the device comprising:

[0013] The database determination module determines the database used to store configuration-related information for changes to nodes in the distributed cluster;

[0014] The slave server masquerading module disguises itself as a slave server corresponding to the master server of the database;

[0015] The change information acquisition module, based on the disguised identity of the slave server, obtains the configuration-related information of the change from the master server of the database;

[0016] The configuration data change module makes corresponding changes in its own memory based on the configuration-related information to obtain the corresponding configuration data in the memory.

[0017] This specification provides one or more embodiments of a configuration information processing device applied to a node in a distributed cluster, the device comprising:

[0018] At least one processor; and,

[0019] A memory communicatively connected to the at least one processor; wherein,

[0020] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0021] Determine a database for storing configuration-related information for changes to nodes in the distributed cluster;

[0022] It disguises itself as a slave server corresponding to the master server of the database;

[0023] Based on the disguised identity of the slave server, obtain the configuration-related information of the changes from the master server of the database;

[0024] Based on the configuration information related to the changes, corresponding changes are made in its own memory so that the corresponding configuration data can be obtained in the memory.

[0025] This specification provides one or more embodiments of a non-volatile computer storage medium applied to nodes in a distributed cluster. The medium stores computer-executable instructions, which are configured as follows:

[0026] Determine a database for storing configuration-related information for changes to nodes in the distributed cluster;

[0027] It disguises itself as a slave server corresponding to the master server of the database;

[0028] Based on the disguised identity of the slave server, obtain the configuration-related information of the changes from the master server of the database;

[0029] Based on the configuration information related to the changes, corresponding changes are made in its own memory so that the corresponding configuration data can be obtained in the memory.

[0030] The above-described at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects: In order to reflect the configuration-related information of configuration data changes, a database is specially constructed. Without setting up a slave server on the server of the database itself, the server of the database is regarded as the master server. The slave server corresponding to the master server is disguised on the node. In this way, the changed configuration-related information can be accurately targeted and efficiently monitored and synchronized from the server of the database, and updated to the local cache of the node. This allows the local cache of each node to efficiently update the configuration data, and does not have to assume the actual slave server work obligations. Therefore, it is effective and friendly to the nodes, and the implementation cost is low. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 A flowchart illustrating a configuration information processing method provided in one or more embodiments of this specification;

[0033] Figure 2 This is a schematic diagram illustrating the interaction of a node masquerading database obtaining configuration-related information from a server in one or more application scenarios provided by this specification;

[0034] Figure 3 In one application scenario provided by one or more embodiments of this specification, Figure 1 A schematic diagram of an implementation scheme of the method;

[0035] Figure 4 In one application scenario provided by one or more embodiments of this specification, Figure 3 The solution involves a detailed flowchart illustrating the specific process of changing configuration data.

[0036] Figure 5 A flowchart illustrating a multi-node cooperation and database interaction scheme provided for one or more embodiments of this specification;

[0037] Figure 6 A schematic diagram of the structure of a configuration information processing device provided for one or more embodiments of this specification;

[0038] Figure 7 This is a schematic diagram of the structure of a configuration information processing device provided for one or more embodiments of this specification. Detailed Implementation

[0039] This specification provides a configuration information processing method, apparatus, device, and storage medium through its embodiments.

[0040] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0041] To address the issue of updating configuration data in a single-machine local cache within a distributed environment, the applicant previously attempted several solutions, but none yielded satisfactory results. For example, having nodes periodically fetch configuration data from a database or other nodes resulted in significant update latency, and attempting to fetch data when no changes had occurred wasted request resources. Another approach was using ZooKeeper to notify nodes of configuration data changes; however, this required building ZooKeeper from scratch, incurring high learning and development costs, lacking lightweight design, and significantly impacting the entire distributed system. To better address these issues, a superior solution is proposed in this application, which will be detailed below.

[0042] Figure 1 This diagram illustrates a configuration information processing method provided in one or more embodiments of this specification. The method can be applied to nodes in a distributed cluster. For example, a subset of nodes in the distributed cluster can each act as an execution entity, executing the process independently (for ease of description, the current execution entity is referred to as "this node"). A single node typically consists of one or more machines. Some steps in the process can be executed by different machines on the same node or by different modules on the same machine. Intermediate results involved in the process execution (e.g., spoofed active relationships, acquired configuration change information, etc.) can also be manually intervened to improve the accuracy of the final result.

[0043] Figure 1 The process includes the following steps:

[0044] S102: Determine a database for storing configuration-related information for changes to nodes in the distributed cluster.

[0045] In one or more embodiments of this specification, the configuration-related information of the change includes the changed configuration data itself, and / or other data that can be used to locate or restore the changed configuration data, such as change logs, configuration change instructions, configuration data indexes, etc.

[0046] One or more databases are pre-built to store configuration-related information. In the case of multiple databases, for example, the changed configuration data itself is stored in one database, while other data such as change logs are stored in another database.

[0047] In one or more embodiments of this specification, when the configuration data required by a node in a distributed cluster is about to change, or has already changed within a local area of ​​the distributed cluster, the database can quickly obtain the corresponding configuration-related information from the changed node or a management entity outside the node, so as to use it for configuration data changes on a larger scale within the distributed cluster. Assuming that this node primarily relies on this database for configuration data changes, most of the following embodiments are illustrated using this role as an example.

[0048] S104: Disguise itself as the slave server corresponding to the master server of the database (i.e., the server of the database, which is regarded as the master server from the perspective of disguise, but may not be the master server in the true sense).

[0049] In one or more embodiments of this specification, the database server itself may not be configured with master-slave disaster recovery mode. In this case, if the database server crashes or restarts, the database cannot provide services to the outside world until it recovers. Conversely, if master-slave disaster recovery mode is configured, the database has at least one master server and one slave server. If the master server fails, the slave server will take over the position of the master server and continue to provide services to the outside world, so that the database can still be used normally. However, this application is not concerned with whether the master-slave disaster recovery mode is actually configured. Rather, it only aims to monitor database changes and promptly obtain the latest configuration information. Part or all of this node is disguised as a database slave server. In this case, from the node's perspective, the actual database server is in the master server position, while this node is in the corresponding slave server position. That said, compared to a true master-slave disaster recovery mode, the disguised node in this application only uses the powers inherent in a slave server position, without having to fulfill the duties that a slave server should normally perform. Furthermore, during the disguise process, this node can proactively define the scope of data it is disguising within the database to avoid unnecessarily synchronizing unused data beyond the configuration information. In summary, at least part of this node, after being disguised, becomes a lightweight, less responsible slave server of the database server. This slave server is highly proactive and flexible, breaking through the passive position of a traditional true slave server, effectively reducing coupling with the database, and helping to reduce the possibility of mutual risks introduced between the two.

[0050] S106: Based on the disguised identity of the slave server, obtain the configuration-related information of the changes from the master server of the database.

[0051] In one or more embodiments of this specification, the local node, based on its disguised slave server identity, is sensitive to data changes on the server that it considers the master server for databases, and can at least obtain relatively timely information on whether any new configuration-related information has been added to the database. If there is any addition, it indicates that the corresponding configuration data on at least some nodes in the distributed cluster needs to be changed. Some of the following embodiments assume that at least the local node needs to make this change.

[0052] In one or more embodiments of this specification, one or a small number of nodes may be pre-designated to lead the configuration data changes.

[0053] Specifically, these designated nodes can first complete their own configuration data changes without relying on the database (for example, by operations personnel configuring directly on the node machine; or by automatically updating the node machine adaptively according to dedicated permissions; etc.). Then, these nodes (referred to as the first type of node) send the configuration-related information corresponding to this configuration data change to the database for storage. Subsequently, other nodes (referred to as the second type of node) retrieve the saved configuration-related information from the database and perform the corresponding configuration data changes.

[0054] It should be noted that the first type of node can lead global configuration data changes, or the responsibility can be further subdivided, for example, different nodes can each lead changes to a portion of the configuration data. In this case, some nodes of the first type may also belong to the second type. Based on this role division, when executing step S106, this node belongs to at least the second type of node, and may also belong to the first type of node.

[0055] Assuming this node also belongs to the previous type of node. For example, if this node is designated as a node for actively updating the database, then when the configuration data in its memory changes (changes to configuration data that are not initiated by the node itself are not included, because such changes depend on the database itself, so there is no need to report them back to the database), it can write the corresponding configuration change instructions and / or configuration data into the database, so that other nodes can also update their configuration data according to the database.

[0056] In one or more embodiments of this specification, if the database server becomes unusable, the local node can remove its masquerade identity without triggering a master-slave switchover event between the local node and the server. Since the configuration data changes relatively infrequently, a short-term unavailability of the database server has minimal global impact on the distributed system. Alternatively, the database server itself may have genuine slave servers. In this case, the genuine slave server can take over as the database master server, continuing to provide configuration data update support for the nodes.

[0057] S108: Based on the configuration-related information of the changes, make corresponding changes in its own memory so that the corresponding configuration data can be obtained in the memory.

[0058] In one or more embodiments of this specification, this node may make corresponding configuration data changes in its own memory that are consistent with the changed configuration information. Of course, if this node has some special circumstances, it is also allowed to make only a part of the corresponding configuration data changes, and it does not necessarily have to follow the changes completely.

[0059] If the configuration information to be changed is the configuration data itself, the configuration data can be directly copied to the memory of this node to complete the change. If the configuration information to be changed is the location or restoration information of the configuration data, the configuration data can be located and copied, or restored, and the change can be completed in the memory of this node.

[0060] In one or more embodiments of this specification, the configuration data of this node can be stored in its own memory (e.g., a local cache is allocated) for use, thus achieving higher access efficiency.

[0061] pass Figure 1 This method involves constructing a dedicated database to reflect configuration changes. Without requiring a slave server on the database server itself, the database server is treated as the master server. Nodes are then configured as slave servers corresponding to this master server. This allows for precise and efficient monitoring and synchronization of changed configuration information from the database server, updating the node's local cache. This enables efficient configuration data updates on each node's local cache without requiring them to perform actual slave server tasks. Therefore, this approach is effective and user-friendly for nodes, with low implementation costs.

[0062] based on Figure 1 In addition to the method described herein, this specification also provides some specific implementation schemes and extension schemes of this method, which will be further explained below.

[0063] Based on the above description, intuitively, one or more embodiments of this specification provide an interactive diagram illustrating how a node masquerading as a database obtains configuration-related information from a server in an application scenario, such as... Figure 2 As shown.

[0064] In this scenario, this node can simulate the interaction protocol of a database slave server, disguising itself as a slave server corresponding to the master server of the data information repository. Based on the information retrieval protocol corresponding to the interaction protocol (e.g., information synchronization protocol or information push protocol), it can obtain changed configuration information from the master server of the data information repository. Specifically, the changed configuration information includes, for example, change logs. Specifically... Figure 2 For example, assuming the database is a MySQL database, this node can disguise itself as a slave server corresponding to the master server of the MySQL database, and then obtain the changed configuration information based on the dump protocol supported by MySQL.

[0065] Figure 2 The interactions can include:

[0066] When data changes occur on the database's master server, a corresponding binary log is generated to record what kind of changes occurred.

[0067] This node simulates a slave server of the database, listens to the database's binary log to obtain configuration data change notifications, and specifically sends data backup requests (e.g., dump requests) to the database's master server.

[0068] In response to the data backup request, the database master server begins pushing its own binary logs to this node;

[0069] This node receives binary logs pushed from the database's master server and retrieves information related to changed configurations based on these logs. If the original binary logs are in byte stream format, the binary log objects can be parsed from the byte stream to obtain the changed configuration information.

[0070] In one or more embodiments of this specification, the configuration-related information of the changes may include configuration change instructions, and the binary logs or other forms of logs listed above may mainly consist of configuration change instructions.

[0071] Configuration change instructions can include distinguishing information to differentiate between different instructions and the order in which changes are made. This distinguishing information may include an auto-incrementing identifier (ID) or a change timestamp. Configuration change instructions can also include more information such as the change type, the location of the changed configuration data, and the specific change execution statements.

[0072] Change types, such as reload, update, add, and delete, can be represented by keywords such as RELOAD, UPDATE, ADD, and DELETE.

[0073] The location information of the configuration data to be changed, such as the configuration data type and configuration data ID, can be used to determine which specific configuration data needs to be changed.

[0074] The specific change execution statements, such as the SQL statements executed when writing the changed configuration information to the database.

[0075] Furthermore, when retrieving configuration-related information from the master server of the database, specifically, the master server of the database retrieves configuration change instructions, which are sent to the database by at least one other node in the distributed cluster after making configuration data changes.

[0076] When making corresponding changes in its own memory based on the changed configuration information, specifically, according to the configuration change instruction, the corresponding configuration data is retrieved from the database that stores the relevant configuration data and updated to its own memory; or, the corresponding configuration data is changed in its own memory by executing the configuration change instruction (e.g., replaying the binary log). The former method has the advantage of low computational cost, potentially simplifying the intermediate process and reaching the final result faster, without needing to support the execution of database statements on the local node; the latter method has the advantages of high accuracy and reliability, and does not require storing specific configuration data in the database, reducing the burden on the database.

[0077] In one or more embodiments of this specification, the aforementioned distinguishing information can be used to perform incremental changes more efficiently and accurately. Taking an auto-incrementing identifier as the distinguishing information as an example, the auto-incrementing identifier is used to record the change order corresponding to different configuration change commands. The larger the identifier, the later the change order corresponding to the configuration change command.

[0078] Based on this, when retrieving configuration change instructions from the master database server, specifically, the maximum identifier of the configuration change instructions already processed in the current node's records is determined as the first identifier; the maximum identifier of the configuration change instructions stored in the master database server is obtained as the second identifier; based on the difference between the second identifier and the first identifier, the corresponding incremental configuration change instruction is retrieved from the master database server. Then, the incremental configuration change instruction is retrieved, the corresponding configuration data is queried and changed on this node, or the incremental configuration change instruction is replayed on this node to complete the change.

[0079] Based on the above description, one or more embodiments of this specification also provide an application scenario, Figure 1 A schematic diagram of one implementation scheme of the method, such as Figure 3 As shown.

[0080] In this application scenario, to enable more flexible and efficient masquerading, a dedicated masquerading module is set up on the node. This module can provide incremental data subscription and consumption capabilities based on incremental database log parsing, achieving flexible data synchronization. Since nodes in a distributed cluster are often also used as servers, in some embodiments of this application, the node can also be referred to as a server. In this case, the node includes the server body and the masquerading module used for masquerading.

[0081] It can be seen that, Figure 3The example lists at least four nodes, where node 1, as the first type of node mentioned above, is responsible for the configuration data change, while the remaining nodes, as the second type of node mentioned above, rely on the database for configuration data changes. Two databases are used: one to store configuration change instructions, called the instruction database, and the other to store the changed configuration data, called the configuration database.

[0082] Figure 3 The solution mainly includes the following processes:

[0083] When the configuration data on node 1 changes, node 1 writes the configuration change instruction to the instruction database and writes the changed configuration data (the configuration data obtained after the change) to the configuration database, thereby recording the corresponding binary log.

[0084] The remaining nodes, through their own masquerading modules, disguise themselves as slave servers of the instruction database, listen to and synchronize new binary logs on the instruction database, parse the binary logs, query the configuration database to obtain the corresponding changed configuration data based on the parsing results, and then update themselves.

[0085] Therefore, all nodes that need to use this configuration data have completed the changes to the configuration data.

[0086] More specifically, considering the use of auto-incrementing identifiers in instructions, one or more embodiments of this specification also provide an application scenario in which... Figure 3 The solution involves a detailed flowchart illustrating the configuration data change process, as shown below. Figure 4 As shown.

[0087] Figure 4 The proposed solution involves two parts. The first part mainly involves the process of obtaining basic configuration data during node startup (including initial startup and restart scenarios). The second part mainly involves the process of handling subsequent changes to the basic configuration data already possessed by the node.

[0088] In the first part of the process, after its initial startup, the node obtains and records the maximum identifier of the configuration change instructions stored in the master database (referred to as the latest instruction identifier of the database, i.e., the second identifier mentioned above); and retrieves the full set of configuration data it needs from the database that stores the corresponding configuration data, and updates it into its own memory. Of course, if a node restart or other event causes a power outage that damages memory, assuming the configuration-related data stored in memory has not been persisted, it needs to re-obtain the current basic configuration data and the latest instruction identifier of the database; if it has been persisted, it can read the corresponding data from its own persistent area (e.g., disk) into memory.

[0089] In the second part of the process, if a change notification is received from the instruction database, the node needs to refresh the configuration information in its own memory. Specifically, this includes: recording the latest instruction identifier that has been processed in the node's memory (referred to as the node's latest instruction identifier, i.e., the first identifier mentioned above); obtaining the latest instruction identifier from the instruction database; the difference between the latest instruction identifier in the database and the node's latest instruction identifier represents the instructions that have not yet been updated; then the node queries and parses these instructions, retrieves the latest configuration data from the configuration database based on the instructions, and refreshes it into memory, thus completing this configuration data change.

[0090] Considering the detailed module division within the node, more specifically, the masquerading module performs the masquerading work from the server, and determines whether configuration data has changed by interacting with the instruction database. If so, it notifies the server principal accordingly to trigger the server principal to query the database for the latest instruction identifier.

[0091] In one or more embodiments of this specification, the advantages of masquerading as a slave server to a node have been mentioned above. Furthermore, to reduce the burden on the database and improve its reliability when the node has sufficient capacity, while simultaneously preventing the node from becoming overly reliant on slave server responsibilities, one or more embodiments of this specification also provide a flowchart illustrating a multi-node cooperation and database interaction scheme, as shown below. Figure 5 As shown.

[0092] Figure 5 The process includes the following steps:

[0093] S502: Determine a node set constructed with several other nodes, so as to disguise the node set, including itself, as a slave server corresponding to the master server of the database.

[0094] S504: Based on the spoofed identity of the slave server, listen for and obtain binary logs from the database.

[0095] S506: Filter and select from the binary logs to remove at least some logs that are not related to the configuration data change, and obtain the target logs that are related to the configuration data change.

[0096] During transmission, the processing capacity of these nodes can be assessed. If the processing capacity of any node exceeds the set threshold, at least some logs unrelated to configuration data changes are saved and distributed to that node so that it can share more comprehensive data service sub-responsibilities in the future.

[0097] S508: Send the target log to the other nodes so that the other nodes can obtain the configuration-related information of the change based on the target log.

[0098] S510: When the master server of the database is unavailable, determine the data service responsibility of the master server, decompose the data service responsibility into multiple data service sub-responsibilities, and distribute the data service sub-responsibilities to multiple nodes of the node set.

[0099] S512: For each node distributed to the data service sub-responsibility, each node is determined as a block master server of the database, and through multiple block master servers, the database provides corresponding data services to the outside world.

[0100] New nodes can be dynamically added to or removed from the node set, and the corresponding data service sub-responsibilities are transferred accordingly.

[0101] based on Figure 5 The proposed solution ensures database serviceability without requiring the deployment of actual slave servers. Furthermore, it minimizes the impact on the business operations that the nodes themselves may undertake and allows for flexible adjustment of this impact to improve overall efficiency.

[0102] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figure 6 , Figure 7 As shown. The apparatus and equipment are capable of performing the above methods and related alternatives accordingly.

[0103] Figure 6 This specification provides a schematic diagram of the structure of a configuration information processing device according to one or more embodiments. The device is applied to a node in a distributed cluster and includes:

[0104] Database determination module 602 determines a database for storing configuration-related information of changes for nodes in the distributed cluster;

[0105] The slave server masquerading module 604 masquerades itself as a slave server corresponding to the master server of the database;

[0106] The change information acquisition module 606, based on the disguised identity of the slave server, obtains the configuration-related information of the change from the master server of the database;

[0107] The configuration data change module 608 makes corresponding changes in its own memory according to the changed configuration-related information, so as to obtain the corresponding configuration data in the memory.

[0108] Optionally, the slave server masquerading module 604 masquerades itself as a slave server corresponding to the master server of the MySQL database by simulating the interaction protocol of the slave server of the MySQL database, so as to obtain the configuration-related information of the changes based on the dump protocol.

[0109] Optionally, the change information acquisition module 606 sends a data backup request to the master server of the database;

[0110] Receive the binary logs pushed by the master server of the database in response to the data backup request;

[0111] Based on the binary log, obtain the configuration-related information of the changes.

[0112] Optionally, the slave server masquerading module 604 determines a node set constructed with several other nodes, so as to masquerade the node set, including itself, as a slave server corresponding to the master server of the database.

[0113] The change information acquisition module 606 filters and selects from the binary logs, removes logs that are not related to the configuration data change, and obtains the target logs that are related to the configuration data change.

[0114] The target log is sent to the other nodes so that the other nodes can obtain the configuration-related information of the change based on the target log.

[0115] Optionally, the change information acquisition module 606 obtains a configuration change instruction from the master server of the database. The configuration change instruction is sent to the database by at least one other node in the distributed cluster after making a configuration data change.

[0116] The configuration data change module 608, according to the configuration change instruction, retrieves the corresponding configuration data from the database storing the corresponding configuration data and updates it to its own memory; or,

[0117] By executing the configuration change instruction, the corresponding configuration data is changed in its own memory.

[0118] Optionally, the configuration change instruction includes an auto-incrementing identifier to record the change order corresponding to different configuration change instructions;

[0119] The change information acquisition module 606 determines the maximum identifier of the configuration change instructions that it has recorded that have been processed, and uses it as the first identifier;

[0120] Obtain the maximum identifier of the configuration change instruction stored in the master server of the database, and use it as the second identifier;

[0121] Based on the difference between the second identifier and the first identifier, the corresponding incremental configuration change instruction is obtained from the master server of the database.

[0122] Optionally, the change information acquisition module 606 acquires and records the maximum identifier of the configuration change instruction stored in the master server of the database after the node itself starts or restarts.

[0123] It retrieves the full set of configuration data it needs from the database that stores the corresponding configuration data, and updates it into its own memory.

[0124] Optionally, it also includes:

[0125] The change information writing module 610, if the node itself is designated as a node for actively updating the database, will write the corresponding configuration change instructions and / or configuration data into the database after the configuration data in its own memory changes, so that other nodes can also update the corresponding configuration data according to the database.

[0126] Optionally, the configuration change instruction may further include: change type and location information of the configuration data to be changed.

[0127] Optionally, the node includes a server body and a camouflage module for performing the camouflage;

[0128] The spoofing module determines whether configuration data changes have occurred by interacting with the database;

[0129] If so, the server principal is notified accordingly to trigger the server principal to query the maximum identifier of the configuration change instruction stored in the master server of the database.

[0130] Figure 7 This specification provides a schematic diagram of the structure of a configuration information processing device according to one or more embodiments. The device is applied to a node in a distributed cluster and includes:

[0131] At least one processor; and,

[0132] A memory communicatively connected to the at least one processor; wherein,

[0133] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0134] Determine a database for storing configuration-related information for changes to nodes in the distributed cluster;

[0135] It disguises itself as a slave server corresponding to the master server of the database;

[0136] Based on the disguised identity of the slave server, obtain the configuration-related information of the changes from the master server of the database;

[0137] Based on the configuration information related to the changes, corresponding changes are made in its own memory so that the corresponding configuration data can be obtained in the memory.

[0138] Based on the same idea, one or more embodiments of this specification also provide a non-volatile computer storage medium for use in nodes of a distributed cluster, wherein the medium stores computer-executable instructions configured as follows:

[0139] Determine a database for storing configuration-related information for changes to nodes in the distributed cluster;

[0140] It disguises itself as a slave server corresponding to the master server of the database;

[0141] Based on the disguised identity of the slave server, obtain the configuration-related information of the changes from the master server of the database;

[0142] Based on the configuration information related to the changes, corresponding changes are made in its own memory so that the corresponding configuration data can be obtained in the memory.

[0143] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0144] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0145] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0146] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0147] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0148] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0149] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0150] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0151] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0152] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0153] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A configuration information processing method, applied to nodes in a distributed cluster, the method comprising: Determine a database for storing configuration-related information for changes to nodes in the distributed cluster; Disguising itself as a slave server corresponding to the master server of the database includes: determining a node set constructed with several other nodes, so as to disguise the node set, including itself, as a slave server corresponding to the master server of the database; Based on the disguised identity of the slave server, obtain the configuration-related information of the changes from the master server of the database; Based on the configuration-related information of the changes, corresponding changes are made in its own memory so that the corresponding configuration data can be obtained in the memory; When the master server of the database is unavailable, the data service responsibility of the master server is determined, the data service responsibility is decomposed into multiple data service sub-responsibilities, and the data service sub-responsibilities are distributed to multiple nodes of the node set.

2. The method as described in claim 1, wherein disguising itself as a slave server corresponding to the master server of the database specifically includes: By simulating the interaction protocol of a MySQL database slave server, it disguises itself as a slave server corresponding to the master server of the MySQL database, so as to obtain the configuration-related information of the changes based on the dump protocol.

3. The method as described in claim 1 or 2, wherein obtaining the changed configuration-related information from the master server of the database based on the disguised identity of the slave server specifically includes: Send a data backup request to the master server of the database; Receive the binary logs pushed by the master server of the database in response to the data backup request; Based on the binary log, obtain the configuration-related information of the changes.

4. The method of claim 3, further comprising: Determine a node set constructed with several other nodes, so as to disguise the node set, including itself, as a slave server corresponding to the master server of the database; The step of obtaining the configuration-related information of the change based on the binary log specifically includes: The binary logs are filtered and selected to remove logs that are not related to the configuration data changes, so as to obtain the target logs that are related to the configuration data changes. The target log is sent to the other nodes so that the other nodes can obtain the configuration-related information of the change based on the target log.

5. The method as described in claim 1, wherein obtaining the changed configuration-related information from the master server of the database specifically includes: The configuration change instruction is obtained from the master server of the database. The configuration change instruction is sent to the database by at least one other node in the distributed cluster after making configuration data changes. The step of making corresponding changes in its own memory based on the changed configuration information specifically includes: According to the configuration change instruction, the corresponding configuration data is obtained from the database that stores the corresponding configuration data and updated to its own memory; or, By executing the configuration change instruction, the corresponding configuration data is changed in its own memory.

6. The method as described in claim 5, wherein the configuration change instruction includes an auto-incrementing identifier for recording the change order corresponding to different configuration change instructions; The step of obtaining the configuration change instruction from the master server of the database specifically includes: Determine the largest identifier of the configuration change commands that have been processed in its own records, and use it as the first identifier; Obtain the maximum identifier of the configuration change instruction stored in the master server of the database, and use it as the second identifier; Based on the difference between the second identifier and the first identifier, the corresponding incremental configuration change instruction is obtained from the master server of the database.

7. The method of claim 5, further comprising: After starting up, it obtains and records the maximum identifier of the configuration change command stored in the master server of the database; It retrieves the full set of configuration data it needs from the database that stores the corresponding configuration data, and updates it into its own memory.

8. The method of claim 5, further comprising: If a node is designated as a node for actively updating the database, it will write the corresponding configuration change instructions and / or configuration data into the database when the configuration data in its memory changes, so that other nodes can also update their configuration data according to the database.

9. The method of claim 6, the configuration change instruction further comprising: Change type and location information of the configuration data to be changed.

10. The method of claim 6, wherein the node comprises a server body and a camouflage module for performing the camouflage; The step of obtaining the maximum identifier of the configuration change instructions stored in the master server of the database specifically includes: The spoofing module determines whether configuration data changes have occurred by interacting with the database; If so, the server principal is notified accordingly to trigger the server principal to query the maximum identifier of the configuration change instruction stored in the master server of the database.

11. A configuration information processing device, applied to a node in a distributed cluster, the device comprising: The database determination module determines the database used to store configuration-related information for changes to nodes in the distributed cluster; The slave server masquerading module masquerades itself as a slave server corresponding to the master server of the database, including: determining a node set constructed with several other nodes, and masquerading the node set, including itself, as a slave server corresponding to the master server of the database; The change information acquisition module, based on the disguised identity of the slave server, obtains the configuration-related information of the change from the master server of the database; The configuration data change module makes corresponding changes in its own memory according to the configuration-related information of the change, so as to obtain the corresponding configuration data in the memory; When the master server of the database is unavailable, the data service responsibility of the master server is determined, the data service responsibility is decomposed into multiple data service sub-responsibilities, and the data service sub-responsibilities are distributed to multiple nodes of the node set.

12. The apparatus of claim 11, wherein the slave server masquerading module masquerades itself as a slave server corresponding to the master server of the MySQL database by simulating the interaction protocol of the slave server of the MySQL database, so as to obtain the configuration-related information of the changes based on the dump protocol.

13. The apparatus as described in claim 11 or 12, wherein the change information acquisition module sends a data backup request to the master server of the database; Receive the binary logs pushed by the master server of the database in response to the data backup request; Based on the binary log, obtain the configuration-related information of the changes.

14. The apparatus of claim 13, wherein the slave server masquerading module determines a node set constructed with several other nodes to masquerade the node set, including itself, as a slave server corresponding to the master server of the database; The change information acquisition module filters and selects from the binary logs, removing logs unrelated to configuration data changes, and obtains target logs related to configuration data changes. The target log is sent to the other nodes so that the other nodes can obtain the configuration-related information of the change based on the target log.

15. The apparatus of claim 11, wherein the change information acquisition module obtains a configuration change instruction from the master server of the database, the configuration change instruction being sent to the database by at least one other node in the distributed cluster after making a configuration data change; The configuration data modification module, according to the configuration modification instruction, retrieves the corresponding configuration data from the database storing the corresponding configuration data and updates it to its own memory; or, By executing the configuration change instruction, the corresponding configuration data is changed in its own memory.

16. The apparatus of claim 15, wherein the configuration change instruction includes an auto-incrementing identifier for recording the change order corresponding to different configuration change instructions; The change information acquisition module determines the largest identifier of the configuration change instructions that it has recorded that have been processed, and uses it as the first identifier; Obtain the maximum identifier of the configuration change instruction stored in the master server of the database, and use it as the second identifier; Based on the difference between the second identifier and the first identifier, the corresponding incremental configuration change instruction is obtained from the master server of the database.

17. The apparatus of claim 15, wherein the change information acquisition module acquires and records the maximum identifier of the configuration change instruction stored in the master server of the database after the node itself starts up; It retrieves the full set of configuration data it needs from the database that stores the corresponding configuration data, and updates it into its own memory.

18. The apparatus of claim 15, further comprising: The change information writing module, if the node itself is designated as a node for actively updating the database, will write the corresponding configuration change instructions and / or configuration data into the database after the configuration data in its own memory changes, so that other nodes can also update their configuration data according to the database.

19. The apparatus of claim 16, wherein the configuration change instruction further comprises: Change type and location information of the configuration data to be changed.

20. The apparatus of claim 16, wherein the node comprises a server body and a camouflage module for performing the camouflage; The spoofing module determines whether configuration data changes have occurred by interacting with the database; If so, the server principal is notified accordingly to trigger the server principal to query the maximum identifier of the configuration change instruction stored in the master server of the database.

21. A configuration information processing device, applied to a node in a distributed cluster, the device comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: Determine a database for storing configuration-related information for changes to nodes in the distributed cluster; Disguising itself as a slave server corresponding to the master server of the database includes: determining a node set constructed with several other nodes, so as to disguise the node set, including itself, as a slave server corresponding to the master server of the database; Based on the disguised identity of the slave server, obtain the configuration-related information of the changes from the master server of the database; Based on the configuration-related information of the changes, corresponding changes are made in its own memory so that the corresponding configuration data can be obtained in the memory; When the master server of the database is unavailable, the data service responsibility of the master server is determined, the data service responsibility is decomposed into multiple data service sub-responsibilities, and the data service sub-responsibilities are distributed to multiple nodes of the node set.

Images