etcd优化

　　etcd 集群划分成几个核心的部分：例如蓝色的 Raft 层、红色的 Storage 层，Storage 层内部又分为 treeIndex 层和 boltdb 底层持久化存储 key/value 层。它们的每一层都有可能造成 etcd 的性能损失。

　　Raft 层，Raft 需要通过网络同步数据，网络 IO 节点之间的 RTT 和 / 带宽会影响 etcd 的性能。除此之外，WAL 也受到磁盘 IO 写入速度影响。

　　Storage 层，磁盘 IO fdatasync 延迟会影响 etcd 性能，索引层锁的 block 也会影响 etcd 的性能。除此之外，boltdb Tx 的锁以及 boltdb 本身的性能也将大大影响 etcd 的性能。

　　etcd server 端的性能优化：

　　　　server 端在硬件上需要足够的 CPU 和 Memory 来保障 etcd 的运行。其次，作为一个非常依赖于磁盘 IO 的数据库程序，etcd 需要 IO 延迟和吞吐量非常好的 ssd 硬盘，etcd 是一个分布式的 key/value 存储系统，网络条件对它也很重要。最后在部署上，需要尽量将它独立的部署，以防止宿主机的其他程序会对 etcd 的性能造成干扰。

　　　　etcd 的内存索引层优化　　lease 规模使用的优化　　后端 boltdb 的使用优化　　优化调用 boltdb tx 读写锁使用，提升读性能

　　　　阿里贡献的一个性能优化：基于 segregated hashmap 的 etcd 内部存储 freelist 分配回收新算法。

　　　　　　当新的数据存储需要一个连续页面为 k 的配置时，旧的算法需要从 freelist 头开始扫描，最后返回页面起始 ID ，以此可以看到普通的 etcd 线性扫描内部 freelist 的算法，在数据量较大或者是内部碎片严重的情况下，性能就会急速的下降。

　　　　　　新的 freelist 分配回收算法。该算法将连续的页面大小作为 hashmap 的 key，value 是起始 ID 的配置集合。当需要新的页面存储时，只需要 O(1) 的时间复杂度来查询这个 hashmap 值，快速得到页面的起始 ID。

　　etcd 性能优化 -client 端

　　　　针对于 Put 操作避免使用大 value，精简精简再精简，例如 K8s 下的 crd 使用；

　　　　其次，etcd 本身适用及存储一些不频繁变动的 key/value 元数据信息。因此客户端在使用上需要避免创建频繁变化的 key/value。这一点例如 K8s下对于新的 node 节点的心跳数据上传就遵循了这一实践；

　　　　最后，我们需要避免创建大量的 lease，尽量选择复用。例如在 K8s下，event 数据管理：相同 TTL 失效时间的 event 同样会选择类似的 lease 进行复用，而不是创建新的 lease。