• ????歡迎點(diǎn)贊 ：???? 收藏 ?留言 ???? 如有錯(cuò)誤敬請(qǐng)指正，賜人玫瑰，手留余香！

• ????本文作者：由webmote 原創(chuàng)，首發(fā)于 【掘金】

• ????作者格言：生活在于折騰，當(dāng)你不折騰生活時(shí)，生活就開始折騰你，讓我們一起加油！????????????

???? 序言

以往在架構(gòu)選項(xiàng)的時(shí)候，大概了解其做什么的，有什么優(yōu)劣就夠了，因?yàn)榇蟛糠只ヂ?lián)網(wǎng)企業(yè)比較輕文檔重快速迭代，往往并不會(huì)糾結(jié)過(guò)多的選型方案。

只要方案合適，干就行了。

遙憶剛工作那會(huì)，流行瀑布式開發(fā)模式，方案和需求的重要性放在最頂級(jí)的位置，往往方案需要寫幾十上百頁(yè)，關(guān)鍵的技術(shù)選項(xiàng)還需要編寫關(guān)鍵技術(shù)選項(xiàng)，經(jīng)過(guò)好幾輪的評(píng)審才可能最終走向需求、概要、詳細(xì)和總結(jié)。當(dāng)然評(píng)審里領(lǐng)導(dǎo)各種角度的問(wèn)題，往往讓人不知所措。

經(jīng)過(guò)這些年的“放松”，編寫技術(shù)文檔的水平也越來(lái)越差了，甚至于很多中間件也只是了解個(gè)皮毛，深層次的原理都不愿意仔細(xì)看看，只關(guān)注怎么能利用這些中間件干點(diǎn)什么事上。

這不，開始碰壁了，因?yàn)槿鄙倮碚搶用娴闹笇?dǎo)，很多過(guò)去認(rèn)為理所當(dāng)然的事情，在需要仔細(xì)闡述并爭(zhēng)取領(lǐng)導(dǎo)同意上，就遇到了自己解釋不清楚的各種問(wèn)題。

怎么能快速說(shuō)服領(lǐng)導(dǎo)上，遇到了很大的阻力。也讓我看清楚了自己的問(wèn)題之所在：缺乏理論依據(jù)。當(dāng)然作為大領(lǐng)導(dǎo)是否需要深入的介入技術(shù)問(wèn)題在這里不談，因?yàn)槿松ㄒ蛔畲蟮氖?#xff0c;莫過(guò)于修煉自身。

因此這篇文章送給我自己，修煉重在點(diǎn)滴間。

???? 01.ETCD是干啥的?

etcd是一種高一致的分布式鍵值存儲(chǔ)，它提供了一種可靠的方式來(lái)存儲(chǔ)需要由分布式系統(tǒng)或機(jī)器集群訪問(wèn)的數(shù)據(jù)。它在網(wǎng)絡(luò)內(nèi)優(yōu)雅地處理領(lǐng)導(dǎo)者選舉，并且可以容忍機(jī)器故障，就算是領(lǐng)導(dǎo)者故障也不會(huì)影響高一致性。

作為高一致性解決方案三劍客之一的ETCD（其他還有ZooKeeper、Consul），其最大的特點(diǎn)就是保持高一致性。

???? 02.一致性的概念

一致性是分布式系統(tǒng)提出的一個(gè)概念，因?yàn)閷?duì)于單機(jī)系統(tǒng)，幾乎不存在一致性的問(wèn)題。

而為了解決單機(jī)存儲(chǔ)的單點(diǎn)故障，就從架構(gòu)上升級(jí)為了主備系統(tǒng)，備份系統(tǒng)使用各種方案對(duì)主系統(tǒng)上的數(shù)據(jù)進(jìn)行備份，以便保持和主系統(tǒng)的數(shù)據(jù)同步。

而一旦開始復(fù)制數(shù)據(jù)，那么就產(chǎn)生了一致性的問(wèn)題。

一致性的定義：對(duì)某個(gè)指定的客戶端，讀操作能保證返回最新的寫操作的結(jié)果。

???? 2.1 CAP定理

作為分布式系統(tǒng)中的最基礎(chǔ)的定理，CAP是由加州大學(xué)的布魯爾最先提出的一個(gè)猜想，最后被證明，而使之成為分布式計(jì)算領(lǐng)域公認(rèn)的定理，因此也被稱作布魯爾定理。

CAP定理是說(shuō)在一個(gè)分布式系統(tǒng)（互相鏈接并共享數(shù)據(jù)節(jié)點(diǎn)的集合）中，當(dāng)涉及讀寫操作時(shí)，只能保證一致性（Consistency）、可用性（Avaliability）、分區(qū)容錯(cuò)性（Partition Tolerance)三者中的兩個(gè)，另外一個(gè)必須被犧牲。

