CN115002073B

CN115002073B - Data updating method and system based on improved RAFT

Info

Publication number: CN115002073B
Application number: CN202210732226.5A
Authority: CN
Inventors: 左鹏; 贺智谋; 张海阔; 杨卫平; 左拔山
Original assignee: China Internet Network Information Center
Current assignee: China Internet Network Information Center
Priority date: 2022-06-23
Filing date: 2022-06-23
Publication date: 2023-06-23
Anticipated expiration: 2042-06-23
Also published as: CN115002073A

Abstract

The application discloses a data updating method and system based on improved RAFT, wherein the method is applied to a system consisting of a client, a main node and a sub node, and a message module stores at least one data updating request sent by the client into an original message queue; the message module merges at least one data updating request in the original message queue to obtain a request to be updated and stores the request into a sliding window queue; the consensus module sends a request to be updated to each child node in the system, and when the number of the first confirmation messages exceeds a preset threshold value, sends a second confirmation message to each child node; the consensus module writes the request to be updated into a log; the DNS updating module acquires the request to be updated from the log and sends the request to be updated to the DNS service module; the DNS service module acquires an update processing result corresponding to the request to be updated, and feeds the update processing result back to the client corresponding to the request to be updated.

Description

Data updating method and system based on improved RAFT

Technical Field

The invention relates to the technical field of information, in particular to a data updating method and system based on improved RAFT.

Background

DNS is an identification resolution scheme mainly used by the internet, and provides basic services for upper-layer internet applications through a distributed system based on global deployment. Functionally, the DNS system includes an authoritative DNS and a recursive DNS, where the authoritative DNS is responsible for publishing DNS namespaces and domain name data, and the recursive DNS is responsible for brokering DNS requests of internet users, and returns analysis results to the users after initiating recursive analysis to the authoritative DNS system.

In actual deployment, in order to improve service availability and service performance, an authoritative DNS physically adopts a multilevel deployment networking manner with a tree structure. Similar to the tree structure of the DNS domain name space, the primary node of the system is a primary master node, which is the data source of the authoritative DNS system, and each secondary node below the primary node is an auxiliary server node of the superior node and is the master server node of the inferior node. Each level of nodes realizes data update issue through the IXFR (incremental update) and AXFR (full update) protocols of the DNS.

In this mode, there are two problems: 1. single master dependency on primary master node. Although DNS is deployed in a distributed manner, single point failure hidden danger is eliminated at the resolution level. However, in the data transmission layer, when a traditional hierarchical networking mode is adopted, a primary master node in an authoritative DNS system is a unique data transmission source of the system, and once the master node fails, the whole system cannot transmit data. 2. Performance problems when data updates are high in concurrency. On the one hand, when the hierarchical network is constructed, data update is transmitted to the leaf nodes through multi-layer transmission, on the other hand, the next data update of the traditional DNS data increment update mode (IXFR) needs 4 RTTs, and the efficiency is low. According to the related actual operation data, in the traditional networking mode, when the server deployment has the conditions of crossing continents and operators, the data is updated to the leaf nodes at least to the second level. When data updates are highly concurrent (e.g., domain name preemption), a large amount of data will be caused to wait for the update, and the delay may reach the minute or even hour level. The authoritative DNS system of the registration management mechanism of the top-level domain name solves the two problems and has important significance for improving the domain name service capability.

Disclosure of Invention

The application provides an authoritative DNS networking method and system based on improved RAFT, which aim to solve two problems of single-point fault risk of a primary master node and limited data issuing performance in high concurrency under the traditional networking mode of authoritative DNS, and improve the usability and service performance of the authoritative DNS.

In a first aspect, the present application provides an improved RAFT-based data updating method, applied to a system formed by a client, a master node and a child node, where the master node is configured with a message module, a consensus module, a DNS updating module and a DNS service module; the method comprises the following steps:

the message module stores at least one data update request sent by the client into an original message queue;

the message module merges at least one data updating request in the original message queue to obtain a request to be updated and stores the request into a sliding window queue; in the sliding window queue, all the requests to be updated are arranged according to serial numbers corresponding to time stamps of the requests;

