etcd文件索引存储

⑴ etcd工作原理和部署指南

​ etcd是由CoreOS团队发的一个分布式一致性的KV存储系统，可用于服务注册发现和共享配置，随着CoreOS和Kubernetes等项目在开源社区日益火热，它们项目中都用斗老塌到的etcd组件作为一个高可用强一致性的服务发现存储仓库，渐渐为开发人员所关注。在云计算时代，如何让服务快速透明地接入到计算集群中，如何让共享配置信息快速被集群中的所有机器发现，更为重要的是，如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群，已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音，本文将从etcd的应用场景开含档始，深入解读etcd的实现方式，以供开发者们更为充分地享用etcd所带来的便利。

​ etcd推荐使用奇数作为集群节点个数。因为奇数个节点和其配对的偶数个节点相比，容错能力相同，却可以少一个节点。综合考虑性能和容错能力，etcd官方文档推荐的etcd集群大小是3,5,7。由于etcd使用是Raft算法，每次写入数据需要有2N+1个节点同意可以写入数据，所以部分节点由于网络或者其他不可靠因素延迟收到数据更新，但是最终数据会保持一致，高度可靠。随着节点数目的增加，每次的写入延迟会相应的线性递增，除了节点数量会影响写入数据的延迟，如果节点跟接节点之间的网络延迟，也会导致数据的延迟写入。
结论：
​ 1.节点数并非越多越好，过多的节点将会导致数据延迟写入。
​ 2.节点跟节点之间的跨机房，专线之间网络延迟，也将会导致数据延迟写入。
​ 3.受网络IO和磁盘IO的延迟
​ 4.为了提高吞吐量，etcd通常将多个请求一次批量处理并提交Raft，
​ 5.增加节点，读性能会提升，写性能会下降，减少节点，写性能会提升。

参数说明：

这种方式就是 利用一个已有的 etcd 集群来提供 discovery 服务，从而搭建一个新的 etcd 集群。

假设已有的 etcd 集群的一个访问地址是： myetcd.local ，那么我们首先需要在已有 etcd 中创建一个特殊的 key，方法如下：

其中 value=3 表示本集群的大小，即: 有多少集群节点。而 就是用来做 discovery 的 token。

接下来你在 3 个节点上分别启动 etcd 程序，并加上刚刚的 token。
加 token 的方式同样也有 命令行参数 和 环境变量 两种。

命令行参数:

环境变量

以 命令行参数 启动方式为例：

可以使用etcd附带的 基准 CLI工具完成基准测试etcd性能。

对于一些基准性能数字，我们考虑具有以下硬件配置的三个成员的etcd集群：

有了这个配置，etcd可以大致写出：

示例命令是：

可线性读取请求通过集群成员的法定人数达成一致以获取最新数据。可序列化的读取请求比线性读取要便宜，因为它们由任何单个etcd成员提供，而不是成员法定人数，以换取可能的陈旧数据。etcd可以阅读：

示例命令是：

我们鼓励在新环境中首次安装etcd集群时运行基准测试，以确保集群达到足够的性能; 群集延迟和吞吐量可能会对较小的环境差异敏感。

以上测试部分翻译空圆自官方文档（ https://coreos.com/etcd/docs/latest/op-guide/performance.html ）

⑵ etcd简要使用

etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines.
从定义可以看到，etcd是一个key-value型存储，具有强一致性

etcd的客户端有etcdctl、etcd-go、etcd-java，其中etcdctl是etcd自带的命令行工具，其主要命令有

etcd的数据是按照B+树的方式组织，并按照MVCC的思想存储数据，也就衡早祥是数据按照多咐搏个版本存储，每个版本都有一个版本号，当数据更新时，并非更新原有数据，而是再存储一条新版本号数据。

在内存中，实际上有两个B+树，一个存储key到revison的映射，一个存储revison和value的映射。当进行get的时候，先到key-revison映射中查找revison，如果未制定版本号，就取最新的revison，然后睁祥用revison到revison-value的B+树查找value。

