Etcd介绍

协调服务满足目标

• 可用性角度:高可用
• 数据一致性角度:提供获取最新数据的机制
• 容器角度:低容量、仅存储关键元数据配置。
• 功能:增删改查,监听数据变化的机制。
• 运维复杂度:可维护性。

ectd v1 和 v2

Zookeeper的缺点:

• 不支持通过API安全地变更成员,需要人工修改一个个节点的配置,并重启进程(操作不当,会发生脑裂等严重故障)。
• Zookeeper 用Java便携的，部署繁琐，占用较多的内存资源,rpc序列化用的jute，无法使用curl。

etcd的算法:

• 数据一致性:使用raft算法。将一致性问题分解成Leader选举、日志同步、安全性。
• 高可用:只要集群一半以上节点存活就可以提供服务，具备良好的可用性。
• 功能:使用目录的内存模式(内存树,包含节点路径、值、孩子节点信息，无需考虑数据分片,只保存最新数据)，使用简单、易用的REST API。
• 可维护性:raft算法提供了成员变更算法,在线、安全变更,使用go开发，部署简单。

etcd v2 技术点:

• 数据模型/Data Model: 基于目录的层次模型
• 复制/Replication:Leader->Follower/Raft Log Replication
• 共识/Consensus:Raft
• Http JSON API:GET、SET、DELETE、WATCH、Atomic Compare-And-Swap、Atmoic Compare-And-Delete
• TTL
• AUTH
• 高可用/High Availability:集群一半以上节点存活即可提供服务
• 成员管理及故障检测/membership and failure detection:raft
• 读一致性/Read Consistency:quorum read、stale
• 存储引擎/Storage Engine:Memory Tree
• 数据区分/Data Partition:无,低容量存储
• 事物/Transaction:单key
• 状态一致性检测:无

etcd v2 的问题:

• 功能局限问题:不支持范围和分页查询、不支持多key事物。
• Watch机制可靠性问题:不保存历史数据,只保存最新的,数据量大,引起雪崩。
• 性能瓶颈问题:集群大导致CPU高负载、OOM、丢包等问题。
• 内存开销问题:配置多,占用内存多。

etcd v3改进:

• 内存开销、Watch事件可靠性、功能局限:引入B-tree、boltdb实现一个MVCC数据库,数据模型从层次型目录结构改成变成的KEY-VALUE,
  提供稳定可靠的事件通知,实现了事物,支持多KEY原子更新,使用boltdb来实现持久化存储,降低内存占用、避免ectd v2定期生成快照时
  的昂贵的资源开销。
• 使用gRPC,使用protobuf定义消息,http 2.0多路服用机制,减少watch场景下的连接数。
• 使用Lease优化TTL机制,相同TTL的key关联一个Lease,Lease过期的时候自动删除相关联的所有key,不需要为每个key单独续期。
• 支持范围、分页查询,避免打包等昂贵的请求。

etcd vs Consul vs Zookeeper vs eureka

参考文献

服务发现比较:Consul vs Zookeeper vs Etcd vs Eureka
k8s学习笔记（5）--- kubernetes核心组件之etcd详解
A Closer Look at Etcd: The Brain of a Kubernetes Cluster