理論修煉之ETCD，高一致性Key-Value服務提供者中的佼佼者

這是我參與8月更文挑戰的第11天，活動詳情查看：8月更文挑戰

• 📢歡迎點贊 ：👍 收藏 ⭐留言 📝 若有錯誤敬請指正，賜人玫瑰，手留餘香！
• 📢本文做者：由webmote 原創，首發於 【掘金】
• 📢做者格言： 生活在於折騰，當你不折騰生活時，生活就開始折騰你，讓咱們一塊兒加油！💪💪💪

🎏 序言

以往在架構選項的時候，大概瞭解其作什麼的，有什麼優劣就夠了，由於大部分互聯網企業比較輕文檔重快速迭代，每每並不會糾結過多的選型方案。

只要方案合適，幹就好了。

遙憶剛工做那會，流行瀑布式開發模式，方案和需求的重要性放在最頂級的位置，每每方案須要寫幾十上百頁，關鍵的技術選項還須要編寫關鍵技術選項，通過好幾輪的評審纔可能最終走向需求、概要、詳細和總結。固然評審裏領導各類角度的問題，每每讓人不知所措。

通過這些年的「放鬆」，編寫技術文檔的水平也愈來愈差了，甚至於不少中間件也只是瞭解個皮毛，深層次的原理都不肯意仔細看看，只關注怎麼能利用這些中間件乾點什麼事上。

這不，開始碰壁了，由於缺乏理論層面的指導，不少過去認爲理所固然的事情，在須要仔細闡述並爭取領導贊成上，就遇到了本身解釋不清楚的各類問題。

怎麼能快速說服領導上，遇到了很大的阻力。也讓我看清楚了本身的問題之所在：缺少理論依據。固然做爲大領導是否須要深刻的介入技術問題在這裏不談，由於人生惟一最大的事，莫過於修煉自身。

所以這篇文章送給我本身，修煉重在點滴間。

🎏 01.ETCD是幹啥的?

etcd是一種高一致的分佈式鍵值存儲，它提供了一種可靠的方式來存儲須要由分佈式系統或機器集羣訪問的數據。它在網絡內優雅地處理領導者選舉，而且能夠容忍機器故障，就算是領導者故障也不會影響高一致性。

做爲高一致性解決方案三劍客之一的ETCD（其餘還有ZooKeeper、Consul），其最大的特色就是保持高一致性。

🎏 02.一致性的概念

一致性是分佈式系統提出的一個概念，由於對於單機系統，幾乎不存在一致性的問題。

而爲了解決單機存儲的單點故障，就從架構上升級爲了主備系統，備份系統使用各類方案對主系統上的數據進行備份，以便保持和主系統的數據同步。

而一旦開始複製數據，那麼就產生了一致性的問題。

一致性的定義：對某個指定的客戶端，讀操做能保證返回最新的寫操做的結果。

🎏 2.1 CAP定理

做爲分佈式系統中的最基礎的定理，CAP是由加州大學的布魯爾最早提出的一個猜測，最後被證實，而使之成爲分佈式計算領域公認的定理，所以也被稱做布魯爾定理。

CAP定理是說在一個分佈式系統（互相連接並共享數據節點的集合）中，當涉及讀寫操做時，只能保證一致性（Consistency）、可用性（Avaliability）、分區容錯性（Partition Tolerance)三者中的兩個，另一個必須被犧牲。

可用性指非故障節點在合理的時間內返回合理的響應（不包含錯誤和超時）。 分區容錯：指當出現網絡分區後，系統可以繼續履行職責。 換句話說，系統部分節點出現故障後，鏈接正常節點還可使用系統提供的服務。

不懂就搜，分區容錯這個概念很差理解，所以這裏引用知乎的回答。

一個分佈式系統裏面，節點組成的網絡原本應該是連通的。然而可能由於一些故障，使得有些節點之間不連通了，整個網絡就分紅了幾塊區域。數據就散佈在了這些不連通的區域中。這就叫分區。

當你一個數據項只在一個節點中保存，那麼分區出現後，和這個節點不連通的部分就訪問不到這個數據了。這時分區就是沒法容忍的。

提升分區容忍性的辦法就是一個數據項複製到多個節點上，那麼出現分區以後，這一數據項就可能分佈到各個區裏。容忍性就提升了。

然而，要把數據複製到多個節點，就會帶來一致性的問題，多個節點上面的數據多是不一致的。要保證一致，每次寫操做就都要等待所有節點寫成功，而這等待又會帶來可用性的問題。