为什么要用B+树，因为要支持范围查找。

本文总结etcd的简要使用，下篇再对底层原理进行解析。

⑶ Etcd 写请求过程

etcdserver:mvcc:database space exceeded错误:

etcd server收到put/txn等写请求的时候,会首先检查当前etcd db大小加上请求的key-value大小只是否超过了配额。
如果超过配额,会产生一个告警请求,告警类型为NO SPACE,并通过Raft日志同步给其他节点,告知db无空间,并将告警持久化
到db中。

etcd设置建议配额不超过8G。APPLY模块在执行每个命令的时候,都会去检查当前是否存在NO SPACE告警,如果有则拒绝写入。
在调大配额之后,需要发送一个取消告警的命令,以消世棚巧除所有告警。

检查etcd的压缩是否开启、配置是否合理。在配置etcd db配额,就不要设置小于0的,这样是禁用配额功能。

为了保证集群稳定性,避免雪崩,任何提交到raft模块的请求,都会做一些简单的限速判断。

在经过检查之后,会生成一个唯一的ID,将此请求关联到一个对应的消息通知channel,然后raft模块发起Propose一个提案,向raft模和迟块发起的提案后,
KVServer模块会等待此put请求,等待写入结果通过消息通知channel返回或者超时。etcd默认超时时间是7秒,如果一个请求超时未返回结果,则可能会出现你熟悉的

Raft模块收到提案后,如果当前节点是Follower,它会转发给Leader,只有Leader才能搜键处理写请求,Leader收到提案后,通过Raft模块输出待转发给Follower
节点的消息和待持久化的日志条目。
etcdserver 从Raft模块获取到以上消息和日志条目后,作为Leader,它会将put提案消息广播给集群各个节点,同时需要把集群Leader任期号、投票信息、
以提交索引、提案内容持久化到一个WAL日志文件中,用于保证集群的一致性，可恢复性。

WAL记录是按照顺序追加写入组成,每个记录由类型(Type)、数据(Data)、循环冗余校验码(CRC)组成。

WAL记录类型目前支持5种,分别是文件元数据记录、日志条目记录、状态信息记录、CRC记录、快照记录:

WAL模块是如何持久化一个put提案的日志条目记录:

每个提案被提交前都会被持久化到WAL文件中,以保证集群的一致性和可恢复性。

etcd的幂等性是根据Raft日志条目中的索引字段。etcd通过引入consistent index字段,来存储系统当前已经执行过的日志条目索引,实现幂等性。

Apply模块基于consistent index和事务实现了幂等性。

MVCC主要是由两部分组成,一个是内存索引模块treeIndex,保存key的历史版本信息,另一个是boltdb模块,用来持久化存储key-value数据。

版本号在etcd里面发挥着重大作用,它是etcd的逻辑时钟。etcd启动的时候默认版本号是1,从最小值1开始枚举到最大值,未读到数据的数据则结束,最后读出来的
版本号即时当前etcd的最大版本号currentRevision。

boltdb是一个基于B+tree实现的key-value嵌入式db,通过提供桶机制实现类似于Mysql表的逻辑隔离。
将修改的数据放入到一个名为key的桶里,在启动etcd时自动创建。

boltdb value的值是将包含key名称、key创建是时版本号、最后一次修改的版本号、修改菜蔬、value值、租赁信息序列化为二进制数据。

etcd使用合并再合并解决写性能差的问题:

etcd在启动时候通过mmap机制将etcd db文件映射到etcd进程地址空间,并设置mmap的MAP_POPULATE flag,它会告诉Linux内核预读文件,Linux就会将文件内容
拷贝到物理内存中,此时会产生磁盘I/O。节点在内存足够的请求下,后续处理读请求过程中就不会产生磁盘I/O了。
如果etcd节点内存不足时,可能会导致db文件对应的内存页被换出,当读请求命中的文件未在内存中时,就会产生缺页异常,导致读过程中产生磁盘IO,
可以通过观察etcd进程
可以通过观察etcd进程的majflt字段来判断etcd是否产生了主缺页中断。

