etcd架构
- client:提供了简洁易用的API,同时支持负载均衡、节点故障自动转移，可极大降低业务使用etcd复杂度,提升开发效率、服务可用性。
- API:client访问etcd server的api,server之间访问,节点间通过Raft算法实现数据复制和Leader选举等功能。
- Raft算法层:实现Leader选举、日志复制、ReadIndex等核心算法特性,用于保证etcd多个节点间的数据一致性、提供服务可用性等。
- 功能逻辑层: KVServer模块、MVCC模块(treeIndex模块和boltdb模块)、Auth鉴权模块、Lease续约模块、Comparator压缩模块。
- 存储层:包含预写日志(WAL)模块(保证数据不丢)、快照模块、boltdb模块(保存元数据和用户数据)。
etcd是典型的读多写少存储。
Client
在etcd v3.4.9版本中,etcdctl是通过clientv3库中访问ectd server的, client v3库基于gRPC client API封装了操作etcd KVServer、Cluster、
Auth、Lease、Watch等模块的API，同时包含了负载均衡、健康探测和故障切换等特性。
负载均衡算法:
- 如果client版本<=3.3,当配置多个endpoints时,负载均衡仅会从选择一个IP并创建一个连接,这样可以节省服务器总连接数。
在heavy usage场景,回造成server负载不均衡。- 在client 3.4 之前的版本中，负载均衡算法有一个严重bug:如果第一个节点异常了，可能回导致client访问etcd server异常,特别是
K8S 场景中会导致APIServer不可用。在K8S 1.16版本后被修复。
KVServer
etcd通过拦截器提供了丰富的metrics、日志、请求行为检查等机制，可记录所有请求的执行耗时及错误码、来源IP等，也可控制请求是否允许通过。
etcd 实现了一些特性:
- 执行一个操作前集群必须有Leader,防止脑裂;
- 请求延时超过指定阈值时,打印包含来源IP的慢查询日志。
串行读与线性读
串行读过程:
client发送请求到etcd server-->Leader 节点收到请求之后,持久化到WAL日志-->广播给各个节点,等到一半以上节点上持久化成功-->将请求标记为已提交
-->ectd server 模块异步从Raft模块获取已提交的日志条目,应用到状态机。
线性读是通过ReadIndex机制保证数据一致性原理。
线性读过程:
KVServer模块收到线性读请求后,向Raft模块发起ReadIndex请求,Raft模块将Leader最新的已提交日志索引封装在ReadState结构块,通过channel
层层返回给线性读模块,线性读模块等待本节点状态机追赶上Leader进度,追赶完成后,通知KVServer模块,与状态机中的MVCC模块进行交互。
串行读具有低延时、高吞吐量的特点,适合对数据一致性要求不高的场景。
线性读解决读数据一致性要求高的场景。
MVCC
MVCC的核心由内存树形索引模块和嵌入式的KV持久化存储库boltdb组成。
boltdb是基于B+ tree实现的k-v键值库,支持事物,提供GET/PUT等简易API给etcd操作。
etcd如何基于boltdb保存一个key的多个版本:
- 一个key保存多个历史版本的值;导致value太大,存在明显读写放大、并发冲突等问题。
- 每次修改操作,生成一个新的新版本号;以版本号为key,value为用户key-value等信息组成的结构体。
treeIndex
treeIndex是基于btree实现的。treeIndex模块只会保存用户的key和用户版本号信息,用户的key的value数据存储在boltdb里面。
从treeIndex模块中获取hello这个key对应的版本号信息,treeIndex模块基于B-tree快速查找此key, 返回此key对应的索引项keyIndex即可。
buffer
获取版本号之后,可以从boltdb模块中获取用户的key-value数据了。在访问boltdb前,首先会从一个内存读事物buffer中，
二分查找要访问key是否存在，如果命中则直接返回。
boltdb
boltdb是使用bucket隔离集群元数据和用户数据,bucket就是MySQL的一个表,用户的key数据存放真的bucket名字的是key,
etcd MVCC元数据存放的bucket是meta。