the consensus module sequentially sends the request to be updated in the sliding window queue to each child node in the system according to the serial numbers so as to acquire a first confirmation message which is fed back by each child node and corresponds to the request to be updated;

when the number of the first confirmation messages corresponding to the request to be updated exceeds a preset threshold, the consensus module generates a second confirmation message corresponding to the request to be updated and sends the second confirmation message to each child node;

the consensus module writes the request to be updated, which generates the second confirmation message, into a log according to the sequence of the sequence number; in the log, the requests to be updated are arranged according to the size of the serial number;

the DNS updating module acquires the request to be updated with the minimum serial number from the log, and sends the request to be updated to the DNS service module;

and the DNS service module acquires an update processing result corresponding to the request to be updated and feeds the update processing result back to the client corresponding to the request to be updated.

In one implementation, the step of the message module obtaining the data update request includes:

and the message module receives the data updating request sent by the client and/or receives the data updating request from the client sent by the child node.

In one implementation, the message module merges at least one of the data update requests in the original message queue, obtains a request to be updated, and stores the request into a sliding window queue, including:

the message module acquires a plurality of data updating requests from the original message queue, and combines the data updating requests according to different DNS regions to generate a plurality of sets; the DNS zones for data update requests in a single set are the same;

and respectively generating one request to be updated from each set.

In one implementation, the step of the consensus module sequentially sending the request to be updated in the sliding window queue to each of the child nodes in the system according to the sequence number includes:

the consensus module sequentially sends the to-be-updated requests in the sliding window queue to receiving windows in all child nodes in a system; the sliding window is used for accommodating a preset number of requests to be updated, and the preset number corresponds to the maximum number of the receiving windows in the child nodes for receiving the requests to be updated.

In one implementation, the method for determining the preset number includes:

the consensus module acquires receiving window information sent by all child nodes in the system; the receiving window information is the maximum number of the sub-nodes receiving the request to be updated;

the consensus module is used for sorting all the receiving window information according to the increasing order of the values according to the receiving window information to obtain a value queue;

the consensus module determines a median of the numerical queue as the preset number.

In one implementation manner, the step of sequentially writing the to-be-updated request for generating the second acknowledgement message into the log in the sequence of the sequence numbers according to the sequence numbers includes:

setting the request to be updated corresponding to the second confirmation message in the sliding window queue to be in a confirmation state;

traversing the sliding window queue, and judging whether all the requests to be updated with the serial numbers before the requests to be updated are in a confirmation state or not;

if yes, writing the request to be updated, which is set to be in a confirmation state, into the log;

and removing the sliding window from the to-be-updated request written into the log.

In one implementation, after removing the sliding window from the to-be-updated request written to the log, the method further comprises:

judging whether the number of the requests to be updated in the sliding window is smaller than a preset number or not;

if yes, adding a first number of the to-be-updated requests which are positioned outside the sliding window and are close to the sliding window into the sliding window; the first number is the difference between the preset number and the number of the requests to be updated in the sliding window.

In a second aspect, the present application provides an improved RAFT-based data update system comprising: the system comprises a message module, a consensus module, a DNS updating module and a DNS service module;

the message module is configured to: storing at least one data update request sent by a client into an original message queue, wherein at least one data update request in the original message queue is combined to obtain a request to be updated and stored into a sliding window queue;

the consensus module is configured to: the request to be updated in the sliding window queue is sequentially sent to each child node in the system according to the sequence number, so that first confirmation messages corresponding to the request to be updated, which are fed back by each child node, are obtained, when the number of the first confirmation messages corresponding to the request to be updated exceeds a preset threshold, the consensus module generates second confirmation messages corresponding to the request to be updated, and sends the second confirmation messages to each child node, wherein the request to be updated, which generates the second confirmation messages, is sequentially written into a log according to the sequence of the sequence number according to the sequence number;

the DNS update module is configured to: acquiring the request to be updated with the minimum serial number from the log, and sending the request to be updated to the DNS service module;

the DNS service module is configured to: and acquiring an updating processing result corresponding to the request to be updated, and feeding back the updating processing result to the client corresponding to the request to be updated.

