zetcd是一款架在ZooKeeper與etcd之間的代理程序，它可以將ZooKeeper客戶端的請求消息轉換成etcd要求的格式，并轉發給etcd，然后將響應消息轉換后返回給客戶端。本文介紹了zetcd的使用方法、工作原理以及性能評測。以下是譯文。

　　分布式系統需要依賴分布式一致性來協調工作。通常情況下，提供分布式一致性擔保信息的系統會接收到按順序投遞過來的消息，這樣就不會產生腦裂沖突（split-brain conflicts，譯者注：本來一個大腦的兩個半球是互相配合的，但是現在分裂變成了兩個獨立的大腦，并且都認為對方已死。此時，雙方都會去嘗試接管集群資源，這樣就可能會造成沖突，產生嚴重的后果）。這類系統的用途是顯而易見的。像chubby、ZooKeeper、etcd、consul這些項目，盡管它們的原理和協議各不相同，但它們都側重于為分布式一致性提供類似的基本鍵值原語。為了讓etcd成為分布式系統中最具吸引力的項目，etcd團隊開發了一款新的代理服務器程序：zetcd，使用這款軟件，etcd集群無需修改即可處理ZooKeeper客戶端的請求。

　　ZooKeeper是這方面第一個流行起來的開源軟件，它是很多分布式系統的首選后端軟件。這些系統理論上也可以搭配etcd一起運行，但是由于歷史原因，實際上根本實現不了。etcd集群不支持ZooKeeper，因為etcd的數據模型和客戶端協議與ZooKeeper應用程序不兼容。ZooKeeper應用程序也不是原生的支持etcd；如果系統已經在穩定運行了，那么沒有必要去為了適應新的后端軟件而讓系統更加復雜。幸運的是，etcd的第三版API相當的牛逼，它可以通過一個普通的代理來模擬ZooKeeper客戶端的數據模型，這就是zetcd，一個由etcd團隊開發的新的開源項目。今天，zetcd發布了第一個測試版，v0.0.1版，這為在生產系統中管理和部署zetcd打下了基礎。

　　zetcd代理位于etcd集群的前端，它提供了一個模擬ZooKeeper客戶端的端口，讓原版的ZooKeeper應用程序可以運行在etcd上。其基本原理是，zetcd將ZooKeeper客戶端的請求轉換為適合于etcd數據模型和API要求的消息，將發送給etcd，然后將etcd的響應消息轉換后返回給客戶端。該代理的性能可以與ZooKeeper相媲美，利用etcd的特性和工具可以簡化ZooKeeper集群管理。下文將展示zetcd的使用方法和工作原理，并分享一些性能評測數據。

　　zetcd入門

　　讓zetcd運行起來需要三樣東西：一個Go編譯器、一個能夠獲取源代碼的互聯網連接，以及一個可以運行etcd的系統。下面的示例展示了如何用源代碼編譯生成zetcd，并對它運行ZooKeeper命令。當我們需要部署正式環境的時候，我們并不建議從開發分支來獲取源代碼并編譯etcd和zetcd，但是如果只是試用一下的話，這是最簡單的方法。

　　首先，獲取源代碼并編譯etcd和zetcd的二進制文件：

　　接下來，運行etcd，并將zetcd連接到etcd的客戶端接入點：

　　試用zetcd，啟動查看并創建一個key：

　　這個例子展示了在一個獨立的etcd實例上部署了一個zetcd代理層：

　　一個簡單的zetcd服務器拓撲

　　那么這個zetcd代理層是做什么的呢？

　　ZooKeeper接入etcd3

　　在底層，zetcd將ZooKeeper的數據模型轉換為適合的etcd API的數據。對于key的查找，zetcd將ZooKeeper的分級目錄轉換為etcd的普通二進制keyspace。對于元數據的管理，zetcd利用事務內存安全地和原子地將ZooKeeper znode信息更新到etcd后端。

　　ZooKeeper是按目錄列出所有的key（getChildren），而etcd是按區間（Range）列出所有的key。下圖說明了zetcd是如何在etcd中對key進行編碼以便可以快速地列出目錄中的key。所有zetcd的key都有一個包括目錄深度的前綴（例如，“/”和“/abc/”分別具有0和1的深度）。要列出一個目錄，zetcd會給出前綴范圍，這個前綴以目錄的深度和路徑來匹配相應的key（例如，前綴范圍［“/zk/key/002/abc/”，“/zk/key/002/abc0”］用于列出/abc/）。這里的目錄深度是為了限制目錄本身被當作key。如果zetcd將路徑當作是沒有深度的前綴，那么目錄下的所有key，而不是只有其直接子節點，會由etcd返回并被代理拋棄。