如何进行etcd的分析

这篇文章给大家介绍如何进行etcd的分析,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。

成都创新互联公司是一家专业提供禄丰企业网站建设,专注与成都网站设计、网站建设、外贸网站建设html5、小程序制作等业务。10年已为禄丰众多企业、政府机构等服务。创新互联专业网络公司优惠进行中。

机制

概念

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


网站标题:如何进行etcd的分析
新闻来源:http://azwzsj.com/article/ipejeh.html