According to the technical scheme, the single-master fault risk of the authoritative DNS in the traditional networking mode based on the master-slave layered architecture is effectively relieved through the flattened networking mode, and the robustness and the usability of the domain name system are improved. Meanwhile, by combining the characteristics of DNS data updating, the synchronization mechanism of the RAFT is improved to improve the synchronization efficiency, and on one hand, the batch processing of DNS updating operation is realized through message merging; on the other hand, through realizing the concurrent processing of the DNS message based on the sliding window, the order and the state of the message can be ensured to be consistent finally. In addition, by using the method, the issuing speed of the leaf nodes can be obviously reduced, the traditional three-level networking is taken as an example, 8 times of interaction are needed when data are issued from the main node to the leaf nodes, and the interaction times are reduced to 3 times under the method.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following description will briefly explain the drawings used in the embodiments or the description of the prior art, and it is obvious that the drawings in the following description are only embodiments of the present invention, and other drawings can be obtained according to the provided drawings without inventive effort to a person skilled in the art.

FIG. 1 is a flow chart of a data update method based on improved RAFT provided by the present application;

FIG. 2 is a schematic diagram of an improved RAFT-based data updating method provided in the present application;

FIG. 3 is a schematic diagram of a sliding window queue in a data update method based on improved RAFT provided in the present application;

FIG. 4 is a flowchart for determining a preset number in an improved RAFT-based data updating method provided in the present application;

FIG. 5 is a flowchart of writing a request to be updated into a log in an improved RAFT-based data updating method provided by the present application;

FIG. 6 is a schematic diagram of sliding a sliding window in a data updating method based on improved RAFT provided by the present application;

FIG. 7 is a schematic diagram of message confirmation in an improved RAFT-based data update method provided in the present application;

FIG. 8 is a schematic diagram of one of the cases of writing a request to be updated into a log in the improved RAFT-based data updating method provided in the present application;

fig. 9 is a schematic diagram of another case of writing a request to be updated into a log in the data updating method based on improved RAFT provided in the present application.

Detailed Description

It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.

The method and the device solve the problem of single-master dependence of the traditional authoritative DNS traditional networking on the primary master node in the prior art. Although DNS is deployed in a distributed manner, single point failure hidden danger is eliminated at the resolution level. However, in the data transmission layer, when a traditional hierarchical networking mode is adopted, a primary master node in an authoritative DNS system is a unique data transmission source of the system, and once the master node fails, the whole system cannot transmit data. There are also performance problems when data updates are high in concurrency. On the one hand, when the hierarchical network is constructed, data update is transmitted to the leaf nodes through multi-layer transmission, on the other hand, the next data update of the traditional DNS data increment update mode (IXFR) needs 4 RTTs, and the efficiency is low. According to the related actual operation data, in the traditional networking mode, when the server deployment has the conditions of crossing continents and operators, the data is updated to the leaf nodes at least to the second level. When data updates are highly concurrent (e.g., domain name preemption), a large amount of data will be caused to wait for the update, and the delay may reach the minute or even hour level.

The data updating method and system based on improved RAFT of the present invention are further described below with reference to specific embodiments.

In this embodiment, it is first to be understood that: DNS servers are abbreviations for computer domain name systems (Domain Name System or Domain Name Service) that consist of a domain name resolver and a domain name server. The domain name server is a server which stores domain names and corresponding IP addresses of all hosts in the network and has a function of converting the domain names into IP addresses. Where the domain name must correspond to an IP address and the IP address does not necessarily have a domain name. The domain name system adopts a hierarchical structure like a directory tree. The domain name server is the server side in client/server mode, and has mainly two forms: a primary server and a forwarding server. The process of mapping a domain name to an IP address is known as "domain name resolution".

In this application, a RAFT algorithm is applied, in which a leader can be selected by election, that is, in this embodiment, all nodes in the system are configured with a message module, a consensus module, a DNS update module, and a DNS service module, and a master node can be selected by election.

