这篇文章给大家介绍如何进行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的分析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。