如何进行etcd的分析

共计 2243 个字符，预计需要花费 6 分钟才能阅读完成。

这篇文章给大家介绍如何进行 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 的 Raft

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

脑裂解决方案

引入一个新的概念, region leader

region leader 是一个逻辑上的概念

任意时刻对于某一个 region 来说, 一定只拥有一个 region leader

每个 region leader 在任期之内尝试每隔 t 时间间隔, 在 raft group 内部更新一下 region leader 的 lease.

所有的读写请求都必须通过 region leader 完成

但是值得注意的是，region leader 和 raft leader 可能不是一个节点。当 region leader 和 raft leader 不重合的时候，region leader 会将请求转发给当前的 raft leader

当网络出现分区时，会出现以下几种情况：

region leader 落在多数派，老 raft leader 在多数派这边

region leader 落在多数派，老 raft leader 在少数派这边

region leader 落在少数派，老 raft leader 在多数派这边

region leader 落在少数派，老 raft leader 在少数派这边

存储 (v3)

v3 和之前版本差别太大，仅以其为准

Backend：BoltDB

基本特点

单机

支持事务

键值对

事务处理

增、删、读：都要获取一个事务

只读事务：只读，只能查找 Bucket 和 K/V

读写事务：可读写

结束时：若无异常，则提交事务

有异常：抛弃整个事务

MVCC 结构层次

revision：对同一个 key 每次修改都对应一个 revision – main：每次事务 +1 – sub：同次事务每次对其操作 +1 generation：– 一个 key 在生命周期内可能被频繁删除 – 从某次创建到该次删除的所有 revision 集合组成一个 generation key：每个 key 是由多个 generation 组成多版本 keyIndex：组织这个多版本 key 的结构体叫做 keyIndex

维护

多个版本同时保持，需要不定期清理

删除过老版本

ectd 提供了命令行工具

实现

type keyIndex struct {key []byte
 modified revision // 最新版本 revision
 generations []generation // 代
type generation struct {
 ver int64
 created revision //  创建这个代的第一个版本
 revs []revision// 版本数组
type revision struct {
 main int64 // 事务 id，全局递增
 sub int64 //  事务内递增
}

例子 插入数据

(key1, value1)
(key2, value2)

更新数据

(key1, update1)
(key2, update2)

存储的记录

rev={1 0}, key=key1, value= value1 
rev={1 0}, key=key2, value= value2 
rev={2 0}, key=key1, value= update1 
rev={2 1}, key=key2, value= update2

内存索引：KeyIndex

基本特点

基于 Google 开源

基于 btree

组件

HTTP Server：用于处理用户发送的 API 请求以及其它 etcd 节点的同步与心跳信息请求。

Store：用于处理 etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现。

Raft：Raft 强一致性算法的具体实现，是 etcd 的核心。

WAL：Write Ahead Log（预写式日志），是 etcd 的数据存储方式

除了在内存中存有所有数据的状态以及节点的索引以外，etcd 就通过 WAL 进行持久化存储

WAL 中，所有的数据提交前都会事先记录日志

Snapshot 是为了防止数据过多而进行的状态快照

Entry 表示存储的具体日志内容

关于如何进行 etcd 的分析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。