小楼一夜听春雨，深巷明朝卖杏花

etcd作为一个分布式键值存储系统，其性能主要由延迟和吞吐量两个因素决定。延迟指完成操作所需时间，而吞吐量则是在特定时间内完成的操作数量。在并发客户端请求下，etcd的平均延迟会随吞吐量增加而增加。在标准云环境中，三成员etcd集群在轻负载下可实现低于1毫秒的请求完成时间，重负载下每秒可处理超过30000个请求。etcd使用Raft算法确保数据一致性和复制，其性能受网络和磁盘IO延迟限制。为提高吞吐量，etcd采用批量处理策略。此外，etcd的性能还受到MVCC存储引擎、快照、压缩和gRPC系统的影响。通过

总结：etcd恢复还是比较快的，脚本做了一些工作，比如，停服务，因此，恢复完要先启动etcd，然后在其它节点启动etcd，最后启动kube-apiserver服务，顺序不要搞错了哦。可将备份脚本放入计划任务，实现自动备份哈，这里我就不演示啦，然后恢复的时候根据需要恢复任意天的etcd。再次强调，集群恢复是所有节点都恢复，不能只恢复一个节点，那样会劈叉的，根据每个节点的etcd配置文件修改脚本。

本文介绍了ETCD集群在日常运维中常见问题的处理方法。ETCD是一个高可用的分布式Key/Value存储系统，使用Raft算法保持集群一致性。文章详细描述了三种常见问题的解决步骤：1）单个节点宕机的恢复，包括查看状态、摘除异常节点、重新部署和加入集群；2）超过半数节点宕机的恢复，涉及备份数据恢复、启动服务和检查状态；3）数据库空间超限的恢复，包括备份数据、获取reversion、compact、defrag和删除报警。文章还建议定时备份和压缩数据，并增加集群监控以确保服务稳定运行。

etcd集群在正常服务时，成员分为Leader和Follower两种状态，确保数据强一致性。所有数据从Leader流向Follower，Follower数据必须与Leader一致，否则会被覆盖。Leader处理所有写操作，并需等待超过半数的成员确认写操作成功，而Follower可直接响应读操作。etcd采用预写式日志（WAL）记录所有数据库事务，确保数据持久化。此外，etcd定期生成数据库快照（snapshot），记录某一时间点的数据状态，以减少日志体积并辅助数据恢复。快照与WAL日志结合，可快速同步故障实

本文介绍了处理ETCD集群故障的步骤，包括查看集群状态、剔除故障节点、重新添加故障节点以及备份恢复集群的方法。首先，通过etcdctl命令查看集群状态，识别主节点和故障节点。接着，使用member remove命令剔除故障节点，并通过member list验证剔除是否成功。随后，详细说明了重新添加故障节点的步骤，包括清空旧数据、修改配置文件、拷贝证书以及执行member add命令。最后，文章还提供了备份恢复集群的流程，强调停止相关服务、恢复数据后重启服务的操作顺序。通过这些步骤，可以有效维护ETCD集群的

内存中的存储除了顺序化的记录下所有用户对节点数据变更的记录外，还会对用户数据进行索引、建堆等方便查询的操作。历史版本越多，存储空间越大，性能越差，直到etcd到达空间配额限制的时候，etcd的写入将会被禁止变为只读，影响线上服务，因此这些历史版本需要进行压缩。由于ETCD数据存储多版本数据，随着写入的主键增加历史版本需要定时清理，默认的历史数据是不会清理的，数据达到2G就不能写入，只是对给定版本之前的历史版本进行清理，清理后数据的历史版本将不能访问，但不会影响现有最新数据的访问。

etcd就是个分布式非关系型数据库，3 个节点组成的集群，可以容忍 1 个节点故障。生产环境中，不推荐使用单个节点的 etcd 集群。etcd 支持存储多个版本的数据，允许查询指定 key 历史版本的数据。etcd 为了控制数据总空间，会周期性的清理数据的历史版本。etcd 不支持修改旧版本的数据。etcd 中，数据以二进制的方式存储在磁盘中。#/bin/bash。

读写 QPS 为 etcd 100 连接，1000 客户端 下的 etcd benchmark 结果。

对于非结构化的数据存储系统来说，LIST 操作通常都是非常重量级的，不仅占用大量的 磁盘 IO、网络带宽和 CPU，而且会影响同时间段的其他请求（尤其是响应延迟要求极高的 选主请求），是集群稳定性的一大杀手。例如，对于 Ceph 对象存储来说，每个 LIST bucket 请求都需要去多个磁盘中捞出这个 bucket 的全部数据；不仅自身很慢，还影响了同一时间段内的其他普通读写请求，因为 IO 是共享的，导致响应延迟上升乃至超时。...

