如何进行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的分析
URL链接:http://scyanting.com/article/ipejeh.html