在分布式系統要滿足CAP原則，一個提供資料服務的存儲系統無法同時滿足：資料一緻性、資料可用性、分區耐受性。
C資料一緻性：所有應用程式都能通路到相同的資料。 A資料可用性：任何時候，任何應用程式都可以讀寫通路。 P分區耐受性：系統可以跨網絡分區線性伸縮。（通俗來說就是資料的規模可擴充） 在大型網站中通常都是犧牲C，選擇AP。為了可能減小資料不一緻帶來的影響，都會采取各種手段保證資料最終一緻。
資料強一緻：各個副本的資料在實體存儲中總是一緻的。
資料使用者一緻：資料在實體存儲的各個副本可能是不一緻的，但是通過糾錯和校驗機制，會确定一個一緻的且正确的資料傳回給使用者。
資料最終一緻：實體存儲的資料可能不一緻，終端使用者通路也可能不一緻，但是一段時間内資料會達成一緻。
使一組伺服器在一個值上達成一緻，是以活躍的特征在于最終每個伺服器都可以決定一個值。
通過值的一緻能夠實作對同一個資料的請求會讓同一個伺服器來處理。
Paxos和Raft都是通過選取master來實作多節點下值的一緻性，進而借助一緻性hash算法來配置設定請求。
一緻性Hash算法 一緻性Hash算法可以根據不同的屬性參數（通常是IP和端口号），生成一串不相同的Hash值，并将Hash值轉換成0-2^32-1的整數， 不同範圍的值由不同伺服器進行處理。（B-C之間的由B處理）。
Raft算法是在Paxos算法的基礎上的進行優化。 Raft在Paxos的基礎上主要做了兩個方向的優化： 1.将複雜的分布式共識問題拆分成上司選舉、日志複制和安全性三個問題 2.壓縮狀态空間：相對于Paxos施加了更合理的限制，減少了系統狀态過多而産生的不确定因素。
上司選舉(具體以zookeeper舉例) 其基本的特性有：
zookeeper在配置叢集時節點數不可小于3
節點隻有獲得半數以上的投票才能當選Leader
zookeeper在啟動時會通過廣播機制來把投票結果告訴其他的節點
zookeeper在啟動時首先會給自己投票，然後與其他已啟動的節點進行通信，通過比較id進而判斷是否能擷取其他節點的投票
zookeeper在選舉過程中的角色：上司者、跟随者、觀察者、競選者
日志複制 在共識算法中，所有伺服器節點都會包含一個有限狀态自動機，名為複制狀态機（replicated state machine）。每個節點都維護着一個複制日志（replicated logs）的隊列，複制狀态機會按序輸入并執行該隊列中的請求，執行狀态轉換并輸出結果。可見，如果能保證各個節點中日志的一緻性，那麼所有節點狀态機的狀态轉換和輸出也就都一緻。
可見，日志由一個個按序排列的entry組成。每個entry内包含有請求的資料，還有該entry産生時的上司任期值。每個節點上的日志隊列用一個數組log[]表示。
上司節點選舉出來後，叢集就可以開始處理用戶端請求了。當用戶端發來請求時，上司節點首先将其加入自己的日志隊列，再并行地發送AppendEntries RPC消息給所有跟随節點。最終實作節點資料的一緻性。
安全性 Raft安全保障機制有5種：
選舉安全性：節點要3個以上，避免“腦裂”的方式
上司者隻追加：用戶端發出的請求都是插入上司者日志隊列的尾部，沒有修改或删除的操作。
日志比對：每條AppendEntries都會包含最新entry之前那個entry的下标與任期值，如果跟随節點在對應下标找不到對應任期的日志，就會拒絕接受并告知上司節點。（避免追随者故障，導緻資料不一緻）
上司者完全性:如果有一條日志在某個任期被送出了，那麼它一定會出現在所有任期更大的上司者日志裡。（master會優先擷取日志的更新）
狀态機安全性:如果一個節點已經向其複制狀态機應用了一條日志中的請求，那麼對于其他節點的同一下标的日志，不能應用不同的請求。(避免master當機時，重新選舉，導緻部分節點資料不一緻)
Consul vs Eureka vs Zookeeper
注： CAP: 資料一緻性、資料可用性、分區耐受性 AP: 犧牲強一緻性，部分節點當機，不會影響正常工作的節點。 CP: 犧牲資料可用性,為了保證資料的一緻性，當一台機器出現故障時，所有節點的資料都不能使用。
最後總結
RabbitMQ實戰指南
手寫RocketMQ筆記
手寫“Kafka筆記”
關于分布式，限流+緩存+緩存，這三大技術（包含：ZooKeeper+Nginx+MongoDB+memcached+Redis+ActiveMQ+Kafka+RabbitMQ）等等。這些相關的面試也好，還有手寫以及學習的筆記PDF，都是啃透分布式技術必不可少的寶藏。以上的每一個專題每一個小分類都有相關的介紹，并且小編也已經将其整理成PDF啦