介紹目前etcd的狀況和其今后的發展
本次分享主要介紹目前etcd的狀況和其今后的發展。
@Container大會，專為一線開發者和運維工程師設計的頂級容器技術會議。
etcd是CoreOS開發的一個分布式一致性鍵值存儲系統。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做了很多優化。Q：etcd未來的版本會像ZooKeeper一樣支持臨時節點嗎？
支持目錄和key是類似的，目前可以做到100k左右的小key。
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這件事情完整的做好已經不容易了。Q：請問Kubernetes中使用etcd主要用來做什么？
我們希望上層的系統可以在etcd上搭建，而不是讓etcd本身服務最終用戶。另外在某些程度上而言，Consul并不著重保證自身的穩定性和可靠性。HashiCorp自己的調度系統nomad也并沒有采用Consul。這些差別導致了很多設計、實現上的不同。
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，專注于分布式系統和容器集群管理研究開發。目前是etcd的maintainer，rkt和Kubernetes的主要貢獻者。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。
來自：http://dockone.io/article/801