etcd 监控可以帮助您更好地利用 etcd，特别用于是定位性能问题。KubeSphere 监控系统提供了高度图形化和响应性强的仪表板，用于显示原生数据。频繁变更 Leader 将显著影响 etcd 性能，同时这还表明 Leader 可能由于网络连接问题或 etcd 集群负载过高而不稳定。如果成员没有 Leader，则成员完全不可用。如果集群中的所有成员都没有任何 Leader，则整个集群完全不可用。etcd 的底层数据库大小，单位为 MiB。图表中显示的是 etcd 的每个成员数据库的平均大小。.....

但是，如果存在多个候选人并获得相同数目的选票，则现有的选举任期将在没有领导人的情况下结束 ，而新任期将以新的随机选举计时器开始。如果候选人从集群中的大多数节点获得投票，那么它将成为新的领导者。每个节点维护的选举计时器的超时时间不同，因此第一个候选人通常会成为新的领导者。etcd 是高可用的键值对的分布式安全存储系统，用于持久化存储集群中所有的资源对象，例如集群中的Node。如果领导者不再响应，成员处时，如果它不是领导者，那么它会将此请求转移给领导者。的工作机制，每个写请求需要集群中的每个成员做仲裁，....

增强版backup方案当谈论etcd备份的时候，来看看现有工具是什么。那是etcdctl snapshot save，它的好处是一次性的将整个etcd dump出来，效率比较高，但是它有它的问题，比如它锁住硬盘空间导致磁盘空间暴涨，其实还有其他方法，比如watch k8s，etcd event，这样可以把集群所有的细节变动都拉下来，对于etcd来说我们是关心所有etcd写入的event，从这个层面就可以将集群的所有变更都记录下来。那么就可以snapshot加上一些事件驱动，去关注事件流，将这些日志存下来再回

谈到生产系统etcd高可用集群一般有几类，第一类为kubeadm搭建的K8s集群，这种的etcd我们通常通过kubelet扫描本地目录，这个本地目录我们可以将etcd的pod放进去，kubelet扫描到etcd的pod清单，然后它就会去启动etcd的pod，这个就是K8s控制平面怎么拉起自己的etcd。有些时候我们可能使用另外的方式去搭建etcd集群，etcd-operator是基于k8s crd完成etcd的集群配置。 operator本身其实就是crd和controller的组合，所以etcd oper

在生产线上面，虽然etcd使用起来很简单，只需要put get watch这几条命令就可以将整个数据让它流转起来，在生产线上面etcd还有很多很多的问题，包括第一安全如何保证，第二高可用的etcd集群如何构建，第三数据如何备份，这些都和整个集群安全性息息相关。 ETCD_NAME：节点名称，集群中唯一参数有几类，第一类就是核心参数，最基本的参数，和成员相关，每个etcd成员都有它自己的名字，默认是default，所以去建Etcd集群的时候，什么参数都不加的时候，这个Etcd成员叫做default。

etcd在存储数据的时候主要分为了两个部分，第一部分叫做kvstore，这个kvstore是存储在内存当中的，这个是in memory的kvstore，任何数据库都需要做索引，所以etcd就是通过这种方式在内存当中构建了索引，这个索引的目标是来做快速的查找。另外后端会有真正落盘的数据库，etcd默认使用blotdb去实现的，blotdb是Google开源的key value数据库，当你任何数据要去存储到etcd store的时候，它同时会去存索引和落盘，通过blotdb去落盘。（最终的数据持久化是基于blo

raft本身是一个指导性原则，etcd严格遵循这个指导性原则，做了go语言版本的实现。etcd很多特性其实就是在学习raft协议的特性。 选举方法上面可以看到选举严格遵循了raft协议。选举方法 当接 Leader 收到客户端的日志（事务请求）后先把该日志追加到本地的 Log 中，然后通过heartbeat 把该Entry同步给其他 Follower，Follower 接收到日志后记录日志然后向 Leader 发送ACK，当Leader收到大多数（n/2+1）Follower 的ACK信息后将该日志设置为

etcd是raft协议的一个实现。如果你使用过zookeeper这样的分布式键值对，你应该知道有个叫paxos的协议，paxos协议是挺复杂的，raft协议是paxos协议的简化版本。大多数同意原则：一群人怎么达成原则，往往是通过投票，当多数人同意的时候就按照多数人投票的结果去执行。在服务端一般是多个成员组成了一个集群，针对客户端任何的变更，这个变更首先会发到服务端，服务端在处理变更请求的时候，它会有一个一致性的模块，这个一致性模块会将这个变更请求发给其他所有的peer，请求经过一致性模块之后，请求就会转发

etcd是 CoreOS基于Raft开发的分布式key-value 存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）。在分布式系统中，如何管理节点间的状态一直是一个难题，etcd 像是专门为集群环境的服务发现和注册而设计，它提供了数据TTL失效、数据改变监视、多值、目录监听、分布式锁原子操作等功能，可以方便的跟踪并管理集群节点的状态。 为什么要做分布式存储呢？就是数据安全的要求，如果是单节点的键值对存储很简单就能够实现，但是如果单节点出现了故障，那么数据就会丢失，对于这种场景你要保证

