etcd基础知识总结

在之前的学习中，经常会听到或者用到etcd，尤其是在做微服务的时候，用它来进行服务的注册与发现，好像离开他，很多东西也就都不行了，所以总结一下etcd的一些基础知识。

核心概念

什么是etcd

由于云原生的出现，有了很多的分布式微服务的概念，所以也需要很多的技术去支持，这里的etcd是k8s内部的一大关键组件，etcd可以进行可靠的分布式数据存储。

etcd：是一个用于配置共享和服务发现的键值存储系统。

归根结底是一个存储组件，并且可以实现配置共享和服务发现。，是一款实现了元数据信息可靠存储的组件。可以几种管理配置信息。

需要注意的是，etcd是由go语言实现的。

为什么需要etcd

要知道云原生中的微服务应用是分布式系统的落地实践，但是有一个比较大的问题就是在多个实例服务中，数据存储不一致的问题，也就是自己的数据和拿到的数据可能不相同。

分布式中CAP理论

CAP理论就是说Consistency（一致性），Availability（可用性）和Partition tolerance（分区容错性）三个不能同时存在，最多实现两个，分布式的特性分区容错性是必须要满足的。

下面的示例中：银行的话就需要有强一致性，但是想网页一样的话，就需要的是可用性，因为大家一般不会去关注版本

etcd中常用的术语

etcd的特性

简单，存储，Watch机制，安全通信，高性能，一直可靠。

实现了分布式一致性键值对存储的中间件

etcd的应用场景

1. 键值对存储
2. 服务注册与发现：使用Raft算法保证分布式场景中的一致性
3. 消息发布于订阅

1. 分布式锁：存储到etcd集群中都是一直

etcd的核心架构

基本etcd使用咱们都做过，服务端和客户端的api接口也都是使用的，但是没使用过比较高级的，比如使用watch之类，它们的底层比较复杂，但是还是要学习的

小结

etcd搭建

基本的使用都是会的，所以只是总结一些之前没有使用过的一些知识点

在实际应用中，为了高可用，一般都是以集群的方式部署，以避免单点故障

etcd支持通过TLS协议进行的加密通信，TLS通道可用于对等体（指etcd集群中的服务实例）之间的加密内度集群通信以及加密的客户端流量

小结

Etcdctl

首先来看看etcd中一些比较有用的命令，咱们可以通过etcdctl -h然后就可以获取了，可以查看里面所有的指令可以大致看看里面的一些基础操作，虽然一般都是通过其他的语言，去操作，但是一般时候还是比较有用的，咱们可以通过这些进行一定的判断操作

这些命令大致分为数据库操作和非数据库操作，一般使用的是前者

添加
zwm@zwm-Lenovo-V15-G2-ITL:~/dos$ etcdctl put /test/fool "123'
"
OK
获取
etcdctl get /test/fool
/test/fool
123'

对于这些增删改查的操作都是比较简单的，可以使用watch用于检测某个值的变化，但是有些时候有点异常，所以就要指定历史版本，然后用于监控。

lease（租约）：ease为租约，相当于Redis中的TTL，etcd中的键值对可以绑定到租约上面，实现存活周期控制，可以设置，删除，刷新，查询租约。

小结

etcd网关和grpc-Getway

Etcd 网关模式

etcd网关是一个简单的TCP代理，可以将网络数据转发到etcd集群中，网关是无状态并且透明的，不会检查客户端请求，也不会干扰集群响应，支持多个etcd服务器实例，采用简单的循环策略

下面两个不适用于etcd：

1. etcd网关不是为了提高etcd集群性能设计的
2. 在集群上面运行管理系统

总而言之，为了自动传播集群端点更改，etcd网关在每台机器上都允许，为了多个应用提供访问相同的etcd集群服务

在使用的时候一定要注意当前的etcd的版本，然后根据版本再去选择需要的接口。

grpc-Geteway

为非grpc的客户端提供http接口，

HTTP的方式访问etcd服务端，需要考虑安全问题，grpc-GEteway中提供API接口支持开启安全认证

创建用户->创建角色->用户授予角色->开启认证

小结

etcd读请求执行流程

上面的总结了很多，但是感觉的作用不是很大，所以从这里直接开始去看一些执行流程。然后方便我们去了解他的底层构造。

我们从上面这个图中，一步步去理解整个的过程

1. client
   1. 首先，对命令参数进行解析
   2. 创建一个库对象，使用KVServer模块的API访问etcd Server

   3. 注意这里client v3库是有个负载均衡的算法Round-robin。针对每一个请求，通过轮询的方式从endpoint列表中选择一个（长连接），是etcd server负载尽量均衡

2. KVserver 与连接器

etcd通过拦截器以非法入侵的方式实现许多特性：

要求执行一个操作前集群必须有Leader

