概念
etcd 是一个高可用的分布式键值key-value数据库，可用于服务发现。
etcd 采用raft 一致性算法，基于 Go语言实现。
etcd作为一个高可用键值存储系统，天生就是为集群化而设计的。
etcd部署方式
由于Raft算法在做决策时需要多数节点的投票，所以etcd一般部署集群推荐奇数个节点，推荐的数量为3、5或者7个节点构成一个集群。
官网地址
CAP原理
也叫CAP原则，指的是在一个分布式系统中存在三个特性：Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时满足三个特性中的两个，三者不可兼得。
CAP原理的提出主要是针对分布式场景，所以P是必须具备的。
分布式键值存储系统对比
| etcd | zookeeper | consul | NewSQL | |
|---|---|---|---|---|
| CAP | CP | CP | CP | CP |
| 开发语言 | go | java | go | C/C++ |
| 线性读 | Y | N | N | 有时候 |
| 多版本并发控制 | Y | N | N | 有时候 |
| 事务 | 数据内容比较、读或写 | 版本检查，写 | 数据内容比较、锁、读或写 | SQL式事务 |
| 用户权限 | RBAC | 访问控制列表 | 访问控制列表 | 每个数据库的权限和每个表的授权 |
| 数据更新通知 | 历史和当前健范围 | 当前键和目录 | 当前键（支持前缀） | 触发器（有时候） |
| http/json api | Y | N | Y | 很少 |
| 最大数据库大小 | 几GB | 几百MB到几GB | 几百MB以上 | 几TB |
| 最小线性读时延 | 网络RTT | 不支持线性读 | 网络RTT+fsync | 取决于系统和网络时钟 |
其实eureka专注于服务发现，严格来说不算是分布式键值存储系统
NewSQL 分布式关系型数据库，主流有google公司的Cloud Spanner，CockroachDB（与PostgreSQL兼容的开源分布式SQL数据库，由熟悉Google Cloud Spanner的前谷歌员工开发），ClustrixDB（现归MariaDB所有，这个横向扩展的集群关系HTAP(混合事务/分析处理)数据库采用无共享架构设计。ClustrixDB主要与MySQL和MariaDB兼容）
总的来说，每种系统都有其优势：
- etcd的优势在于配置信息共享和方便运维，etcd设计理念是设计成大规模分布式系统的通用底座，因此在云原生领域得到广泛使用；
- Zookeeper优势在于稳定性在大数据领域应用很广；
- Consul的优势在于服务发现。
实现原理
架构
- HTTP Server：接受客户端发出的 API 请求以及其它 etcd 节点的同步与心跳信息请求。
- Store：kv数据的存储引擎，v3支持不同的后端存储，当前采用boltdb。通过boltdb支持事务操作。用于处理 etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现。
- Raft：强一致性算法的具体实现，是 etcd 的核心算法。
- WAL（Write Ahead Log，预写式日志）：是 etcd 的数据存储方式，etcd 会在内存中储存所有数据的状态以及节点的索引，此外，etcd 还会通过 WAL 进行持久化存储。WAL 中，所有的数据提交前都会事先记录日志。
- Snapshot：为了防止数据过多而进行的状态快照
- Entry：表示存储的具体日志内容。
通常一个用户的请求发送过来，会经由 HTTP Server 转发给 Store 进行具体的事务处理，如果涉及到节点数据的修改，则交给 Raft 模块进行状态的变更、日志的记录，然后再同步给别的 etcd 节点以确认数据提交，最后进行数据的提交，再次同步。
数据读写过程
- 读取：由于集群所有节点数据都是强一致性的，读取可以随机读取，leader和follow 都可以读取
- 写入：如果请求发到follow会转发给leader，由leader写入，然后分发给follower，具体过程如下：
-
客户端向Etcd集群发送写入请求，请求中包含要写入的K-V数据。
-
Etcd集群的任意一个节点接收到请求后，将其转发给Leader节点。
-
Leader节点根据配置决定是否需要生成WAL Log预写式日志。如果需要，它会向所有的Follower节点发送预写式日志条目（WAL Log Entry），并等待超过半数的Follower节点返回接收日志条目成功的信息。
-
如果预写式日志生成成功，Leader节点会将K-V数据写入到内存中的PageCache中，并通知客户端写入成功。
-
如果配置为"沃尔夫法则"（W+L=N）且N大于一半的节点，在超过半数的Follower节点返回接收Entry日志条目成功的信息后，Etcd会将K-V数据写入到磁盘中的Blot DB中。
-
写入磁盘中的Blot DB后，Etcd会生成一个唯一的Snapshot快照，并保存在指定的存储路径中。
-
注意：
Etcd的写入流程是异步的，也就是说，写入请求的响应不是立即返回的。Etcd会使用后台线程或者异步操作来完成K-V数据写入磁盘和Snapshot快照的生成。这样可以提高系统的吞吐量和性能。
etcd基本特点
- 简单性：使用标准HTTP工具（如curl）读取和写入值，其实就是常说的对外API接口
- 观测性：可持续watch key的变化，做出相应的响应，
- 高可用：分布式集群，解决单点故障
- 完全复制：每个节点都是一份完整的的存档
- 安全：带有客户端验证的TLS
- 一致性：每次读取都会返回跨多主机的最新写入，这里的一致性主要指的是数据的强一致性。
选举过程
- 集群开始的时候，所有节点的角色都是Follower
- 当节点在指定的时间没有收到Leader 或者 Candidate的有效消息时会发起选举投票，指定时间是选举超时时间，是一个随机的值（防止多节点同时发起选举，Leader无法被选出 ），心跳时间比这个时间短。
- 投票过程：
- Follower 递增Term
- 自身状态变成Candidate
- 投票给自己
- 向集群其它节点发起投票请求（Request Vote）
- 当超过集群一半节点都同意，状态变成Leader，立即向集群所有其它节点发送心跳
- 当发现其它Leader 节点并且Term不小于自己的term ，状态变成Follow，否则丢弃消息。
- 投票过程：
数据通道
-
Stream类型通道： 主要用于传输数据量较小的信息，例如心跳、日志追加消息，节点之间维护长连接
-
Pipeline 类型通道： 主要用于处理数据量大的信息，比如snapshot，采用短连接，与心跳等消息区分处理，保证集群稳定
应用场景
etcd的定位是通用的一致性key/value的存储，典型的应用场景包括：
- 分布式数据库
- 服务注册与发现
- 负载均衡
- 分布式锁
- 分布式队列
- 消息发布与订阅
- 分布式通知与协调
- 集群监控与leader竞选
发展里程碑
etcd目前最新的是3.x版本，有3个重要里程碑版本，分别是：
- etcd 0.4
- etcd 2.0
- etcd 3.0
etcd 0.4是对外发布的第一个稳定版本，etcd2.0与etcd3.0版本差别比较，具体如下：
- v3版本采用gRPC+protobuf 取代 v2版本的Http+json的通讯方式，同时保留v2版本的方式，提高整体吞吐率，降低时延
- v3采用磁盘数据库代替v2 key-value内存数据库
- v3引入多版本的键空间(MVCC),支持访问历史版本key
- v3引入事务概念，etcd服务的多个请求合并成一个操作
- v3摒弃v2的key-value的层级和目录，采用扁平的二进制键空间
- v3更轻量级的基于租约(Lease)的key自动过期机制，取代基于TTL的key过期机制
- v3 watch机制重新设计，采用基于http2的server push，对事件进行多路复用优化
v2采用的是http长连接的事件驱动机制
etcd v3 版本依然保留etcd v2的协议和api，同时提供一套v3的API,也就是说，两个版本共享一套raft协议代码的，在于api不同，存储不同，数据相互隔离，采用v2版本API 只能用v2版本的API，v3版本只能用v3 版本的API
etcd专业名词
在开始 etcd 的安装使用之前，先了解下 etcd 的概念词汇表，以便于理解。
- Raft：etcd所采用的保证分布式系统强一致性的算法。
- Node：一个Raft状态机实例。
- Member： 一个etcd实例。它管理着一个Node，并且可以为客户端请求提供服务。
- Cluster：由多个Member构成可以协同工作的etcd集群。
- Peer：对同一个etcd集群中另外一个Member的称呼。
- Client： 向etcd集群发送HTTP请求的客户端。
- WAL：预写式日志，etcd用于持久化存储的日志格式。
- snapshot：etcd防止WAL文件过多而设置的快照，存储etcd数据状态。
- Proxy：etcd的一种模式，为etcd集群提供反向代理服务。
- Leader：Raft算法中通过竞选而产生的处理所有数据提交的节点。
- Follower：竞选失败的节点作为Raft中的从属节点，为算法提供强一致性保证。
- Candidate：当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始竞选。
- Term：某个节点成为Leader到下一次竞选时间，称为一个Term。
- Index：数据项编号。Raft中通过Term和Index来定位数据。
etcd端口信息
| 端口 | 作用 |
|---|---|
| 2380端口 | 伙伴通信，例如集群通信，交换选举等信息 |
| 2379端口 | 2379是http协议的RESTful接口，用于客户端连接 |
选举机制
安装部署
参考：etcd安装部署方式_docker run etcd-CSDN博客
访问安全
etcd 默认是没有开启访问控制的，访问安全包括用户的认证和授权，传输安全是指使用SSL/TLS来加密信道，本身证书也可以来做认证
1） 基于身份验证的访问控制
采用基于角色访问控制（RBAC）
etcdctl user add root #首开添加root账户，才能开始认证
etcdctl auth enable #开启认证 ，默认有root角色，拥有所有权限，授予root用户
etcdctl role add test --user=root:pwd # 添加角色
etcdctl role grant-permission --from-key test read "" --user=root:pwd #角色授予所有key读权限（read，write，readwrite）
etcdctl user grant-role test test # 用户test授予test角色
2） 基于证书的访问控制开（支持双向认证）
#[Security]
ETCD_CERT_FILE="server.pem" #服务端证书
ETCD_KEY_FILE="server-key.pem" #
ETCD_CLIENT_CERT_AUTH="true" #是否开启客户端端证书认证
ETCD_TRUSTED_CA_FILE="ca.pem" #客户端服务器TLS授信的CA证书路径，
ETCD_AUTO_TLS="true" # 客户端TLS是否使用自动生成的证书
ETCD_PEER_CERT_FILE="peer.pem" #节点通讯采用的客户端证书
ETCD_PEER_KEY_FILE="peer-key.pem"
ETCD_PEER_CLIENT_CERT_AUTH="true" #是否启用peer客户端证书认证
ETCD_PEER_TRUSTED_CA_FILE="ca.pem" 服务端TLS授信的CA证书路径
ETCD_PEER_AUTO_TLS="true" #是否使用自动生成的证书