理论修炼之ETCD，高一致性Key-Value服务提供者中的佼佼者
????歡迎點贊 ：???? 收藏 ?留言 ???? 如有錯誤敬請指正，賜人玫瑰，手留余香！
????本文作者：由webmote 原創，首發于 【掘金】
????作者格言：生活在于折騰，當你不折騰生活時，生活就開始折騰你，讓我們一起加油！????????????
???? 序言
以往在架構選項的時候，大概了解其做什么的，有什么優劣就夠了，因為大部分互聯網企業比較輕文檔重快速迭代，往往并不會糾結過多的選型方案。
只要方案合適，干就行了。
遙憶剛工作那會，流行瀑布式開發模式，方案和需求的重要性放在最頂級的位置，往往方案需要寫幾十上百頁，關鍵的技術選項還需要編寫關鍵技術選項，經過好幾輪的評審才可能最終走向需求、概要、詳細和總結。當然評審里領導各種角度的問題，往往讓人不知所措。
經過這些年的“放松”，編寫技術文檔的水平也越來越差了，甚至于很多中間件也只是了解個皮毛，深層次的原理都不愿意仔細看看，只關注怎么能利用這些中間件干點什么事上。
這不，開始碰壁了，因為缺少理論層面的指導，很多過去認為理所當然的事情，在需要仔細闡述并爭取領導同意上，就遇到了自己解釋不清楚的各種問題。
怎么能快速說服領導上，遇到了很大的阻力。也讓我看清楚了自己的問題之所在：缺乏理論依據。當然作為大領導是否需要深入的介入技術問題在這里不談，因為人生唯一最大的事，莫過于修煉自身。
因此這篇文章送給我自己，修煉重在點滴間。
???? 01.ETCD是干啥的?
etcd是一種高一致的分布式鍵值存儲，它提供了一種可靠的方式來存儲需要由分布式系統或機器集群訪問的數據。它在網絡內優雅地處理領導者選舉，并且可以容忍機器故障，就算是領導者故障也不會影響高一致性。
作為高一致性解決方案三劍客之一的ETCD（其他還有ZooKeeper、Consul），其最大的特點就是保持高一致性。
???? 02.一致性的概念
一致性是分布式系統提出的一個概念，因為對于單機系統，幾乎不存在一致性的問題。
而為了解決單機存儲的單點故障，就從架構上升級為了主備系統，備份系統使用各種方案對主系統上的數據進行備份，以便保持和主系統的數據同步。
而一旦開始復制數據，那么就產生了一致性的問題。
一致性的定義：對某個指定的客戶端，讀操作能保證返回最新的寫操作的結果。
???? 2.1 CAP定理
作為分布式系統中的最基礎的定理，CAP是由加州大學的布魯爾最先提出的一個猜想，最后被證明，而使之成為分布式計算領域公認的定理，因此也被稱作布魯爾定理。
CAP定理是說在一個分布式系統（互相鏈接并共享數據節點的集合）中，當涉及讀寫操作時，只能保證一致性（Consistency）、可用性（Avaliability）、分區容錯性（Partition Tolerance)三者中的兩個，另外一個必須被犧牲。
可用性指非故障節點在合理的時間內返回合理的響應（不包含錯誤和超時）。
分區容錯：指當出現網絡分區后，系統能夠繼續履行職責。換句話說，系統部分節點出現故障后，連接正常節點還可以使用系統提供的服務。
不懂就搜，分區容錯這個概念不好理解，因此這里引用知乎的回答。
一個分布式系統里面，節點組成的網絡本來應該是連通的。然而可能因為一些故障，使得有些節點之間不連通了，整個網絡就分成了幾塊區域。數據就散布在了這些不連通的區域中。這就叫分區。
當你一個數據項只在一個節點中保存，那么分區出現后，和這個節點不連通的部分就訪問不到這個數據了。這時分區就是無法容忍的。
提高分區容忍性的辦法就是一個數據項復制到多個節點上，那么出現分區之后，這一數據項就可能分布到各個區里。容忍性就提高了。
然而，要把數據復制到多個節點，就會帶來一致性的問題，多個節點上面的數據可能是不一致的。要保證一致，每次寫操作就都要等待全部節點寫成功，而這等待又會帶來可用性的問題。
總的來說就是，數據存在的節點越多，分區容忍性越高，但要復制更新的數據就越多，一致性就越難保證。為了保證一致性，更新所有節點數據所需要的時間就越長，可用性就會降低。
對于分布式系統，理論上不可能舍棄P，因此可選方案經常是CP或者AP架構，當然舍棄并不是什么也不做，當發生分區時，可以做些事情，等到分區恢復后重新達到CA的狀態。
???? 2.2 一致性分類
一致性按照副本復制的策略又可以分為四種類型：
嚴格一致性：任何寫入操作立即馬上同步給所有節點。而在分布式系統中，數據的同步都需要時間，因此可想而知，這種模型是無法做到的。
線性一致性：任何一次讀都能讀到某個數據的最近一次寫的數據。系統中的所有進程，看到的操作順序，都和全局時鐘下的順序一致。
順序一致性：不管系統怎么運行，得到的結果就好像把所有節點的所有操作按照某個sequential order排序后運行，但是在這個sequential order順序中，來自同一個節點的操作仍然保持著它們在節點中被指定的順序。
最終一致性（弱一致性）
不保證在任意時刻任意節點上的同一份數據都是相同的，但是隨著時間的遷移，不同節點上的同一份數據總是在向趨同的方向變化。簡單說，就是在一段時間后，節點間的數據會最終達到一致狀態。
???? 2.3 共識
共識（consensus）是分布式計算中最重要也是最基本的問題，它想要做的事情是：讓所有節點就某事達成一致。共識問題中所有的節點要最終達成共識，由于最終目標是所有節點都要達成一致，所以根本不存在一致性強弱之分。
例如，Paxos是共識（Consensus）算法而不是強一致性（Consistency）協議。共識算法沒有一致性級別的區分。
????2.4 兩階段提交
兩階段提交（two-phase commit）?是一種跨多節點實現原子提交的算法，即確保所有節點提交或所有節點中止。
ETCD中數據寫同步也使用了兩階段提交，在leader收到寫數據后變發起階段1的寫通知，如果超過半數的節點寫了log，則發起第二階段的正式寫數據，并通知各個節點，如果半數寫成功則提交數據，否則雖然不回滾數據，但后續可以覆蓋之。
二階段協議的關鍵，它通過兩個階段來把不可靠事務提交失敗的幾率降低到了最小，第一階段一般占據了整個事務的大部分時間，而真正提交事務的第二階段幾乎是瞬間完成的，因此第二階段出錯的機率大大降低，所以這正是二階段的巧妙之處。
現實中我們很少使用二階段提交協議來保證事務性，為什么呢？
在現實場景中，最常用的是基于BASE理論的最終一致性
提交協議需要鎖定資源，在性能上會有一定損失，這在高并發的場景中是不適合的。
提交協議引入了事務管理器（TM），導致系統實現比較復雜，復雜的事情一般很少有人愿意做。
分布式事務的最高境界是沒有分布式事務！
???? 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. 小結
理論的學習還是比較枯燥的，幸虧有你們的陪伴，分享何嘗不是一種快樂！
例行小結，理性看待！
結的是啥啊，結的是我想你點贊而不可得的寂寞。????????????
????都看到這了，還在乎點個贊嗎？
????都點贊了，還在乎一個收藏嗎？
????都收藏了，還在乎一個評論嗎？
總結
以上是生活随笔為你收集整理的理论修炼之ETCD，高一致性Key-Value服务提供者中的佼佼者的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Dapr 客户端 搭配 WebApiCl
- 下一篇： Blazor 路由及导航开发指南