请求延时超过指定阈值的，打印包含来源IP的慢查询日志

1. 串行读和线行读

为了保证服务高可用，生产环境一般部署多个节点，多节点之间的数据由延迟等关系可能会存在不一致情况。

在多节点etcd集群中，各个节点的状态机一致性存在差异

1. 串行直接从状态机返回数据，没有Raft协议和集群进行交互，低延迟，高吞吐，使用与一致性比较要求不高的场景

2. 线性：etcd默认是这个，需要Raft协议模块，反应的是集群知识，在延时和吞吐量上差一点，但是一致性高

3. ReadIndex

这个机制保证在串行读的时候，也能读到最新的数据

从图中可看到，主要的是读的位置不一样，一个是普通节点，一个是leader节点

1. MVCC

是有内存树形索引模块和嵌入式和KV之久话存储库boltdb组成。

Etcd 写请求执行流程

这里需要注意的是API的调用不会直接到KVserver上面，而是先到Quata上面，这个的作用是啥呀，就是用来判断etcd是否再够进行存储的空间

这里对于WAl还有一个存储，是为了保证宕机之后的数据恢复。

写请求之Quota

主要用于检查当前etcd db大小加上你请求的key-value大小之和是否超过配额。

无论是API层gRpc模块还是负责将Raft侧已经提交的日志条目应用到状态机的Apply模块，都拒绝写入，集群只读。

有时候会检测到超越db的大小然后如法写入，触发错误的条件

• db配额仅为2G
• 另一方面etcd是一个MVCC数据库，保存了key的历史版本，当你没有配置压缩策略的时候，数据不断写入，会增大

解决方法

• 调大配额，建议不超过8G，不建议禁用
• 检查etcd的压缩是否开启

KVServer模块

• 打包提案：将put写请求内如打包成一个消息，提交给Raft
• 请求限速，检查：在提交前，还有限速，鉴权和打包检查

Preflight Check

• 限速：日志索引超过了5000，请求太多
• 鉴权：检查是否使用了密码鉴权，请求中是否携带token
• 大包检查：写入包是否超过默认值1.5G

Propose:etcd默认超时时间是7秒，如果一个请求超时未返回结果，出现这个错误

写请求之WAL详解

在数据库中的持久化也是使用这个机制的，将put的请求封装成一个Raft条目，apply模块这里是一个队列。

Apply模块

如果执行过程中宕机，重启之后如何找回异常提案。再次执行呢？

这里就要使用到WAL日志。

重启恢复，如何保证幂等性，防止提案重复执行导致数据混乱呢？

通过引入一个consistent index的字段，来存储系统当前已经执行过的日志条目索引，实现幂等性。这里需要保证它的原子性

写请求之MVCC

需要保证写到磁盘，才算是真正的提交上去了。

在存到boltdb的时候，需要先存到buffer里面，注意在读的时候，会先在buffer里面读数据，这个过程是比较重要的。

Raft算法

Raft算法是现在分布式系统开发首选的共识算法

通过一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致。

选择leader是一个比较好的算法，可以通过官网去观察动画，在有了leader之后，会向其他节点发送心跳，保证连接，然后如果leader宕机之后，会重新选择的，只有leader节点会进行写数据的。然后就是日志复制只有leader，安全性，只有一个leader节点。

leader选举原理

有三种节点，leader，candidate，follower三种节点 ，每次选举都会有一个任期，etcd默认心跳是100ms。默认竞选时间是1000ms。

当leader宕机之后，立马重新开始选举，为了防止很多时间是一致的，无法选举出来，然后就有一个时钟的随机数。

为了避免无效的选举，etcd引入了一个PreVote，用来启动PreCandidate状态，follower在转换为Candidate前，先进入这个状态，不自增任期号，发起预投票。若获得集群多数节点认可，确定有概率称为leader才进入竞选者状态，发起选举流程。

日志复制原理

保证数据不丢失

选举规则

在投票的时候，检查候选者最后一条日志的任期号

• 若小于自己则投票
• 如果任期号相同，日志却比自己短，也拒绝为其投票

日志复制规则

• Leader完全特性：是指如果某个日志条目在某个任期号中已经被提交，那么这个条目必然出现更大的任期号的所有Leader中
• 只附加原则：Leader只能追加日志条目，不能删除已经持久化的日志条目
• 日志匹配特性

MVCC原理

treeIndex原理

通过数据结构B-tree保存用户key和版本号之间的关系，再以版本号作为boltdb key，以用户的key-Value等信息作为boltdb value,保存到boltdb。

更新key原理

查询key原理

删除key原理和更新的原理相似

不同之处：

• 生成的boltdbkey版本号删除表示，doltdb value变成了只含有用户的key的keyValue结构体
• treeIndex也会给次key hello对应的keyIndex对象，增加一个空的generation对象，表示这个索引被删除了