etcd 是什么
etcd 这个名字由两部分组成： etc 和 d ，即 UNIX/Linux操作系统的“／etc” 目录和分布式（ distributed ）首字母的“d ” 。我们都知道，／etc目录一般用于存 储 UNIX/Linux 操作系统的配置信息 因此etc和d合起来就是一个分布式的／etc 目录。etcd 的寓意是为大规模分布式系统存储配置信息。
etcd 的官方定义如下：
A distributed, reliable key-value store for the most critical data of a distributed system
etcd 是一个 Go 语言编写的分布式、高可用 的用于分布式系统重要数据存储的 一致性键值存储 系统，常用于提供可靠的分布式键值（ key-value ）存储、配置共享和服务发现等 功能。
etcd 具有容错能力，对于n个节点的集群，可以在n-1/2 个节点宕机（其他节点正常） 的情况下仍继续工作。
特点
- 简单
支持 RESTful 风格的 的 API，V3版本增加了对 gRPC 的支持，同时也提供 rest gateway 进行转化 。Go 语言编写，跨平台，部署和维护简单；使用 Raft 算法保证强一致性， 更好理解 - 安全 支持 TLS 客户端安全认证
- 高性能 单实例支持每秒一千次以上的写操作（v2 ），极限写性能可达 10K+Qps(v3 ）
- 可靠 使用 Raft 算法充分保证了分布式系统数据的强一致性
etcd结构简介
etcd ( server ）大体上可以分为网络层（ http(s) server ）、 Raft 模块、复制状 态机和存储模块 。
网络层：提供网络数据读写功能，监听服务端口，完成集群节点之间数 据通信，收发客户端数据。
Raft 模块： Raft 强一致性算法的具体实现。
存储模块：涉及 KV 存储、 WAL 文件、 Snapshot 管理等，用于处理etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反 馈、 事件处理与执行等.是etcd对用户提供的大多数API功能的具体实现
复制状态机：这是一个抽象的模块，状态机的数据维护在内存中，定期持久化到磁盘，每次写请求都会持久化到 WAL 文件，并根据写请求的 内容修改状态机数据
一个用户的请求发送过来，会经由 HTTP ( S) Server转发给存储模 块进行具体的事务处理，如果涉及节点状态的更新，则交给 Raft 模块进行仲裁 和日志的记录，然后再同步给别的 etcd 节点，只有当半数以上的节点确认了该 节点状态的修改之后，才会进行数据的持久化
etcd集群的各个节点之间需要通过网络来传递数据，具体表现为如下几个方面。
1 ) Leader 向 Follower 发送心跳包， Follower 向 Leader回复消息。
2) Leader 向Follower发送日志追加信息。
3) Leader 向Follower发送 Snapshot 数据。
4 ) Candidate 节点发起选举，向其他节点发起投票请求。
5) Follower 将收到的写操作转发给 Leader。
etcd 集群节点之间的网络拓扑是一个任意 2 个节点之间均有长链接 相互连接的网状结构
etcd 数据通道
etcd 根据不同的用途，定义了各种不同的消息类型 。 这些消息大小不同 。 etcd对这些消 息采取了分类处理的方式。它抽象出了 2 种类型的消息传输通道，Stream 类型通道和 Pipeline 类型通道 。这 2 种通道都使用 HTTP 传输数据。
Stream 像是在点与点之间维护的双向传输带，消息打包后，放 到传输带上，传给对方，对方将回复消息打包好并放到反向传输带上；
Pipeline 就如同拥 有 N 辆汽车，将大消息打包放到汽车上，开到 对端，然后 再开回来，最多可以同时发送 N 个消息
Stream 通道
Stream 类型通道用 于处理数据量较少的消息，例如， 心跳、日志追加消 息等。点到点之间只维护l个HTTP 长链接，交替向链接中写人数据和读取 数据。etcd节点启动后主动与其他 每一 个节点建立Stream链接。通过 Channel 与 Raft 模块传递消息。每一个Stream 类型通道关联2个goroutine，一个用于建立 HTTP 链接，并读取数据解码成消 息，再通过 Channel 传给Raft 模块，另外一个通过 Go 语言的 Channel 从Raft 模块中收取消息，然后写人 Stream 类型通道。
Pipeline 通道
Pipeline 类型通道用于处理数据量大的消息，例如， Snapshot。这种类型的 消息需要与心跳等消息分开处理 ，否则会阻塞心跳包的传输，进而影 响集群的稳定性，点到点之间不维护 HTTP 长链接，它只通过短链接传输数据，用完即关闭。ipeline 类型通道还可用来并行发出多个消息，它维护着一组 go routine，每一个goroutine 都可向对端发出 POST 请求（携带数据），收到回复 后，链接关闭。
etcd通信架构
网络层与 Raft 模块之间的交互
网络层与 Raft 模块之间通过Go语言 的 Channel来完成数据通信
etcd Raft 模块中的 RaftNode 拥有一个消息盒子， RaftNode 将各种类型的消息都放入消息盒子中，由专 门的 goroutine将消息盒 子里的消息写人管道（ Go 语言的 Channel ），管道的另外一端就链接在网络层 的不同类型的传输通道上，有专门的 go routine处理（ select ）消息 。
网络层收到消息，通过管道传给 RaftNode 。RaftNode 中有专 门的 go routine处理消息。
etcd server 与客户端的交互
etcd server 在启动之初 ，会 监听服务端口，待服务端口收到客户端的请 求之后，就会解析出消息体，然后通过管道传给 Raft 模块，当 Raft 模块按照 Raft 协议完成操作时，会回复该请求 （ 或者请求超时关闭了） 。 客户端与所有的etcd server 都是通过客户端的端口使用 HTTP 进行通信的 。 etcd server 的客户端 端口主要用来提供对外服务。
etcd server 之间的交互
etcd server 之间通过 peer 端口使用 HTTP 进行通信 。 etcd server 的 peer 端 口主要用来协调 Raft 的相关消息，包括各种提议的协商 。
应用场景
etcd 的定位是通用的一致性 key/value 存储，但也有 服务发现和共享配置 的功能 。 因此，典型的 etcd 应用场景包括但不限于分布式 数据库、服务注册与发现 、 分布式锁 、 分布式消息、队列 、 分布式系统选主等 。 etcd 的定位是通用的一致性 key/value 存储，同时也面向服务注册与发现的应用 场景 。
和ZK对比
Zoo Keeper 的主要优势是其具有成熟、健壮以及丰 富 的特性，然而，它也 有自己的缺点，具体如下：
- 复杂 。 ZooKeeper 的部署维护比较复杂；Paxos 强一致性算法也复杂难懂；使用也比较复杂，需要安装客户端，官方 只提供了 Java 和 C 两种语言的接口
- Java 编写，Java 本身就偏向重型应用依赖较多，对资源的占用也比较高
- 发展缓慢 ,Apache 基金会庞大的结构和松散的管理导致项目发 展缓慢
与 ZooKeeper 相比，ETCD更简单，安 装、部署和使用更加容易，并且 etcd 的某些功能是 ZooKeeper 所没有的,比如：
- etcd 更加稳定可靠，它的唯一目标就是把分布式一致性 KV 存储做到极 致，所以它更注重稳定性和扩展性
- 服务发现，etcd 使用的是节点租约（ Lease ），并且支持Group （多 key ）；而 ZooKeeper 使用的是临时节点，临时节点存在很多问题
- etcd 支持稳定的 watch ，而不是 ZooKeeper 一样简单的单次触发式watch，很多调度系统需要得到完整节点历史记录，etcd 可以存储数十万个历史变更
- etcd 支持 MVCC （多版本并发控制），因为有协同系统需要无锁操作
- etcd 支持更大的数据规模 ， 支持存储百万到千万级别的 key
- etcd 的性能更好 。 在 一 个由 3 台 8 核节点组成的云 服务器上， etcd d 版本可以做到每秒数万次的写操作和数十万次的读操作