我们在日常工作中经常会遇到各种服务调优，同样，对于 etcd 集群来说，也需要对其进行调优，使其处于最佳的状态。这一讲我将通过分析 etcd 的架构，结合其核心部分对 etcd 集群进行优化。etcd 整体分析在对 etcd 进行调优之前，我们先来看看 etcd 集群的架构图，如下图所示：上图是一个简化了的 etcd 集群。完整的 etcd 的架构中包括 API 通信层、Raft 算法层、业务逻辑层（包括鉴权、租约等）和 Storage 存储层。我在图中只标识出了 Raft 层.

常用命令#查看集群member情况etcdctl --endpoints=${exist-advertise-peer-urls} member list#动态扩容etcdctl --endpoints=${exist-advertise-peer-urls} member add infra4 --peer-urls=${new-advertise-peer-urls}#运行时缩容etcdctl --endpoints=${exist-advertise-peer-urls.

安装好 etcd 后，我们将开始体验如何使用 etcd。这一讲，我将会基于 etcd 自带的客户端工具——etcdctl 来演示 etcd 常用的一些操作，帮助你快速入手 etcd。etcdctl 客户端etcdctl 是一个命令行客户端，便于我们进行服务测试或手动修改数据库内容，我们刚开始熟悉 etcd 功能时可以通过 etdctl 客户端熟悉相关操作。etcdctl 在两个不同的 etcd 版本（v2 和 v3）下的功能和使用方式也完全不同。一般通过如下方式来指定使用 etcd 的版本：.

Etcd v3版本是主流版本，2版本也有很多在用，etcdctl对v3 v2两个版本都支持，在备份的时候需要指定默认的话是v2版本，所以在备份v3版本需要声明一下。之前备份是找了其中一个节点去备份的，找任意节点去备份都行，但是建议找两个节点去备份，如果其中一个节点挂了，那么备份就会失败了。现在需要恢复了，对所有的etcd节点都做暂停。这三个节点的信息是相互同步的，要去备份只需要备份一个节点就行了，连接其中一个节点备份就行。注意在每个节点进行恢复，一个是恢复数据，一个是重塑身份。拷贝到其他节点，再去恢复。

etcd 单机安装部署etcd 的安装有多种方式，这里我以 CentOS 7 为例，可以通过yum install etcd进行安装。然而通过系统工具安装的 etcd 版本比较滞后，如果需要安装最新版本的 etcd ，我们可以通过二进制包、源码编译以及 Docker 容器安装。二进制安装目前最新的 etcd API 版本为 v3.4，我们基于 3.4.4 版本进行实践，API 版本与最新版保持一致，在 CentOS 7 上面使用如下脚本进行安装：ETCD_VER=v3.4.4GITHUB

单Master架构图：Etcd集群证书准备Etcd 是一个分布式键值存储系统，Kubernetes使用Etcd进行数据存储，所以先准备一个Etcd数据库，为解决Etcd单点故障，应采用集群方式部署，这里使用3台组建集群，可容忍1台机器故障，当然，你也可以使用5台组建集群，可容忍2台机器故障。节点名称 IP etcd-1 192.168.31.71 etcd-2 192.168.31.72 etcd-3 192.168.31.73 注：为了节省机.

近几年，云原生越来越火，你在各种大会或博客的标题里都可以见到“云原生”的字样，我们这次要学习的 etcd 也是云原生架构中重要的基础组件，因为etcd 项目是 Kubernetes 内部的一大关键组件，目前有很多项目都依赖 etcd 进行可靠的分布式数据存储。etcd 是 CoreOS 团队于 2013 年 6 月发起的开源项目，2018 年底正式加入云原生计算基金会（CNCF）。etcd 组件基于 Go 语言实现，目前最新版本为 V3.4.9。为什么需要 etcd在具体讲解 etcd 前.

2013 年，有一个叫 CoreOS 的创业团队，他们构建了一个产品，Container Linux，它是一个开源、轻量级的操作系统，侧重自动化、快速部署应用服务，并要求应用程序都在容器中运行，同时提供集群化的管理方案，用户管理服务就像单机一样方便。他们希望在重启任意一节点的时候，用户的服务不会因此而宕机，导致无法提供服务，因此需要运行多个副本。但是多个副本之间如何协调，如何避免变更的时候所有副本不可用呢？为了解决这个问题，CoreOS 团队需要一个协调服务来存储服务配置信息、提供分布式锁等能力。怎

本文将主要分享以下三方面的内容：第一部分，会为大家介绍 etcd 项目发展的整个历程，从诞生至今 etcd 经历的那些重要的时刻； 第二部分，会为大家介绍 etcd 的技术架构以及其内部的实现机制，通过对技术架构和内部机制的学习，帮助我们正确地使用 etcd； 第三部分，结合具体的使用场景，为大家介绍在分布式系统中 etcd 所扮演的角色。一、etcd 项目的发展历程etcd 诞生于 CoreOS 公司，它最初是用于解决集群管理系统中 OS 升级的分布式并发控制以及配置文件的存储与分发等.