Shulou(Shulou.com)06/02 Report--

What is the principle of etcd coordination service, raft protocol and GRPC protocol? many beginners are not very clear about this. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

Etcd is a highly available kmurv storage that stores data in a cluster.

Allows applications to listen for changes in kmurv in real-time storage.

Able to tolerate single point of failure and be able to deal with network partition.

(raft is a distributed protocol, which manages logs; etcd manages KMurv, and kv programs distributed clusters by putting KMTV into logs.)

(the caller's write request is sent to the leader request to write the log to the follower leader. The log will be copied to the follower in real time. The leader will not immediately return the log to the caller, but will immediately copy the log to the cluster follower. After the log is copied to the Node 1 (that is, most), it is submitted locally (that is, it tells the client that the commit was successful) and returned to the caller (the client). Why is it copied to Novel1 instead of 2N+1 and then told the client that it was successful? This is an important manifestation of most protocols, that is, drawer theory.

Once the commit is completed, leader periodically tells all follower its commit information, so that other follower will also complete their local commit (this is asynchronous, there is no need for synchronization, just make sure that the log is copied to most). The official write performance is: 1000 writes per second)

(the raft protocol itself is journaling. The first line is the log of the leader node, followed by four follower, that is, a total of five nodes. The log is appended in the order of requests, where most of the 5 nodes are 3 nodes. Of these, 1-7 has been replicated to 3 nodes (most), and these must be committed and will not be lost, because they have been replicated to most. There are only two nodes in total, and the others after 8 are more exaggerated. Some don't even have 3Jing 4 and 5, which is usually caused by the network delay between leader and follower. However, it doesn't matter, as long as you copy it to most people, you won't lose it. So the submission of the real log has reached the 7th log)

(

Luckily for the first leader, f wrote three pieces of data (green blocks identified as 1) and successfully copied them to all nodes, and then f went down and immediately restarted.

Because of the downtime, and f used to be leader, so re-election, stepped on dog shit is very lucky, f has become a leader. F submitted three more records (the purple block identified as 2), but it was not copied to other nodes in the cluster (maybe f just became a leader and then failed to copy to other nodes).

F restart after downtime, stepped on dog shit to become the third leader, wrote 5 pieces of data (orange block with subscript 3), and didn't have time to copy it.

Then the fourth leader luckily wrote four pieces of data (× × × blocks with subscript 4), but during the period of leader, only the first two pieces of data (× × × blocks with subscript 4) were copied to most nodes, and the last two were shut down before they could be copied.

)

(leader writes data, but only replicates to one follower. The other is not replicated due to network reasons, so it cannot be submitted and cannot reply to the client. The client continues to wait.)

(the raft protocol is the underlying principle, and it is true that etcd writes KMurv to storage. After copying it to most, leader tells the client: your job is done.)

When old leader restarts, it finds that it already has a new leader, and its data is lagging behind new leader, so new leader replicates Atrop2 to old leader, while old leader finds that the original AQ1 has not been replicated to the majority (uncommitted state), while April2 has completed most of the replication, so Asp2 will overwrite April1. So in the cluster, axi2 instead of 1)

(etcd supports the general http+json protocol, but its performance is low. Sdk has built-in GRPC protocol with high performance. GRPC is Google's open source RPC protocol, based on the http2 protocol. The etcd we use is based on GRPC. We operate the kmurv in etcd through sdk)

(can achieve the same time expiration as redis)

(use ordered key to simulate the effect of the directory. That is, as long as you navigate to / feature-flags, you can find all directories similar to that directory (actually key) according to it.

(even if key1=value3 overwrites the previous key1=value1, there will be a historical version of key1=value1 (that is, revision=1) in etcd. However, we are only concerned with the latest data, which can be deleted with the compact command)

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.