可用性指非故障節(jié)點(diǎn)在合理的時(shí)間內(nèi)返回合理的響應(yīng)（不包含錯(cuò)誤和超時(shí)）。
分區(qū)容錯(cuò)：指當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)后，系統(tǒng)能夠繼續(xù)履行職責(zé)。換句話說(shuō)，系統(tǒng)部分節(jié)點(diǎn)出現(xiàn)故障后，連接正常節(jié)點(diǎn)還可以使用系統(tǒng)提供的服務(wù)。

不懂就搜，分區(qū)容錯(cuò)這個(gè)概念不好理解，因此這里引用知乎的回答。

一個(gè)分布式系統(tǒng)里面，節(jié)點(diǎn)組成的網(wǎng)絡(luò)本來(lái)應(yīng)該是連通的。然而可能因?yàn)橐恍┕收?#xff0c;使得有些節(jié)點(diǎn)之間不連通了，整個(gè)網(wǎng)絡(luò)就分成了幾塊區(qū)域。數(shù)據(jù)就散布在了這些不連通的區(qū)域中。這就叫分區(qū)。

當(dāng)你一個(gè)數(shù)據(jù)項(xiàng)只在一個(gè)節(jié)點(diǎn)中保存，那么分區(qū)出現(xiàn)后，和這個(gè)節(jié)點(diǎn)不連通的部分就訪問(wèn)不到這個(gè)數(shù)據(jù)了。這時(shí)分區(qū)就是無(wú)法容忍的。

提高分區(qū)容忍性的辦法就是一個(gè)數(shù)據(jù)項(xiàng)復(fù)制到多個(gè)節(jié)點(diǎn)上，那么出現(xiàn)分區(qū)之后，這一數(shù)據(jù)項(xiàng)就可能分布到各個(gè)區(qū)里。容忍性就提高了。

然而，要把數(shù)據(jù)復(fù)制到多個(gè)節(jié)點(diǎn)，就會(huì)帶來(lái)一致性的問(wèn)題，多個(gè)節(jié)點(diǎn)上面的數(shù)據(jù)可能是不一致的。要保證一致，每次寫操作就都要等待全部節(jié)點(diǎn)寫成功，而這等待又會(huì)帶來(lái)可用性的問(wèn)題。

總的來(lái)說(shuō)就是，數(shù)據(jù)存在的節(jié)點(diǎn)越多，分區(qū)容忍性越高，但要復(fù)制更新的數(shù)據(jù)就越多，一致性就越難保證。為了保證一致性，更新所有節(jié)點(diǎn)數(shù)據(jù)所需要的時(shí)間就越長(zhǎng)，可用性就會(huì)降低。

對(duì)于分布式系統(tǒng)，理論上不可能舍棄P，因此可選方案經(jīng)常是CP或者AP架構(gòu)，當(dāng)然舍棄并不是什么也不做，當(dāng)發(fā)生分區(qū)時(shí)，可以做些事情，等到分區(qū)恢復(fù)后重新達(dá)到CA的狀態(tài)。

???? 2.2 一致性分類

一致性按照副本復(fù)制的策略又可以分為四種類型：

嚴(yán)格一致性：任何寫入操作立即馬上同步給所有節(jié)點(diǎn)。而在分布式系統(tǒng)中，數(shù)據(jù)的同步都需要時(shí)間，因此可想而知，這種模型是無(wú)法做到的。

線性一致性：任何一次讀都能讀到某個(gè)數(shù)據(jù)的最近一次寫的數(shù)據(jù)。系統(tǒng)中的所有進(jìn)程，看到的操作順序，都和全局時(shí)鐘下的順序一致。

順序一致性：不管系統(tǒng)怎么運(yùn)行，得到的結(jié)果就好像把所有節(jié)點(diǎn)的所有操作按照某個(gè)sequential order排序后運(yùn)行，但是在這個(gè)sequential order順序中，來(lái)自同一個(gè)節(jié)點(diǎn)的操作仍然保持著它們?cè)诠?jié)點(diǎn)中被指定的順序。

最終一致性（弱一致性）
不保證在任意時(shí)刻任意節(jié)點(diǎn)上的同一份數(shù)據(jù)都是相同的，但是隨著時(shí)間的遷移，不同節(jié)點(diǎn)上的同一份數(shù)據(jù)總是在向趨同的方向變化。簡(jiǎn)單說(shuō)，就是在一段時(shí)間后，節(jié)點(diǎn)間的數(shù)據(jù)會(huì)最終達(dá)到一致狀態(tài)。

???? 2.3 共識(shí)