In a first aspect, as shown in fig. 1, the present application provides an improved RAFT-based data updating method, which is applied to a system formed by a client, a master node and a child node, where the master node is configured with a message module, a consensus module, a DNS updating module and a DNS service module; wherein the message module is configured to receive and combine the data update requests; the consensus module is configured to make the main node and the sub-nodes in the system obtain consensus; the DNS updating module is configured to inform all child nodes in the system to implement updating operation; the DNS service module is configured to receive a request to be updated and provide a service to the outside, the above module performing the following method steps, the method comprising:

s100, the message module stores at least one data update request sent by the client into an original message queue;

in step S100, the message module receives the data update request sent by the client, and/or the message module receives the data update request sent by the child node from the client.

In an actual application scene, a client needs to send a data update request to a main node in a system, and if the request is received by the main node, a message module configured by the main node performs subsequent processing operation on the received data update request; meanwhile, since the client may not know which is the master node in the system, there may be a case that the client missends the request to the child node, in this case, the child node may forward the received request to the master node, and then the message module of the master node performs subsequent processing operation on the received data update request. Wherein the data update request includes a host name.

S200, the message module merges at least one data updating request in the original message queue to obtain a request to be updated and stores the request into a sliding window queue; in the sliding window queue, all the requests to be updated are arranged according to serial numbers corresponding to time stamps of the requests;

in the practical application scenario, as shown in fig. 2 and fig. 3, the original message queue includes a plurality of data update requests, and it is assumed that the original message queue includes MSG1, MSG2, MSG3, MSG4, MSG5, and MSG6, and these 6 data update requests, when performing the subsequent operation, based on two features of DNS data update, strict timing needs to be guaranteed and the guaranteed states are eventually consistent, so the data update requests received by the message module need to be merged together in time sequence, that is, the corresponding Entry1 needs to be stored in the sliding window queue by merging MSG1 and MSG2, the corresponding Entry2 needs to be stored in the sliding window queue by merging MSG3 and MSG6, and the corresponding Entry3 needs to be stored in the sliding window queue by merging MSG5 and MSG6, where it needs to be noted that the Entry1, the Entry2, and the Entry3 need to be arranged in time sequence in the sliding window queue, the Entry1 may be a transmitted and the update request to be confirmed, and the Entry2 may not be transmitted and the update request to be confirmed.

In step S200, the message module obtains a plurality of data update requests from the original message queue, and merges the data update requests according to different DNS zones to generate a plurality of sets; the DNS zones for data update requests in a single set are the same; and respectively generating one request to be updated from each set.

In this embodiment, the data update request is transmitted using JSON format, the format definition example is as follows:

original MSG requests ADD packet format:

original MSG request DEL packet format:

merged Entry1 format:

wherein, MSG_SEQ is a sequence number of data update request, each data update request is increased; ZONE designates which ZONE the data update request is valid for; the SOA designates the SOA sequence number change of the data updating request; ADD specifies the record for which the data update request is added; the DEL specifies the record that the data update request needs to delete.

The message module acquires N data updating requests (N can be determined through configuration) from an original message queue every time by polling, respectively combines the N data updating requests according to different DNS zones (Zone) to form M to-be-synchronized to-be-updated requests, and inserts the to-be-updated requests into a sliding window queue (M < =N, M is the number of zones). The DNS Zone is a Zone (Zone) in which a DNS name space is divided to manage DNS name management workload for the purpose of distributing the workload according to actual situations. The rule for merging is: dividing N data update requests into M sets according to a DNS Zone (DNS Zone), merging X data update requests of the same Zone, wherein the merging rule conforms to the following specifications:

1. the merging is orderly merging, and merging is carried out strictly according to the SOA sequences corresponding to the updating requests from small to large;

2. the granularity of the merge is accurate to the request resource record (IN the example below: www.example.com IN 360A1.1.1.1 is referred to as one resource record IN its entirety);

3. ADD-DEL operation is performed on the same resource record in the merging process, and no operation is performed after the merging process;

4. merging the data of different resource types, and directly adding the resource records into an operation set of the corresponding operation type (ADD or DEL);

5. only one operation can exist for the same resource record after merging, and the ADD operation and the DEL operation for the same resource record cannot exist at the same time: the merged ADD and DEL sets have no intersection.

