分佈式系統一般都需要一個仲裁系統，一般系統都自己提供這樣的仲裁以免出現腦裂。這樣的系統有很多，例如：chubby，zookeeper，etcd和consul等。儘管這些系統的術語和協議不同，但是都提供基於key-value方式的分佈式仲裁。最近etcd團隊開發了一種全新的代理zetcd，可以為etcd集群提供類zookeeper的服務請求，吸引了更多的注意力。
zookeeper是第一個開源實現的仲裁軟件，成為廣泛使用的分佈式系統後端。概念上來說應該可以更etcd兼容，但由於歷史原因，並非如此；etcd集群不能依靠zookeeper，其數據模型和客戶端協議跟zookeeper應用不兼容；反之亦然。幸運的是，etcd v3 API正準備通過一個標準代理zetcd實現對zookeeper數據模型的模擬，zetcd是一個由etcd團隊開發的全新開源項目，今天發佈了zetcd第一個beta版本,v0.0.1，目標是在生產系統中管理和部署zetcd系統。
zetcd代理在etcd集群和zookeeper客戶端之間提供服務，使得zookeeper應用原生調用etcd的功能。抽象一些，zetcd接受zookeeper的客戶請求，轉化成etcd的數據模型和API，將請求轉發到etcd，然後將返回信息以客戶端可理解方式轉發回去。zetcd的性能跟zookeeper不相上下，並且簡化了zookeeper集群與etcd之間的管理和操作複雜性。以下文章將揭示如何使用zetcd，zetcd工作原理以及性能基準。
zetcd入門
所有zetcd都需要運行go編譯器，它可以方便從互聯網上獲取源代碼並且可以運行etcd。以下例子展示如何獲取zetcd源碼，一直到如何在zetcd之上運行zookeeper命令。這些命令並非真正的產品手冊，他們只是一個如何使用的簡單示例。
首先，獲得etcd和zetcd源碼，並編譯成二進制代碼：
go get github.com/coreos/etcd/cmd/etcd
go get github.com/coreos/zetcd/cmd/zetcd
其次，運行etcd，將zetcd連接到etcd客戶服務端：
etcd uses localhost:2379 by default
etcd &
zetcd -zkaddr localhost:2181 -endpoints localhost:2379 &
用watching啟動zetcd，創建一個key：
go install github.com/coreos/zetcd/cmd/zkctl
zkctl watch / &
zkctl create /abc "foo"
那麼zetcd這層到底是做什麼的呢？
etcd3 中對 zookeeper的支持
如上圖中，zetcd將zookeeper數據模型翻譯成適合etcd API的。對於key查詢，zetcd將zookeeper層級式目錄轉換成etcd的flat binary keyspace。對於metadata管理，當寫入etcd後端時，zetcd利用交易內存將信息安全完整地更新為zookeeper znode信息。
zookeeper以目錄方式列出keys（getChildren），而etcd則通過interval(range)方式。下圖列出zetcd如何對etcd下的keys進行打包來有效支持目錄列表。所有在etcd中的zetcd keys都有一個包括全目錄名的前綴（例如: "/"和“/abc”分別代表深度為0 和1）。當有類目錄需求時，zetcd發出一個帶前綴的range請求（例如[“/zk/key/002/abc/”, “/zk/key/002/abc0”來列出滿足目錄深度和路徑的所有/abc/下的keys。深度限制只針對目錄本身；如果zetcd只使用路徑而不使用深度，那麼這個目錄下所有keys都將返回，反之只返回本目錄下的keys。
每個zookeeper key都包含有在ZNode中保存的修改，版本和權限等metadata。儘管etcd也有每個key的metadata，卻比ZNode中的要簡單很多，例如因為沒有目錄因此沒有子版本，因為etcd使用基於角色認證機制因此沒有ACLs，因為超出實時時鐘範圍因此沒有時間戳。這些額外metadata映像為一批keys，描述一個完整的ZNode。為了調整metadata，zetcd使用軟件交易內存更新keys，保證ZNodes不需要昂貴的加鎖機制就可以保持一致。
另外，zetcd可以動態地與zookeeper服務器做校驗。zetcd同時連接到etcd和外部zookeeper服務器。當客戶端發起請求，請求會被同時轉發到zetcd和zookeeper服務端。如果兩個服務器響應不同，zetcd會給此響應標識一個警告。
性能基準
從以上原理上看因為有數據轉換以及額外的網絡開銷，很容易想見這些操作效率不高。儘管相對於zookeeper或者etcd集群來說，zetcd有額外的花銷，但是它仍然有一個優勢在於某些etcd應用安裝完畢後仍然需要zookeeper來協調。例如，早期用戶報告稱zetcd重加密etcd TLS的流量比加密經典zookeeper配置要簡單。在這些場景中，說同一種zookeeper語言的可靠性相對於性能來說更重要一些。
使用zetcd命令行工具zkboom可以用來判斷性能基準，接口和報告跟etcd性能工具類似。其它zookeeper性能工具也能跟zetcd協同工作；zkboom提供方便性，可以做如下測試：
go get github.com/coreos/zetcd/cmd/zkboom
zkboom --conns=50 --total=10000 --endpoints=localhost:2181 create
zetcd為小負載提供足夠的性能保障。兩節點配置性能延遲證實zetcd對大量請求是可以接受的。具體配置是兩臺linux服務器通過一個千兆交換機互聯，其中一臺設備在RAID磁盤配置上運行代理和和服務端，另外一臺設備用於產生客戶請求。zkbook通過，創建一個空keystore，並從中讀取128Kbytes鍵值對來進行測量。用戶請求被限制在每秒2500個請求，逐漸增加併發客戶端數量。zookeeper 3.4.10和etcd結果如下比較所示：
下圖表明zetcd並行客戶端數量與平均key創建延遲之間關係。因為etcd在延遲上比zookeeper要有5-35ms的優勢，zetcd有足夠的空間吸納由於額外負載造成的延遲。zetcd代理比起zookeeper有20ms左右的劣勢，但是從處理2500請求的吞吐量數據來看，並不弱。一種對zetcd寫比較慢的解釋是，與讀不一樣，對每個zookeeper key寫時因為有額外的數據模型不同，所以需要寫多次。
未來
儘管zetcd承諾以上結果，性能數據是合理的，在可接受延遲情況下，可以支撐每秒上千個操作。以上模擬對Mesos，Kafka和Drill替代zookeeper提供了足夠好的解決方案，但是對於zetcd來說仍然後足夠的空間提高性能期望。同樣的，需要更多基於zookeeper應用採用zetcd做替代性測試。
zetcd從去年十月開始在開源社區出現，最近剛發佈第一個版本：zetcd v0.0.1。儘管是第一個beta發行版，但是已經為未來生產系統提供穩定管理和部署。如果跟etcd配合起來使用，運行zetcd的系統將會一套自驅動的“zookeeper”集群，它可以自動後臺升級，備份和TLS管理。