文章目录
- 核心概念
- 什么是etcd
- 为什么需要etcd
- 分布式中CAP理论
- etcd中常用的术语
- etcd的特性
- etcd的应用场景
- etcd的核心架构
- 小结
- etcd搭建
- 小结
- Etcdctl
- 小结
- etcd网关和grpc-Getway
- Etcd 网关模式
- grpc-Geteway
- 小结
- etcd读请求执行流程
- Etcd 写请求执行流程
- 写请求之Quota
- KVServer模块
- 写请求之WAL详解
- Apply模块
- 写请求之MVCC
- Raft算法
- leader选举原理
- 日志复制原理
- 保证数据不丢失
- MVCC原理
在之前的学习中,经常会听到或者用到etcd,尤其是在做微服务的时候,用它来进行服务的注册与发现,好像离开他,很多东西也就都不行了,所以总结一下etcd的一些基础知识。
核心概念
什么是etcd
由于云原生的出现,有了很多的分布式微服务的概念,所以也需要很多的技术去支持,这里的etcd是k8s内部的一大关键组件,etcd可以进行可靠的分布式数据存储。
etcd:是一个用于配置共享和服务发现的键值存储系统。
归根结底是一个存储组件,并且可以实现配置共享和服务发现。,是一款实现了元数据信息可靠存储的组件。可以几种管理配置信息。
需要注意的是,etcd是由go语言实现的。
为什么需要etcd
要知道云原生中的微服务应用是分布式系统的落地实践,但是有一个比较大的问题就是在多个实例服务中,数据存储不一致的问题,也就是自己的数据和拿到的数据可能不相同。
分布式中CAP理论
CAP理论就是说Consistency(一致性),Availability(可用性)和Partition tolerance(分区容错性)三个不能同时存在,最多实现两个,分布式的特性分区容错性是必须要满足的。
下面的示例中:银行的话就需要有强一致性,但是想网页一样的话,就需要的是可用性,因为大家一般不会去关注版本
etcd中常用的术语
etcd的特性
简单,存储,Watch机制,安全通信,高性能,一直可靠。
实现了分布式一致性键值对存储的中间件
etcd的应用场景
- 键值对存储
- 服务注册与发现:使用Raft算法保证分布式场景中的一致性
- 消息发布于订阅
- 分布式锁:存储到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:
- etcd网关不是为了提高etcd集群性能设计的
- 在集群上面运行管理系统
总而言之,为了自动传播集群端点更改,etcd网关在每台机器上都允许,为了多个应用提供访问相同的etcd集群服务
在使用的时候一定要注意当前的etcd的版本,然后根据版本再去选择需要的接口。
grpc-Geteway
为非grpc的客户端提供http接口,
HTTP的方式访问etcd服务端,需要考虑安全问题,grpc-GEteway中提供API接口支持开启安全认证
创建用户->创建角色->用户授予角色->开启认证
小结
etcd读请求执行流程
上面的总结了很多,但是感觉的作用不是很大,所以从这里直接开始去看一些执行流程。然后方便我们去了解他的底层构造。
我们从上面这个图中,一步步去理解整个的过程
- client
- 首先,对命令参数进行解析
- 创建一个库对象,使用KVServer模块的API访问etcd Server
-
注意这里client v3库是有个负载均衡的算法Round-robin。针对每一个请求,通过轮询的方式从endpoint列表中选择一个(长连接),是etcd server负载尽量均衡
- KVserver 与连接器
etcd通过拦截器以非法入侵的方式实现许多特性:
要求执行一个操作前集群必须有Leader
请求延时超过指定阈值的,打印包含来源IP的慢查询日志
- 串行读和线行读
为了保证服务高可用,生产环境一般部署多个节点,多节点之间的数据由延迟等关系可能会存在不一致情况。
在多节点etcd集群中,各个节点的状态机一致性存在差异
-
串行直接从状态机返回数据,没有Raft协议和集群进行交互,低延迟,高吞吐,使用与一致性比较要求不高的场景
-
线性:etcd默认是这个,需要Raft协议模块,反应的是集群知识,在延时和吞吐量上差一点,但是一致性高
-
ReadIndex
这个机制保证在串行读的时候,也能读到最新的数据
从图中可看到,主要的是读的位置不一样,一个是普通节点,一个是leader节点
- 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对象,表示这个索引被删除了