6. In the combined SOA, the 0rig SOA is the Original SOA of the first message, and the NEW SOA is the NEW SOA of the last message. When the request to be updated is stored in the sliding window queue, the corresponding serial numbers are required to be generated according to the time stamps of the request to be updated, and the request to be updated is required to be arranged according to the corresponding serial numbers during arrangement. Illustratively, the data update request merge rule is:

assume that five data update requests MSG1, MSG2, MSG3, MSG4, and MSG5 are as follows:

the request to be updated after the MSG1-MSG5 are combined is as follows:

s300, the consensus module sequentially sends the request to be updated in the sliding window queue to each child node in the system according to the serial numbers so as to acquire a first confirmation message corresponding to the request to be updated, wherein the first confirmation message corresponds to the request to be updated and is fed back by each child node;

in step S300, the consensus module sequentially sends the request to be updated in the sliding window queue to a receiving window in each child node in the system; the sliding window is used for accommodating a preset number of requests to be updated, and the preset number corresponds to the maximum number of the receiving windows in the child nodes for receiving the requests to be updated. Exemplary, the method for determining the preset number includes:

s310, the consensus module acquires receiving window information sent by all child nodes in the system; the receiving window information is the maximum number of the sub-nodes receiving the request to be updated;

s320, the consensus module progressively sorts all the receiving window information according to the size of the numerical value according to the receiving window information to obtain a numerical value queue;

s330, the consensus module determines the median of the numerical queue as the preset number.

In this embodiment, the consensus module needs to sequentially send the request to be updated in the sliding window queue to each child node in the system according to the sequence number, where when the consensus module sends the request to be updated, in order to utilize the bandwidth to the maximum extent, improve the synchronization efficiency, optimize the serial processing of the message of the traditional RAFT, design a synchronization mechanism based on the sliding window, implement the mechanism of processing the message concurrently, and need to send the next request to be updated after the first request to be updated is sent, regardless of whether the first acknowledgement message of the child node is received or not. The initial size of the receiving window can be determined by configuration, and the preset number of the sliding windows needs to be determined according to the size of the receiving window, so as to improve the issuing speed, ensure that more than half of the child nodes can be processed in time, and take the maximum acceptable window of one half of the child nodes as the preset number of the sliding windows of the main node.

In an actual application scenario, as shown in fig. 4, the preset number setting method is as follows: assuming that 5 sub-nodes exist in the system, configuring initial sizes of receiving windows of the 5 sub-nodes respectively, wherein node one is 3; the second node is 6; node three is 5; node four is 2; node five is 4. When the preset number of the sliding windows is calculated, the receiving window sizes of all the child nodes are required to be formed into an ordered queue according to incremental sequencing, namely, a node four, a node one, a node five, a node three and a node two, and the receiving window size of the node five is selected as the preset number of the sliding windows of the main node.

S400, when the number of the first confirmation messages corresponding to the request to be updated exceeds a preset threshold, the consensus module generates a second confirmation message corresponding to the request to be updated and sends the second confirmation message to each child node;

in this embodiment, the sending and confirming of a request to be updated includes three links: the consensus module sends a request to be updated to the child node; the child node sends a first message acknowledgement (ack_i) to the consensus module; after receiving the first message acknowledgement (ack_1) of the child node with the preset threshold, the consensus module sends a second acknowledgement message (ack_2) to all child nodes. That is, to ensure the ordering and validity of the request to be updated, two conditions are satisfied to write a request to be updated into a LOG (LOG): the first is that the child node that the request to be updated has passed the preset threshold confirms (i.e. ack_2 state), and the second is that all requests to be updated before the request to be updated have been Logged (LOG). If the LOG (LOG) is not written in the request to be updated before the request to be updated, the request to be updated is kept in the window until all the previous requests to be updated are processed. The preset threshold value can be any value within 51% -99%. As shown in fig. 5, the step of sequentially writing the to-be-updated requests for generating the second acknowledgement message into the log in the order of the sequence numbers according to the sequence numbers includes:

s410, setting the request to be updated corresponding to the second confirmation message in the sliding window queue to be in a confirmation state;

s420, traversing the sliding window queue, and judging whether all the requests to be updated with the serial numbers before the requests to be updated are in a confirmation state or not;

