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源创计划”，欢迎正在阅读的你也加入，一块儿分享。