etcd详解

概念

etcd 是一个高可用的分布式键值key-value数据库，可用于服务发现。

etcd 采用raft 一致性算法，基于 Go语言实现。

etcd作为一个高可用键值存储系统，天生就是为集群化而设计的。

etcd部署方式

由于Raft算法在做决策时需要多数节点的投票，所以etcd一般部署集群推荐奇数个节点，推荐的数量为3、5或者7个节点构成一个集群。

官网地址

https://etcd.io/

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 leader选举详解-CSDN博客

安装部署

参考：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）基于证书的访问控制开（支持双向认证）