if yes, executing S430, and writing the request to be updated, which is set to be in a confirmation state, into the log;

if not, executing S450, and waiting for all the requests to be updated before the requests to be updated are in a confirmation state;

s440, removing the sliding window from the request to be updated written into the log.

After removing the sliding window from the to-be-updated request written to the log, the method further includes: judging whether the number of the requests to be updated in the sliding window is smaller than a preset number or not; if yes, adding a first number of the to-be-updated requests which are positioned outside the sliding window and are close to the sliding window into the sliding window; the first number is the difference between the preset number and the number of the requests to be updated in the sliding window.

In one embodiment, as shown in fig. 6, the preset number of the sliding window is calculated to be 9, that is, it is indicated that there are 9 to-be-updated requests in the sliding window, when the to-be-updated requests with

sequence numbers

5 and 6 have been confirmed, the to-be-updated requests with

sequence numbers

5 and 6 can be removed from the sliding window, at this time, the number of to-be-updated requests in the sliding window is 7, then, the difference between the number of to-be-updated requests in the current sliding window and the preset number of the sliding window is calculated, at this time, the calculated difference is 2, and then, it is required to add 2 to-be-updated requests which are outside the sliding window and are closest to the sliding window, that is, add to-be-updated requests with

sequence numbers

14 and 15 to the sliding window, which is equivalent to sliding window sliding backward by two positions.

The method aims at improving the synchronization mechanism of the RAFT to improve the synchronization efficiency by combining the characteristics of DNS data update, and on one hand, batch processing of DNS update operation is realized by combining data update requests; on the other hand, through the concurrent processing of the data updating request based on the sliding window, the order and the state of the message can be ensured to be consistent finally. In addition, as shown in fig. 7, the method of the present application can obviously reduce the issuing speed of the master node, taking the traditional three-level networking as an example, 8 interactions are needed when the request to be updated is issued from the master node to the child node, and the number of interactions is reduced to 3 under the method of the present application. Among them, it is to be understood that: raft is a "consistency" algorithm for managing replication logs. Consistency is a fundamental problem of distributed system fault tolerance. A group of machines works like a whole, and can continue to work even if a small half of the machines (not more than N/2) fail, once they make a decision about the state, the decision is the final decision.

RAFT has three roles: leader, follower and Candidate, wherein their roles are:

leader (Leader): processing all client interactions, log replication, etc., typically only one Leader at a time;

follower (Follower): responding to the log synchronization request of the Leader, responding to the invitation ticket request of the Candidate, and forwarding (redirecting) the transaction of the client request to the follow to the Leader;

candidate (Candidate): the method is in charge of electing and voting, when a cluster is just started or a Leader is down, a node with a role of a follow is converted into a Candidate and election is started, and after electing and winning (obtaining votes of more than half nodes), the node is converted into a Leader role from the Candidate;

s500, the consensus module writes the request to be updated, which generates the second confirmation message, into a log according to the sequence of the sequence number; in the log, the requests to be updated are arranged according to the size of the serial number;

in this embodiment, the log is used to record the request to be updated of the confirmation status, where the request to be updated needs to be ordered according to the serial number. The logs are written in sequence according to the sequence of the serial numbers, so that the sub-node authentication that the request to be updated before the serial numbers passes through the preset threshold value is ensured, the parallel processing of the sliding window is realized, the strict time sequence is ensured, and the characteristic of DNS data updating is met.

In one embodiment, as shown in fig. 8, 3 requests to be updated, namely Entry1, entry2 and Entry3, are stored in the sliding window queue, when the consensus module receives the second acknowledgement message corresponding to Entry3, it needs to determine whether Entry and Entry2 have been logged, if Entry1 has been logged but Entry2 has not been logged, entry3 needs to wait for Entry2 to log, and if Entry1 and Entry2 have been logged, entry3 may directly log, as shown in fig. 9, where Entry1, entry2 and Entry3 are arranged according to the serial numbers.

S600, the DNS updating module acquires the request to be updated with the minimum serial number from the log, and sends the request to be updated to the DNS service module;

