zookeeper：
zookeeper是基於paxos的簡化版zab，我覺得確實很難理解?，以前看了好多遍《從paxos到zookeper》才感覺似懂非懂了，然而過了幾個月發現又一臉蒙蔽了，在這里在整理一下（僅表示我自己的理解）
ZAB協議中存在着三種狀態，每個節點都屬於以下三種中的一種：
1. Looking ：系統剛啟動時或者Leader崩潰后正處於選舉狀態
2. Following ：Follower節點所處的狀態，Follower與Leader處於數據同步階段；
3. Leading ：Leader所處狀態，當前集群中有一個Leader為主進程；
在開始時，所有的節點都是looking狀態並且每個節點都希望自己能成為leader節點，所有每個節點都會向集群中發送一個提案內容是選取自己作為leader節點，提案編號是ZXID
(ZAB協議中使用ZXID作為事務編號，ZXID為64位數字，低32位為一個遞增的計數器，每一個客戶端的一個事務請求時Leader產生新的事務后該計數器都會加1，高32位為Leader周期epoch編號，當新選舉出一個Leader節點時Leader會取出本地日志中最大事務Proposal的ZXID解析出對應的epoch把該值加1作為新的epoch，將低32位從0開始生成新的ZXID；ZAB使用epoch來區分不同的Leader周期),如果得到的提案的zxid比自己的大則說明發出這個題案的節點數據更新，則進行同意的投票，否則繼續投自己，先得到多數的同意的節點當選為leader
現在leader就可以進行管理了，zookeeper也是兩段提交的實現，客戶端提交事務請求時Leader節點為每一個請求生成一個事務Proposal，將其發送給集群中所有的Follower節點，收到過半Follower的反饋后開始對事務進行提交，ZAB協議使用了原子廣播協議
Leader節點為每一個Follower節點分配一個隊列按事務ZXID順序放入到隊列中，且根據隊列的規則FIFO來進行事務的發送。Follower節點收到事務Proposal后會將該事務以事務日志方式寫入到本地磁盤中，成功后反饋Ack消息給Leader節點，Leader在接收到過半Follower節點的Ack反饋后就會進行事務的提交，以此同時向所有的Follower節點廣播Commit消息，Follower節點收到Commit后開始對事務進行提交；?
如果leader宕機，則集群進入恢復階段，根據上面的方式選舉出ZXID最大的節點當選leader，並進入恢復階段，所有的follewer都會將自己的ZXID發送個leader，由leader根據follower的ZXID與自己的相差的階段數采取不同的措施實現整個集群的數據同步（若相差較小，則使用Leader發送從Follolwer.lastZXID到Leader.lastZXID議案的DIFF指令給Follower同步數據，若相差較大則直接發送leader的快照給follower）?
etcd
etcd作為最近很火的一個高可用性?鍵值對服務發現系統被Kubernetes等系統廣泛使用
他相比與zookeeper來說更加簡單，在面對較小集群時可能會效率更高些?，而且他的編寫語言Go本身就是一種多線程編程語言，確實有很大吸引人的地方（雖然我不懂Go語言，但是在學習docker時也是一睹其風采了）
在Raft中，任何時候一個服務器可以扮演下面角色之一：
Leader: 處理所有客戶端交互，日志復制等，一般一次只有一個Leader.
Follower: 類似選民，完全被動
Candidate候選人: 類似Proposer律師，可以被選為一個新的領導人。
1.leader選舉階段
和zookeeper一樣 剛剛開始所有節點都會希望選取自己作為leader，但是不一樣的是etcd卻簡單的多，他維持一個計時器，當這個計時器過時還沒有leader發來心跳信息或者候選人發來的投票信息，就當自動成為選民向其他節點發送選取自己為leader的請求，若收到多數派的投票就當選 ，如果很不湊巧，有兩個節點同時發起並且獲得的投票數相同，那么過三百毫秒后兩個節點再次進行爭奪，這次相同投票數的概率就十分低，實在不行再來一次
2.消息同步階段
假設Leader領導人已經選出，在leader接受到?消息請求，這時leader增加一個日志的要求，比如日志是"GO"：
2. Leader要求Followe遵從他的指令，都將這個新的日志內容追加到他們各自日志中：
3.大多數follower服務器將日志寫入磁盤文件后，確認追加成功，發出Commited Ok:
4. 在下一個心跳heartbeat中，Leader會通知所有Follwer更新commited 項目。
對於每個新的日志記錄，重復上述過程。
3.網絡分區問題
如果在這一過程中，發生了網絡分區或者網絡通信故障，使得Leader不能訪問大多數Follwers了，那么Leader只能正常更新它能訪問的那些Follower服務器，而大多數的服務器Follower因為沒有了Leader，他們重新選舉一個候選者作為Leader，然后這個Leader作為代表於外界打交道，如果外界要求其添加新的日志，這個新的Leader就按上述步驟通知大多數Followers，如果這時網絡故障修復了，那么原先的Leader就變成Follower，在失聯階段這個老Leader的任何更新都不能算commit，都回滾，接受新的Leader的新的更新。?
說了這么多?------------------動畫！！！！！！
看完瞬間開朗啊，不知道是哪位大神做的~?