總的來講就是，數據存在的節點越多，分區容忍性越高，但要複製更新的數據就越多，一致性就越難保證。爲了保證一致性，更新全部節點數據所須要的時間就越長，可用性就會下降。

對於分佈式系統，理論上不可能捨棄P，所以可選方案常常時CP或者AP架構，固然捨棄並非什麼也不作，當發生分區時，能夠作些事情，等到分區恢復後從新達到CA的狀態。

🎏 2.2 一致性分類

一致性按照副本複製的策略又能夠分爲四種類型：

1. 嚴格一致性：任何寫入操做當即立刻同步給全部節點。而在分佈式系統中，數據的同步都須要時間，所以可想而知，這種模型是沒法作到的。
2. 線性一致性：任何一次讀都能讀到某個數據的最近一次寫的數據。系統中的全部進程，看到的操做順序，都和全局時鐘下的順序一致。
3. 順序一致性：無論系統怎麼運行，獲得的結果就好像把全部節點的全部操做按照某個sequential order排序後運行，可是在這個sequential order順序中，來自同一個節點的操做仍然保持着它們在節點中被指定的順序。
4. 最終一致性（弱一致性）

不保證在任意時刻任意節點上的同一份數據都是相同的，可是隨着時間的遷移，不一樣節點上的同一份數據老是在向趨同的方向變化。簡單說，就是在一段時間後，節點間的數據會最終達到一致狀態。

🎏 2.3 共識

共識（consensus）是分佈式計算中最重要也是最基本的問題，它想要作的事情是：讓全部節點就某事達成一致。共識問題中全部的節點要最終達成共識，因爲最終目標是全部節點都要達成一致，因此根本不存在一致性強弱之分。

例如，Paxos是共識（Consensus）算法而不是強一致性（Consistency）協議。共識算法沒有一致性級別的區分。

🎏2.4 兩階段提交

兩階段提交（two-phase commit） 是一種跨多節點實現原子提交的算法，即確保全部節點提交或全部節點停止。

ETCD中數據寫同步也使用了兩階段提交，在leader收到寫數據後變發起階段1的寫通知，若是超過半數的節點寫了log，則發起第二階段的正式寫數據，並通知各個節點，若是半數寫成功則提交數據，不然雖然不回滾數據，但後續能夠覆蓋之。

二階段協議的關鍵，它經過兩個階段來把不可靠事務提交失敗的概率下降到了最小，第一階段通常佔據了整個事務的大部分時間，而真正提交事務的第二階段幾乎是瞬間完成的，所以第二階段出錯的機率大大下降，因此這正是二階段的巧妙之處。

現實中咱們不多使用二階段提交協議來保證事務性，爲何呢？

1. 在現實場景中，最經常使用的是基於BASE理論的最終一致性
2. 提交協議須要鎖定資源，在性能上會有必定損失，這在高併發的場景中是不適合的。
3. 提交協議引入了事務管理器（TM），致使系統實現比較複雜，複雜的事情通常不多有人願意作。
4. 分佈式事務的最高境界是沒有分佈式事務！

🎏 03. ETCD的RAFT算法

歸納以下，詳細的能夠搜各種文章。

選擇leader，每一個節點均可能時 leader、follower、candidate（候選人）三種角色，集羣節點採用心跳檢查各個節點的在線，若是發現leader跪了，則follower能夠把本身提高爲candidate，並廣播全部節點，開始選舉，超過半數贊成，就能夠選做leader。

固然爲了防止錯誤數據的節點被推選爲leader，在選舉中，必須帶上本身保存的最新數據序列，以供其餘節點比對。其餘節點只有在檢查發現你的數據正確或者更新的狀況下才能夠選舉你爲leader。

ooop，這裏不存在拉票和做弊。

固然候選人也沒有特別要求，若是條件都同樣，則按照時間順序的先來後到排隊。

選出leader後，則每次寫數據都是先寫到leader，而後leader廣播給全部節點，按照兩階段提交的方式寫到整個集羣。

🎏 04.通信協議

ETCD採用ProtoBuf編碼，GRPC協議的方式讀寫數據，固然其也提供了更上層的http方式進行讀寫。 .net core 下有github下熱心網友的封裝類庫，並沒找到官方維護的sdk。

🎏 05. 小結

理論的學習仍是比較枯燥的，幸好有大家的陪伴，分享未嘗不是一種快樂！

例行小結，理性看待！

結的是啥啊，結的是我想你點贊而不可得的寂寞。😳😳😳

👓都看到這了，還在意點個贊嗎？

👓都點讚了，還在意一個收藏嗎？

👓都收藏了，還在意一個評論嗎？