s700, the DNS service module acquires an update processing result corresponding to the request to be updated and feeds the update processing result back to the client corresponding to the request to be updated.

The DNS service module corresponds to the DNS service in the actual scene, and after the DNS service module receives the request to be updated, the request to be updated takes effect formally, and can provide services to the outside.

As can be seen from the above technical solutions, the embodiments of the present application provide an improved RAFT-based data updating method, which is applied to a system composed of a client, a master node and a child node, where the master node is configured with a message module, a consensus module, a DNS updating module and a DNS service module; the method comprises the following steps: the message module stores at least one data update request sent by the client into an original message queue; the message module merges at least one data updating request in the original message queue to obtain a request to be updated and stores the request into a sliding window queue; in the sliding window queue, all the requests to be updated are arranged according to serial numbers corresponding to time stamps of the requests; the consensus module sequentially sends the request to be updated in the sliding window queue to each child node in the system according to the serial numbers so as to acquire a first confirmation message which is fed back by each child node and corresponds to the request to be updated; when the number of the first confirmation messages corresponding to the request to be updated exceeds a preset threshold, the consensus module generates a second confirmation message corresponding to the request to be updated and sends the second confirmation message to each child node; the consensus module writes the request to be updated, which generates the second confirmation message, into a log according to the sequence of the sequence number; in the log, the requests to be updated are arranged according to the size of the serial number; the DNS updating module acquires the request to be updated with the minimum serial number from the log, and sends the request to be updated to the DNS service module; and the DNS service module acquires an update processing result corresponding to the request to be updated and feeds the update processing result back to the client corresponding to the request to be updated.

Therefore, the single-master fault risk of the authoritative DNS in the traditional networking mode based on the master-slave layered architecture is effectively relieved through the flattened networking mode, and the robustness and the usability of the domain name system are improved. Meanwhile, by combining the characteristics of DNS data updating, the synchronization mechanism of the RAFT is improved to improve the synchronization efficiency, and on one hand, the batch processing of DNS updating operation is realized through message merging; on the other hand, through realizing the concurrent processing of the DNS message based on the sliding window, the order and the state of the message can be ensured to be consistent finally.

The effects of the above system when the above method is applied may be referred to the description in the foregoing method embodiment, and will not be repeated here.

Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims

1. The data updating method based on the improved RAFT is applied to a system consisting of a client, a main node and a sub node, wherein the main node is configured with a message module, a consensus module, a DNS updating module and a DNS service module; characterized in that the method comprises:

generating a request to be updated from each set and storing the request into a sliding window queue; in the sliding window queue, all the requests to be updated are arranged according to serial numbers corresponding to time stamps of the requests;

2. The improved RAFT based data update method as recited in claim 1, wherein the step of the message module obtaining the data update request includes:

3. The improved RAFT based data updating method as recited in claim 1, wherein the step of the consensus module sequentially sending the request to be updated in the sliding window queue to each of the child nodes in the system according to the sequence number comprises:

4. A data updating method based on improved RAFT as claimed in claim 3, wherein the predetermined number determining method comprises:

5. The improved RAFT based data updating method as recited in claim 1, wherein said step of sequentially writing the order of the sequence numbers of the pending update requests for generating the second acknowledgement message to the log according to the sequence number comprises:

6. The improved RAFT based data update method as recited in claim 5, wherein after removing the sliding window from the pending update request written to the log, the method further comprises:

7. A data updating system based on improved RAFT, applied to the data updating method of claim 1, characterized in that the system is composed of a client, a master node and a child node, wherein the master node is configured with: the system comprises a message module, a consensus module, a DNS updating module and a DNS service module;

the consensus module is configured to: the sequence number sequentially sends the request to be updated in the sliding window queue to each child node in a system to obtain first confirmation messages corresponding to the request to be updated, which are fed back by each child node, when the number of the first confirmation messages corresponding to the request to be updated exceeds a preset threshold value, the consensus module generates second confirmation messages corresponding to the request to be updated, and sends the second confirmation messages to each child node, wherein the request to be updated, which generates the second confirmation messages, is sequentially written into a log according to the sequence of the sequence number according to the sequence number;