etcd協調服務、raft協議、GRPC協議的原理是什么

etcd協調服務、raft協議、GRPC協議的原理是什么，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

etcd是將數據存儲在集群中的高可用k-v存儲。
允許應用實時監聽存儲中的k-v變化。
能容忍單點故障，能夠應對網絡分區。

(raft是一個分布式協議，管理的是日志；etcd管理的是k-v，把k-v放到日志里，kv就編程分布式集群了)

(調用者寫入請求發給leader請求寫入k-v，leader會將日志實時向follower們復制，leader不會立即返回給調用者，會馬上往集群follower做日志拷貝。當日志被復制給N+1個節點后(即大多數)，本地提交(也就是告訴客戶端提交成功)，返回給調用者(客戶端)，為什么復制給N+1,而不是2N+1后就告訴客戶端成功了呢？這就是大多數協議，也就是抽屜理論的重要表現)

(一旦完成提交，leader會周期性把自己的提交信息告訴所有follower，這樣，其他follower也會完成它們的本地提交(這是異步行為，不需要同步，只需要確保日志復制給大多數了就可以)。官方給出的寫入性能是:1000次每秒)

(raft協議本身就是在寫日志。第1行是leader節點的日志，后面是4個是follower，也就是總共5個節點。日志是隨著請求順序追加，這里5個節點的大多數是3個節點。其中1-7已經被復制給了3個節點(大多數)，這些是一定可以被提交不會丟失的，因為已經復制給大多數了。8總共只有兩個節點有，8后面其他的更夸張。有的連3,4,5都沒有，這一般是leader和follower之間產生了網絡延遲，然而，沒關系，只要復制給大多數就不會丟了。所以真個日志的提交已經到了第7個日志)


(
第一個leader幸運是f，f寫入了3條數據(標識為1的綠色塊)，并成功復制給了所有節點，然后f宕機了又馬上重啟。
因為宕機，而f曾經是leader，于是重新選舉，踩了狗屎很幸運，f又成了leader。f又提交了3條記錄(標識為2的紫色塊)，但它沒有復制給集群中的其他節點(可能f剛成為leader沒來得及復制給其他節點又掛掉了)。
f宕機后重啟，又踩了狗屎成為了第三任leader，寫入5條數據(下標為3的橙色塊)，沒來得及復制有宕了。
然后第四任leader幸運的是e，e寫入了4條數據(下標為4的×××塊)，但它作為leader期間，只把前面兩條(下標為4的×××塊)數據復制給大多數節點，后兩個沒來得及復制就宕了......
)


(leader寫入數據，但只復制給了一個follower，其他由于網絡原因沒復制，所以無法提交，無法給客戶端應答，客戶端繼續等待...)

(raft協議是底層原理，etcd將k-v寫入storage才是真的。當復制給大多數后，leader就告訴客戶端：你的事已經辦好了)

(當old leader重啟后，它發現已經有了一個新leader，并且它的數據是落后于new leader的，所以new leader會把a=2復制給old leader，而old leader會發現，原來的a=1沒有復制給大多數(未提交狀態)，而a=2已經完成了大多數復制，所以a=2會覆蓋掉a=1。所以在集群中a=2而不是1)


(etcd支持通用的http+json協議，但性能較低。sdk內置GRPC協議，性能很高。GRPC是谷歌開源的RPC協議，是基于http2協議。我們用的etcd就是基于GRPC的。我們通過sdk操作etcd中的k-v)

(能實現像redis一樣的時間過期)

(用有序的key模擬出目錄的效果。也就是只要定位到/feature-flags，就能根據它找到類似該目錄下的所有目錄(其實是key))

(即便key1=value3覆蓋了之前的key1=value1，在etcd中也會有key1=value1這個歷史版本(也就是revision=1)。然而我們只關心最新的數據，可以用compact命令完成刪減)

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。