⑷ k8s etcd 与持久化存储

1、是什么

2、etcd架构及工作原理

(1) 数据流程

一个用户的请求发送过来，会经过HTTP Server转发给store进行具体事务处理，如果涉及到节点的修改，则需要交给raft模块进行状态的变更，日志的记录，然后再同步给别的etcd节点确认数据提交，最后进行数据提交，再次同步

(2)工作原理

Etcd使用 Raft协议 来维护集群内各个节点状态的 一致性 。简单说，ETCD集群是一个分布式系统，由多个节点相互通信构成整体对外服务， 每个节点都存颤锋慎储了完整的数据 ，并且通过Raft协议保证每个节点维护的数据是一致的

(3) 主要组成部分

(4)etcd集群中的术语

3、k8s中的etcd

(1)etcd在k8s中的作用： etcd在kubernetes集群是用来存放数据并通知变动的

(2)为什么k8s选择etcd：

PV 目前支持的类型包括：gcePersistentDisk 、AWSElasticBlockStore 、AzureFile 、AzureDisk 、FC ( Fibre Channel ） 、Flocker、NFS 、iSCSI 、RBD (Rados Block Device ）、CephFS 、Cinder、GlusterFS 、V sphere Volume 、Quobyte Volumes 、VMware Photon 、Portwonc
Volumes 、ScaleIO Volumes 和HostPath （仅供单机测试）。

如果某茄敬个Pod 想申请某种类型的PY ，则首先基郑需要定义一个PersistentVolurneClaim ( PVC )对象，然后，在Pod 的Volume 定义中引用上述PVC 即可：

⑸ 上传文件后缀名为etcd的文件

etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的，灵感来自于 ZooKeeper 和 Doozer，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强一致性。Raft是一个来自Stanford的新仿毕的一致性算法，适用于分布式系统的日志复制，Raft通过选举的方式来实现一致性，在Raft中，任何一个节点都可能成为Leader。Google的容器集群管理系统Kubernetes、开源PaaS平台Cloud Foundry和CoreOS的Fleet都广泛使用了etcd。

etcd 集群的工作原理基于 raft 共识算法 (The Raft Consensus Algorithm)。etcd 在 0.5.0 版本中重新实现了 raft 算法，而非像之前那样依赖于第三方库 go-raft 。raft 共识算法的优点在于可以在高效的解决分布式系统中各个节点日志穗首内容一致性问题的同时，也使得集群具备一定的容错能力。即使集群中出现部分节点故障、网络故障等问题，仍可保证备族芹其余大多数节点正确的步进。甚至当更多的节点（一般来说超过集群节点总数的一半）出现故障而导致集群不可用时，依然可以保证节点中的数据不会出现错误的结果。

⑹ 笔记本etcd什么意思

键值存储仓库，用于配置共享和服务发现。
扩展知识：etcd（桥山袭读作 et-see-dee）是一种开源的分布式统一唯慧键值存储，用于分布式系统或计算机集群的共享配置、服务发现和的调度协调。etcd 有助于促进更加安全的自动更新，协调向主机调度的工作，并帮助设置容器的覆盖网络。

etcd 是许多其敏兄他项目的核心组件。最值得注意的是，它是 Kubernetes 的首要数据存储，也是容器编排的实际标准系统。使用 etcd， 云原生应用可以保持更为一致的运行时间，而且在个别服务器发生故障时也能正常工作。应用从 etcd 读取数据并写入到其中；通过分散配置数据，为节点配置提供冗余和弹性。

⑺ ETCD——基础原理

一个ETCD集群一般由3个或者5个节点组成，两个quorum一定存在交集，则

即：3个节点容忍1个节点故障，5个节点容忍2个节点故障，以此类推。

首先，所有的数据都保存在B+树（灰色），当我们指定了版本信息之后，会直接到灰色B+树中去获取相关的数据；同时，还有另外一个B+树，它维护了key和revions的映射关系，查询key的数据时候，会根清凳颂据key查询到revision，再通过revision查询到相应的key。

etcd 使用 raft 协议来维护集群内各个节点状态的一致性。简单说，etcd 集群是一个分布式系统，由多个节点相互通信构成整体对外服务，每个节点都存储了完整的数据，并且通过 Raft 协议保证每个节点维护的数据粗备是一致的。

每个 etcd 节点都维护了一个状态机，并且，任意时刻至多存在一个有效的主节点。主节点处理所有来自客户端写操作，通过 Raft 协议保证写操作对状态机的改动会可靠的同步到其他节点。

etcd 的设计目标是用来存放非频繁更新的数据，提供可靠的 Watch插件，它暴露了键值对的历史版本，以支持低成本的快照、监控历史事件。这些设计目标要求它使用一个持久化的、多版本的、支持并发的数据数据模型。

当 etcd 键值对的新版本保存后，先前的版本依然存在。从效果上来说，键值对是不可变的，etcd 不会对其进行 in-place 的更新操作，而总是生成一个新的数据结构。为了防止历史版本无限增加，etcd 的存储支持压缩（Compact）以及删除老旧版本。

逻辑视图

从逻辑角度看，etcd 的存储是一个扁平的二进制键空间，键空间有一个针对键（字节字符串）的词典序索引，因此范围查询的成本较低。

键空间维护了多个修订版本（Revisions），每一个原子变动操作（一个事务可由多个子操作组成）都会产生一个新的修订版本。在集群的整个生命周期中，修订版都是单调递增的。修订版同样支持索引，因此基于修订版的范围扫描也是高效的。压缩操作需要指定一个修订版本答郑号，小于它的修订版会被移除。

一个键的一次生命周期（从创建到删除）叫做 “代 (Generation)”，每个键可以有多个代。创建一个键时会增加键的版本（version），如果在当前修订版中键不存在则版本设置为1。删除一个键会创建一个墓碑（Tombstone），将版本设置为0，结束当前代。每次对键的值进行修改都会增加其版本号 — 在同一代中版本号是单调递增的。

当压缩时，任何在压缩修订版之前结束的代，都会被移除。值在修订版之前的修改记录（仅仅保留最后一个）都会被移除。

物理视图

etcd 将数据存放在一个持久化的 B+ 树中，处于效率的考虑，每个修订版仅仅存储相对前一个修订版的数据状态变化（Delta）。单个修订版中可能包含了 B+ 树中的多个键。

键值对的键，是三元组（major，sub，type）

键值对的值，包含从上一个修订版的 Delta。B+ 树 —— 键的词法字节序排列，基于修订版的范围扫描速度快，可以方便的从一个修改版到另外一个的值变更情况查找。

etcd 同时在内存中维护了一个 B 树索引，用于加速针对键的范围扫描。索引的键是物理存储的键面向用户的映射，索引的值则是指向 B+ 树修该点的指针。

元数据存储——Kubernetes

Service Discovery(Name Service)

Distributed Coordination: Leader Election

⑻ kubernetes控制平面组件：etcd

--listen-peer-urls

--listen-client-urls

--initial-advertise-peer-urls

--initial-cluster

--initial-cluster-state

--advertise-client-urls

1.code

headless svc, 像DNS RR ClusterIP:None

kubectl -n stg1 get endpoints

client 怎么访问：

2.配置文件

3.apply

官方的code有两个问题

本地访问

扩容

利用反亲和性 分布etcd pod到不同节点

~ ❯❯❯ etcdctl get / --prefix

从 etcd 的架构图中我们可以看到，etcd 主要分为四个部分。

etcd 目前支持 V2 和 V3 两个大版本，这两个版本在实现上有比较大的不同，一方面是对外提供接口的方式，另一方面就是底层的存储引擎，V2 版本的实例是一个纯内存的实现，所有的数据都没有存储在磁盘上，而 V3 版本的实例就支持了数据的持久化。

v3默认boltdb

consortium etcd2+mysql

数据默认会存放在 /var/lib/etcd/default/ 目录。我们会发现数据所在的目录，会被分为两个文件夹中，分别是 snap 和 wal目录。

解决三个问题：节点选举、拆仿日志复制以及安全性 。

每一个 Raft 集群中都包含多个服务器，在任意时刻，每一台服务器只可能处于 Leader 、 Follower 以及 Candidate 三种状态；在处于正常的状态时，集群中只会存在一个 Leader 状态，其旅亩纤余耐中的服务器都是 Follower 状态。

所有的 Follower 节点都是被动的，它们不会主动发出任何的请求 ，只会响应 Leader 和 Candidate 发出的请求。对于每一个用户的可变操作，都会被路由给 Leader 节点进行处理，除了 Leader 和 Follower 节点之外，Candidate 节点其实只是集群运行过程中的一个临时状态。

每一个服务器都会存储当前集群的最新任期，它就像是一个单调递增的逻辑时钟，能够同步各个节点之间的状态，当前节点持有的任期会随着每一个请求被传递到其他的节点上。Raft 协议在每一个任期的开始时都会从一个集群中选出一个节点作为集群的 Leader 节点，这个节点会负责集群中的日志的复制以及管理工作。

客户端通过 监听指定的key可以迅速感知key的变化并作出相应处理 ，watch机制的实现依赖于 资源版本号revision的设计 ，每一次key的更新都会使得revision原子递增，因此根据不同的版本号revision的对比就可以感知新事件的发生。etcd watch机制有着广泛的应用，比如利用etcd实现分布式锁； k8s中监听各种资源的变化 ，从而实现各种controller逻辑等。

watch机制的实现主要可分为三个部分

client使用 watchClient 的watch接口发起watch请求，与server端建立一个 gRPCStream 连接。

server端会为每个client生成唯一一个watch id，并记录每个client也就是watcher监听的key或者key range，通过recvLoop接收client请求，通过sendLoop发送请求，server端只负责收发请求和响应。

主要的实现都放在了watchalbStore层，watchalbStore会监听key的变化，然后通过syncWatchersLoop和syncVictimsLoop两个处理流程将key的更新变化包装成event，通过channel发送给gRPC server。

MVCC（Multiversion Concurrency Control）多版本并发控制机制

场景1:

这就是悲观锁

悲观锁：悲观得认为并发事务会冲突，所以要先拿锁，拿到锁的作修改操作

场景2

数据库：写回磁盘，A写好了。哎，B和C都是version 13，我咋写？算了，报错吧。。

就是乐观锁，默认不加锁，你尽管写，冲突我认怂！乐观锁其实不是锁，只是相对悲观锁来定义，适合读多写少。

乐观锁：乐观得认为数据不会冲突，但发生冲突时要能检测到。

场景3

这就是MVCC，在 MVCC 数据库中，你更新一个 key-value 数据的时候，它并不会直接覆盖原数据，而是 新增一个版本来存储新的数据，每个数据都有一个版本号 ，版本号是一个逻辑时钟，不会因为服务器时间的差异而受影响。

MVCC不等于乐观锁！

--rev 查的是main

在底层boltdb里，实际分布是这样的：

底层的key是revision，/奥特曼是用户key，“他很帅”就是用户value

删除

之前有delete动作，但是依然有版本记录。为什么？

删除这个动作，其实etcd是在blotdb里写了一条，“删除用户/奥特曼”

此时有个问题：用户说我的确删除了啊，真的不要了！请把空间还给我啊！

回收 compact（压缩）

etcdctl compact {version}

compact 需要一个版本号。这个版本号就是写事务递增的那个版本号，compact 12345，就是说把版本12345以前的 标记删除了的数据 释放掉，用户没删除的数据肯定不能回收。

如何压缩：

注意修改go.mod

Watch

服务发现要解决的也是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口，并且通过名字就可以查找和连接。

需要实现的功能；

discover.go

eBay payment

ebay kubernetes 控制面架构

问题