這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】本次分享主要介紹目前etcd的狀況和其今後的發展。
@Container大會，專為一線開發人員和營運工程師設計的頂級容器技術會議。
etcd是CoreOS開發的一個分布式一致性KVStore for Redis系統。etcd主要被用於儲存叢集的關鍵資料和對叢集內部組建進行協調。etcd採用了raft分布式一致性協議來保證自身的資料一致性和可用性。一個etcd叢集一般由3到5台節點群組成。只要有多餘半數的節點可用，整個etcd系統對外看來也是可用狀態的。
etcd的API相對簡單。首先etcd支援基本的索引值操作，例如GET、PUT、DELETE。除此之外，etcd還支援CompareAndSwap這個原子性操作。CompareAndSwap首先對一個key進行值比較，如果比較結果一致才會進行下一步的賦值操作。像利用x86的CAS實現鎖一樣，利用CompareAndSwap可以實現分布式的鎖系統。
另外etcd還支援watch操作。使用者可以watch在一個key或者一個directory上。如果key的值發生了改變，etcd會通知watch的client。不同於ZooKeeper的ont time trigger watch，etcd的watch在一般情況下可以保證不漏掉任何變更。etcd不僅僅儲存了全部的索引值，它還儲存了最近的索引值變更紀錄。所以一個比較落後的watch還是可以通過遍曆最近的變更紀錄來擷取到最近的所有更新。
最後etcd支援TTL key。每個key可以有一個TTL屬性來表示它的存活時間。如果存活時間是5秒，那麼etcd會在5秒之後自動刪除這個key並且通知watch在這個key上的使用者。另外一個帶有TTL的key也可以不斷的被重新整理來延長存活時間。使用者可以利用這個功能來時間leader election。
etcd 2是目前最新的etcd版本。它支援穩定的v2 API以及非常穩固的raft分布式一致性。我們內部運行了一些etcd測試叢集。這些測試叢集不斷的被注入錯誤。比如強制關閉一台機器、暫停一台機器、讓一台機器運行緩慢或者阻斷網路通訊等等。我們在前期發現了一些bug，在修複了bug之後etcd的測試叢集已經穩定的工作了幾個月。我們對etcd的穩定性非常有信心。
目前etcd項目的主要開發精力集中在推出全新一代的etcd 3。etcd 3主要解決如下幾個問題：多版本索引值（MVCC）、迷你事務（mini transcation）、更穩定的watch、大資料規模、大使用者watch、效能最佳化。
多版本索引值可以減輕使用者設計分布式系統的難度。通過對多版本控制，使用者可以獲得一個一致的索引值空間的snapshot。使用者可以在無鎖的狀態下來查詢snapshot上的索引值來做出下一步決定。
mini transaction支援原子性比較多個索引值並且操作多個索引值。之前的CompareAndSwap實際上一個針對單個key的mini transaction。一個簡單的例子是 Tx(compare: A=1 && B=2, success: C = 3, D = 3, fail: C = 0, D = 0)。當etcd收到這條transcation請求，etcd會原子性的判斷A和B當前的值和期待的值。如果判斷成功，C和D的值會被設定為3。
etcd 2儲存了一個僅儲存了1000個曆史更改，如果watch過慢就無法得到之前的變更。etcd 3為了支援多紀錄，採用了記錄為主索引的儲存結構。etcd3可以儲存上十萬個紀錄，進行快速查詢並且支援根據使用者的要求進行compaction。
etcd 2和其它類似開源一致性系統一樣最多隻能數十萬層級的key。主要原因是一致性系統都採用了基於log的複製。log不能無限增長，所以在某一時刻系統需要做一個完整的snapshot並且將snapshot儲存到磁碟。在儲存snapshot之後才能將之前的log丟棄。每次儲存完整的snapshot是非常沒有效率的，但是對於一致性系統來說設計增量snapshot以及傳輸同步大量資料都是非常繁瑣的。etcd 3通過對raft和儲存系統的重構，能夠很好的支援增量snapshot和傳輸相對較大的snapshot。目前etcd 3可以儲存百萬到千萬層級的key。
另外一個問題是支援大規模watch。我們主要工作是減小每個watch帶來的資源消耗。首先我們利用了HTTP/2的multiple stream per tcp connection，這樣同一個client的不同watch可以share同一個tcp connection。另一方面我們對於同一個使用者的不同watch只使用一個go routine來serve，這樣再一次減輕了server的資源消耗。
我們在效能方面也做了很多相關的最佳化。etcd 3目前的效能遠強於etcd 2，我們相信etcd 3的效能在不進行特殊最佳化的情況下就可以足夠應付絕大部分的使用。在一個由3台8核節點群組成的的雲端服務器上，etcd 3可以做到每秒數萬次的寫操作和十萬次讀操作。
最後我們爭取在明年年初發布etcd 3。
Q&A
Q：請問下etcd目前的並發串連是多少，支援多少目錄？
A：這個要看你自身的伺服器情況。目前每個watch都會佔用一個tcp資源和一個go routine資源，大概要消耗30-40kb。etcd 3做了很多最佳化。
支援目錄和key是類似的，目前可以做到100k左右的小key。
Q：etcd未來的版本會像ZooKeeper一樣支援臨時節點嗎？
A：目前etcd支援ttl key，etcd 3會支援lease，lease可以lease到多key，lease到期會把所有key自動刪除。相當於group一些ttl keys。ZooKeeper的臨時節點從我看來是一個broken的功能。
Q：etcd在其他OS像CentOS上效能會有折扣嗎？
A：etcd對CoreOS本身沒有任何依賴，所以不會。
Q：etcd 2和ZooKeeper相比優勢在哪些方面？
A：和ZooKeeper的設計理念和方向不太一樣。目前etcd著重於go stack和cloud infra領域。很多上層系統例如Kubernetes、CloudFoundry、Mesos等都對穩定性、擴充性有更高的要求。由於理念的不同，導致了很多設計的不同。比如etcd會支援穩定的watch而不是簡單的one time trigger watch，因為很多調度系統是需要得到完整記錄的。etcd支援mvcc，因為可能有協同系統需要無鎖操作等等。在效能上今後etcd可能也要做更多工作，因為container infra有更多的大規模情境。
Q：etcd能放到Docker裡麼，有沒有這方面案例？
A：https://github.com/coreos/etcd ... de.md。
Q：etcd與Consul比，有什麼特色和差異？
A：Consul是個full stack的工具。etcd只是一個簡單的一致性kv。我們認為能把一致性kv這件事情完整的做好已經不容易了。
我們希望上層的系統可以在etcd上搭建，而不是讓etcd本身服務終端使用者。另外在某些程度上而言，Consul並不著重保證自身的穩定性和可靠性。HashiCorp自己的調度系統nomad也並沒有採用Consul。這些差別導致了很多設計、實現上的不同。
Q：請問Kubernetes中使用etcd主要用來做什嗎？
A：儲存重要的叢集資訊和做相關組建之間的協調。
Q：etcd在n台（n大於等於3）機器組成的叢集下，效能如何，效能會隨機器數下降嗎？
A：寫效能會的。etcd 3做了相關最佳化，分配了一些寫load，etcd 2下降一些。
Q：外Masters實效後，要多久才能選出新的Masters恢複寫？
A：可以根據服務環境自行設定。預設的timeout是1秒，2秒內可以選出。如果網路經常不穩定，或者伺服器忙，可以提高到5秒，10秒內選出。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上內容根據2015年11月6日晚群分享內容整理。分享
李響，就職於CoreOS，專註於分布式系統和Lark研究開發。目前是etcd的maintainer，rkt和Kubernetes的主要貢獻者。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。
