zookeeper基于paxos的化簡版zab，etcd基于raft算法、consul也是基于raft算法。etcd和consul作為後起之秀，并沒有因為已經有了zookeeper而放棄自己，而是采用更為直接的raft算法。
Raft算法的頭号目标就是容易了解（UnderStandable），這從論文的标題就可以看出來。當然，Raft增強了可了解性，在性能、可靠性、可用性方面是不輸于Paxos的。
Raft more understandable than Paxos and also provides a better foundation for building practical systems
為了達到易于了解的目标，raft做了很多努力，其中最主要是兩件事情：
- 問題分解
- 狀态簡化
問題分解是将"複制集中節點一緻性"這個複雜的問題劃分為數個可以被獨立解釋、了解、解決的子問題。在raft，子問題包括，leader election， log replication，safety，membership changes。而狀态簡化更好了解，就是對算法做出一些限制，減少需要考慮的狀态數，使得算法更加清晰，更少的不确定性（比如，保證新選舉出來的leader會包含所有commited log entry）
Raft implements consensus by first electing a distinguished leader, then giving the leader complete responsibility for managing the replicated log. The leader accepts log entries from clients, replicates them on other servers, and tells servers when it is safe to apply log entries to their state machines. A leader can fail or become disconnected from the other servers, in which case a new leader is elected.
上面的引文對raft協定的工作原理進行了高度的概括：raft會先選舉出leader，leader完全負責replicated log的管理。leader負責接受所有用戶端更新請求，然後複制到follower節點，并在“安全”的時候執行這些請求。如果leader故障，followes會重新選舉出新的leader。
這就涉及到raft最新的兩個子問題：leader election和log replication
leader election
log replication
這裡就平時經常用到的服務發現的産品進行下特性的對比，首先看下結論:
- 服務的健康檢查
Euraka 使用時需要顯式配置健康檢查支援；Zookeeper,Etcd 則在失去了和服務程序的連接配接情況下任務不健康，而 Consul 相對更為詳細點，比如記憶體是否已使用了90%，檔案系統的空間是不是快不足了。
- 多資料中心支援
Consul 通過 WAN 的 Gossip 協定，完成跨資料中心的同步；而且其他的産品則需要額外的開發工作來實作；
- KV 存儲服務
除了 Eureka ,其他幾款都能夠對外支援 k-v 的存儲服務，是以後面會講到這幾款産品追求高一緻性的重要原因。而提供存儲服務，也能夠較好的轉化為動态配置服務哦。
- 産品設計中 CAP 理論的取舍
Eureka 典型的 AP,作為分布式場景下的服務發現的産品較為合适，服務發現場景的可用性優先級較高，一緻性并不是特别緻命。其次 CA 類型的場景 Consul,也能提供較高的可用性，并能 k-v store 服務保證一緻性。而Zookeeper,Etcd則是CP類型 犧牲可用性，在服務發現場景并沒太大優勢；
- 多語言能力與對外提供服務的接入協定
Zookeeper的跨語言支援較弱，其他幾款支援 http11 提供接入的可能。Euraka 一般通過 sidecar的方式提供多語言用戶端的接入支援。Etcd 還提供了Grpc的支援。Consul除了标準的Rest服務api,還提供了DNS的支援。
- Watch的支援（用戶端觀察到服務提供者變化）
Zookeeper 支援伺服器端推送變化，Eureka 2.0(正在開發中)也計劃支援。Eureka 1,Consul,Etcd則都通過長輪詢的方式來實作變化的感覺；
- 自身叢集的監控
除了 Zookeeper ,其他幾款都預設支援 metrics，運維者可以搜集并報警這些度量資訊達到監控目的；
- 安全
Consul,Zookeeper 支援ACL，另外 Consul,Etcd 支援安全通道https.
- Spring Cloud的內建
目前都有相對應的 boot starter，提供了內建能力。
總的來看，目前Consul 自身功能，和 spring cloud 對其內建的支援都相對較為完善，而且運維的複雜度較為簡單（沒有詳細列出讨論），Eureka 設計上比較符合場景，但還需持續的完善。
Etcd 和 Zookeeper 提供的能力非常相似，在軟體生态中所處的位置也幾乎是一樣的，可以互相替代的。
都是通用的一緻性元資訊存儲，
都提供watch機制用于變更通知和分發，
也都被分布式系統用來作為共享資訊存儲，
二者除了實作細節，語言，一緻性協定上的差別，最大的差別在周邊生态圈。
Zookeeper 是apache下的，用java寫的，提供rpc接口，最早從hadoop項目中孵化出來，在分布式系統中得到廣泛使用(hadoop, solr, kafka, mesos 等)。
Etcd 是coreos公司旗下的開源産品，比較新，以其簡單好用的rest接口以及活躍的社群俘獲了一批使用者，在新的一些叢集中得到使用(比如kubernetes)。
雖然v3為了性能也改成二進制rpc接口了，但其易用性上比 Zookeeper 還是好一些。
而 Consul 的目标則更為具體一些，Etcd 和 Zookeeper 提供的是分布式一緻性存儲能力，具體的業務場景需要使用者自己實作，比如服務發現，比如配置變更。
而Consul 則以服務發現和配置變更為主要目标，同時附帶了kv存儲。
在軟體生态中，越抽象的元件适用範圍越廣，但同時對具體業務場景需求的滿足上肯定有不足之處。
------------------- 消息中間件Rabbitmq ----------------------------------
消息中間件Rabbitmq（01）
消息中間件Rabbitmq（02）
消息中間件Rabbitmq（03）
消息中間件Rabbitmq（04）
消息中間件Rabbitmq（05）
消息中間件Rabbitmq（06）
消息中間件Rabbitmq（07）
------------------- ---------- 雲計算 -------------------------------------
雲計算（1）——docker的前世今生
雲計算（2）—— 體系結構
雲計算（3）—— 容器應用
雲計算（4）—— LAMP
雲計算（5）—— Dockerfile雲計算（6）—— harbor
關注公衆号 soft張三豐