背景
coreOS中使用了etcd作爲集羣配置服務，擁有衆多出色的特點，etcd是一個key，value的數據服務器，單實例可達每秒 1000 次寫操作，以及方便的REST接口。 zookeeper則是在Hadoop中大放光彩的分佈式協調服務，提供了分佈式鎖，數據同步，等服務。
從功能上看，二者都可以很好的完成集羣中分佈式中遇到的同步，配置問題，但是不可否認，這2種服務在設計的時候的目的不同，也讓這2中服務有着不小的差異。
etcd
目的： 一個高可用的 Key/Value 存儲系統，主要用於分享配置和服務發現
接口： REST接口（HTTP+JSON）方便集羣中每一個主機訪問
功能： 提供了key，value存儲服務，集羣隊列同步服務，觀察一個key的數值變化，以及查詢歷史key值信息等
分佈式協議： Raft一致性協議。提供強一致性保證
部署形態： 採用小集羣（etcd server節點組成一個集羣）+大集羣（其它節點來直接使用服務）的形式，集羣可以達到上千節點
實現語言： go 擁有幾乎不輸於C的效率，特別是go語言本身就是面向多線程，進程通信的語言。在小規模集羣中性能非常突出
zookeeper
目的： 高有效和可靠的協同工作系統
接口： 基於TCP的自協議，需要安裝相應客戶端程序
功能： 提供了key，value存儲服務，集羣中簡歷臨時節點，觀察key值變化等
分佈式協議： 集運Paxos一致性協議，改進的Zab協議。提供強一致性保證
部署形態： 採用小集羣（zookeeper server節點組成一個集羣）+大集羣（其它節點來直接使用服務）的形式，集羣可以達到上千節點
實現語言： java，實現代碼量要多於go，在小規模集羣中性能一般，但是在大規模情況下，使用對多線程的優化後，也和go相差不大
總結：
可以看到因爲設計思路的不同，在原生接口和提供服務方式方面，etcd更適合作爲集羣配置服務器，用來存儲集羣中的大量數據。方便的REST接口也可以讓集羣中的任意一個節點在使用key value服務時獲取方便。zookeeper則更加的適合於提供分佈式協調服務，他在實現分佈式鎖模型方面較etcd要簡單的多。所以在實際使用中應該根據自身使用情況來選擇相應的服務。
轉載於：http://www.tuicool.com/articles/VNjQny