共識(shí)（consensus）是分布式計(jì)算中最重要也是最基本的問(wèn)題，它想要做的事情是：讓所有節(jié)點(diǎn)就某事達(dá)成一致。共識(shí)問(wèn)題中所有的節(jié)點(diǎn)要最終達(dá)成共識(shí)，由于最終目標(biāo)是所有節(jié)點(diǎn)都要達(dá)成一致，所以根本不存在一致性強(qiáng)弱之分。

例如，Paxos是共識(shí)（Consensus）算法而不是強(qiáng)一致性（Consistency）協(xié)議。共識(shí)算法沒有一致性級(jí)別的區(qū)分。

????2.4 兩階段提交

兩階段提交（two-phase commit）?是一種跨多節(jié)點(diǎn)實(shí)現(xiàn)原子提交的算法，即確保所有節(jié)點(diǎn)提交或所有節(jié)點(diǎn)中止。

ETCD中數(shù)據(jù)寫同步也使用了兩階段提交，在leader收到寫數(shù)據(jù)后變發(fā)起階段1的寫通知，如果超過(guò)半數(shù)的節(jié)點(diǎn)寫了log，則發(fā)起第二階段的正式寫數(shù)據(jù)，并通知各個(gè)節(jié)點(diǎn)，如果半數(shù)寫成功則提交數(shù)據(jù)，否則雖然不回滾數(shù)據(jù)，但后續(xù)可以覆蓋之。

二階段協(xié)議的關(guān)鍵，它通過(guò)兩個(gè)階段來(lái)把不可靠事務(wù)提交失敗的幾率降低到了最小，第一階段一般占據(jù)了整個(gè)事務(wù)的大部分時(shí)間，而真正提交事務(wù)的第二階段幾乎是瞬間完成的，因此第二階段出錯(cuò)的機(jī)率大大降低，所以這正是二階段的巧妙之處。

現(xiàn)實(shí)中我們很少使用二階段提交協(xié)議來(lái)保證事務(wù)性，為什么呢？

在現(xiàn)實(shí)場(chǎng)景中，最常用的是基于BASE理論的最終一致性

提交協(xié)議需要鎖定資源，在性能上會(huì)有一定損失，這在高并發(fā)的場(chǎng)景中是不適合的。

提交協(xié)議引入了事務(wù)管理器（TM），導(dǎo)致系統(tǒng)實(shí)現(xiàn)比較復(fù)雜，復(fù)雜的事情一般很少有人愿意做。

分布式事務(wù)的最高境界是沒有分布式事務(wù)！

???? 03. ETCD的RAFT算法

概括如下，詳細(xì)的可以搜各類文章。

選擇leader，每個(gè)節(jié)點(diǎn)都可能時(shí) leader、follower、candidate（候選人）三種角色，集群節(jié)點(diǎn)采用心跳檢查各個(gè)節(jié)點(diǎn)的在線，如果發(fā)現(xiàn)leader跪了，則follower可以把自己提升為candidate，并廣播所有節(jié)點(diǎn)，開始選舉，超過(guò)半數(shù)同意，就可以選作leader。

當(dāng)然為了防止錯(cuò)誤數(shù)據(jù)的節(jié)點(diǎn)被推選為leader，在選舉中，必須帶上自己保存的最新數(shù)據(jù)序列，以供其他節(jié)點(diǎn)比對(duì)。其他節(jié)點(diǎn)只有在檢查發(fā)現(xiàn)你的數(shù)據(jù)正確或者更新的情況下才可以選舉你為leader。

ooop，這里不存在拉票和作弊。

當(dāng)然候選人也沒有特別要求，如果條件都一樣，則按照時(shí)間順序的先來(lái)后到排隊(duì)。

選出leader后，則每次寫數(shù)據(jù)都是先寫到leader，然后leader廣播給所有節(jié)點(diǎn)，按照兩階段提交的方式寫到整個(gè)集群。

???? 04.通訊協(xié)議

ETCD采用ProtoBuf編碼，GRPC協(xié)議的方式讀寫數(shù)據(jù)，當(dāng)然其也提供了更上層的http方式進(jìn)行讀寫。
.net core 下有g(shù)ithub下熱心網(wǎng)友的封裝類庫(kù)，并沒找到官方維護(hù)的sdk。

???? 05. 小結(jié)

理論的學(xué)習(xí)還是比較枯燥的，幸虧有你們的陪伴，分享何嘗不是一種快樂(lè)！

例行小結(jié)，理性看待！

結(jié)的是啥啊，結(jié)的是我想你點(diǎn)贊而不可得的寂寞。????????????

????都看到這了，還在乎點(diǎn)個(gè)贊嗎？

????都點(diǎn)贊了，還在乎一個(gè)收藏嗎？

????都收藏了，還在乎一個(gè)評(píng)論嗎？

總結(jié)

以上是生活随笔為你收集整理的理论修炼之ETCD，高一致性Key-Value服务提供者中的佼佼者的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。