And for persistent nodes, there is an implementation of the Raft protocol
We know that the Raft algorithm is a CP protocol, which uses the Leader node to synchronize data to each node.
Therefore, it will first determine whether the current node is the Leader node, and if not, forward the request to the Leader node for processing.
And if it is the Leader node, then we will first write the data to the memory, and then write to the disk.
You can see that the addTask method of the notifier is called here
Then the subsequent process is still the same, the data in the memory will be updated according to the key put in, and finally the persistence strategy here will choose
The logic in else will be selected here.
One issue that needs to be considered here is that we are using the Raft protocol. The Raft protocol is based on selecting a Leader node for data synchronization, so it is necessary to ensure that there is a Leader node in the cluster. The election rule is the total number of nodes/2+1.
So if there are only three nodes in the cluster, and one of the nodes is down, then there are only two nodes and there is no way to choose a leader, which will cause problems.
That is to say, Nacos has to design a strategy to solve the problem of data synchronization when there are only two nodes, and less time to block.
Nacos uses the counter method of CountDownLaunch.
The above logic is very clear, the master node will directly put the data on the disk, and the slave node will send them a request to write to the disk, and after the disk is successfully written, the method will be called back, then the counter will be -1, as long as Finally, the counter is 0, then no error will be reported and the lock will be released, otherwise an error will be reported and the lock will be released.