etcd是CoreOS公司開發和運維的。CoreOS在2018年初被紅帽收購。
html
etcd如今被普遍用於K8S和OpenShift上，它是一個Key-value數據庫。用於OpenShft集羣的服務註冊。數據庫
etcd的優點在於它的性能，最新版本etc3.4在這方便有了大幅的提高。緩存
etcd3.1的性能測試數據連接以下：服務器
https://coreos.com/blog/performance-of-etcd.html微信
資源利用率網絡
大多數etcd部署使用虛擬機。測試基於Linux OS1的Google Cloud Platform Compute Engine虛擬機上運行。每一個羣集使用三個VM，足以容忍單個節點發生故障。每一個VM有16個專用vCPU，30GB內存和300GB SSD，持續寫入速度爲150 MB / s。此配置足以模擬來自1,000個客戶端的流量，這對於etcd的用例和如下資源測量的所選目標是最小的。全部測試都進行了屢次試驗;運行之間的誤差相對較小，並無影響任何通常結論。設置（使用etcd）以下圖所示：併發
每一個資源利用率測試都會建立一百萬個惟一的256字節密鑰，其值爲1024字節。
app
磁盤帶寬運維
寫操做必須持久存儲到磁盤。 下圖顯示了擴展客戶端併發性如何影響磁盤寫入。etcd3.1的線性最好。性能
網絡
每一個鍵值存儲都有本身的客戶端協議; etcd客戶端使用gRPC和HTTP / 2協議緩衝區v3，Zookeeper客戶端使用Jute而不是自定義流TCP協議，Consul使用JSON。
在大多數狀況下，etcd具備最低的網絡使用率，除了Consul客戶端接收的數據略少。
CPU
下圖顯示了在擴展客戶端時使用top -b -d 1測量的服務器CPU利用率。 etcd CPU利用率按預期平均和最大負載進行擴展;隨着更多鏈接的增長，CPU負載依次增長。
內存
當鍵值存儲設計爲僅管理元數據大小的數據時，大多數數據能夠緩存在內存中。維護內存數據庫能夠加快速度，但代價是過多的內存佔用可能會致使頻繁的垃圾回收和磁盤交換，從而下降總體性能。當Zookeeper和Consul在內存中加載全部鍵值數據時，etcd只保留一個小的駐留內存索引，直接經過boltdb中的內存映射文件支持其大部分數據。僅在boltDB中保存數據會因請求分頁而致使磁盤訪問，但整體而言，etcd更好地尊重操做系統設施。
一般etcd使用的內存量不到Zookeeper或Consul的一半。
吞吐量擴張
隨着愈來愈多的客戶端同時寫入羣集，理想狀況下，在提高以前，提取率應該穩定上升。可是，下圖顯示在寫出一百萬個密鑰時縮放客戶端數量時不是這種狀況。相反，Zookeeper（最大速率爲43,458 req / sec）波動很大;這並不奇怪，由於它必須明確配置爲容許大量鏈接。 Consul的吞吐量（最大速率16,486 req / sec）乾淨地擴展，但在併發壓力降低至低速率。 etcd的吞吐量（最大速率34,747 req / sec）整體穩定，隨着併發性而緩慢上升。最後，儘管Consul和Zookeeper使用了更多的CPU，但最大吞吐量仍然落後於etcd。
延遲分佈
總結：和ZP和Consul相比，etcd3.1的性能較高，etcd3.1的線性提高能力最高。
下面分享Goole兩位專家在Kubcon2019的分享。
本文分享自微信公衆號 - 大魏分享（david-share）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。