Etcd 学习安装教程

最新推荐文章于 2025-04-03 07:45:44 发布

码小呆~

最新推荐文章于 2025-04-03 07:45:44 发布

阅读量1.6k

点赞数 1

分类专栏： etcd 文章标签： kubernetes docker etcd

本文链接：https://blog.youkuaiyun.com/qq_41971087/article/details/126255445

版权

etcd 专栏收录该内容

1 篇文章

订阅专栏

简介:

etcd是一种高度一致的分布式键值存储，它提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据。它在网络分区期间优雅地处理领导者选举，并且可以容忍机器故障，即使在领导者节点中也是如此

在这里插入图片描述

快速开始

安装

https://etcd.io/docs/v3.5/install/ 安装地址

安装 etcd 的最简单方法是使用预构建的二进制文件：

安装地址: https://github.com/etcd-io/etcd/releases/ 选择对应的版本

下载成功后,解压存档文件。这将生成一个包含二进制文件的目录

然后进入对应的文件中启动服务端命令:

etcd

在这里插入图片描述

看到如下图,表示服务端启动成功.

源码安装构建:

需要go1.6版本以上环境.使用git命令从远程产库克隆到本地,使用 Golan 工具构建

git clone -b v3.5.0 https://github.com/etcd-io/etcd.git

进入到 etcd 目录中之心 ./build.sh 命令执行完成会生成一个二进制文件在bin目录下.在bin目录里面就有启动etcd 服务端和客户端文件

官方安装: https://etcd.io/docs/v3.5/install/

接下来,启动客户端操作 etcd 注意 etcd 是一个键值存储数据库.

新增一个值:

etcdctl put name “hello, word”

获取设置的值

etcdctl get name

删除对应的值

etcdctl delete name

etcd 与其他键值存储

分布式系统使用 etcd 作为一致的键值存储，用于配置管理、服务发现和协调分布式工作。许多组织使用 etcd 来实现生产系统，例如容器调度程序、服务发现服务和分布式数据存储。使用 etcd 的常见分布式模式包括领导者选举、分布式锁和监控机器活跃度。

ZooKeeper

ZooKeeper 解决了与 etcd 相同的问题：分布式系统协调和元数据存储。然而，etcd 拥有来自 ZooKeeper 设计和实施的工程和运营经验的后见之明。从 Zookeeper 中吸取的教训无疑为 etcd 的设计提供了参考，帮助它支持像 Kubernetes 这样的大规模系统。etcd 对 Zookeeper 的改进包括：

动态集群成员重新配置
高负载下稳定读/写
多版本并发控制数据模型
可靠的密钥监控，不会默默地丢弃事件
租赁原语将连接与会话分离
用于安全分布式共享锁的 API

此外，etcd 支持多种开箱即用的语言和框架。Zookeeper 有自己的自定义 Jute RPC 协议，它完全是 Zookeeper 独有的，并且限制了它支持的语言绑定，而 etcd 的客户端协议是从gRPC构建的，gRPC是一个流行的 RPC 框架，具有 go、C++、Java 等的语言绑定。同样，gRPC 可以通过 HTTP 序列化为 JSON，因此即使是通用命令行实用程序curl也可以与之对话。由于系统可以从多种选择中进行选择，因此它们使用原生工具构建在 etcd 之上，而不是使用单一固定技术集围绕 etcd 构建。

在考虑功能、支持和稳定性时，计划使用 Zookeeper 进行一致的键值存储的新应用程序最好选择 etcd。

Consul

Consul 是一个端到端的服务发现框架。它提供内置的健康检查、故障检测和 DNS 服务。此外，Consul 使用 RESTful HTTP API 公开了一个键值存储。在 Consul 1.0中，存储系统在键值操作方面的扩展性不如 etcd 或 Zookeeper 等其他系统；需要数百万个密钥的系统将遭受高延迟和内存压力。缺少键值 API，最明显的是多版本键、条件事务和可靠的流式监视。

etcd 和 Consul 解决不同的问题。如果要寻找分布式一致的键值存储，etcd 是比 Consul 更好的选择。如果要寻找端到端的集群服务发现，etcd 将没有足够的特性；选择 Kubernetes、Consul 或 SmartStack。

NewSQL (Cloud Spanner, CockroachDB, TiDB)

etcd 和 NewSQL 数据库（例如Cockroach、TiDB、Google Spanner）都提供了强大的数据一致性保证和高可用性。然而，显着不同的系统设计参数导致显着不同的客户端 API 和性能特征。

NewSQL 数据库旨在跨数据中心横向扩展。这些系统通常将数据分区到多个一致的复制组（分片），可能是遥远的，以 TB 及以上的顺序存储数据集。这种缩放使它们成为分布式协调的不良候选者，因为它们等待时钟的延迟很长，并且期望使用大部分本地化的依赖图进行更新。数据被组织成表，包括具有比 etcd 更丰富的语义的 SQL 样式查询工具，但代价是处理、计划和优化查询的额外复杂性。

简而言之，选择 etcd 来存储元数据或协调分布式应用程序。如果存储超过几 GB 的数据或需要完整的 SQL 查询，请选择 NewSQL 数据库。

使用 etcd 获取元数据

etcd 复制单个一致复制组中的所有数据。对于以一致的顺序存储多达几 GB 的数据，这是最有效的方法。集群状态的每次修改（可能会更改多个键）都被分配一个全局唯一 ID，称为 etcd 中的修订，来自单调递增的计数器，用于推理排序。由于只有一个复制组，因此修改请求只需要通过 raft 协议提交即可。通过将共识限制在一个复制组中，etcd 通过简单的协议获得分布式一致性，同时实现低延迟和高吞吐量。

etcd 背后的复制无法水平扩展，因为它缺乏数据分片。相比之下，NewSQL 数据库通常将数据分片到多个一致的复制组中，以 TB 及以上的顺序存储数据集。但是，要为每个修改分配一个全局唯一且递增的 ID，每个请求都必须通过复制组之间的额外协调协议。这个额外的协调步骤可能会在全局 ID 上发生冲突，从而迫使有序请求重试。结果是一种更复杂的方法，其性能通常比严格排序的 etcd 更差。

如果应用程序主要考虑元数据或元数据排序，例如协调进程，请选择 etcd。如果应用程序需要跨多个数据中心的大型数据存储并且不严重依赖强大的全局排序属性，请选择 NewSQL 数据库。

使用 etcd 进行分布式协调

etcd 具有开箱即用的事件监视、租用、选举和分布式共享锁等分布式协调原语（注意，在分布式共享锁的情况下，用户需要注意其不明显的属性。详细说明如下）。这些原语由 etcd 开发人员维护和支持；将这些原语留给外部库可以推卸开发基础分布式软件的责任，从而使系统不完整。NewSQL 数据库通常期望这些分布式协调原语由第三方编写。同样，ZooKeeper 有一个独立的协调配方库。提供本机锁定 API 的 Consul 甚至道歉说它是“不是防弹的方法”。

理论上，可以在任何提供强一致性的存储系统上构建这些原语。但是，算法往往很微妙。开发一种看似有效的锁定算法很容易，但由于雷鸣般的羊群和时间偏差而突然中断。此外，etcd 支持的其他原语，例如事务内存依赖于 etcd 的 MVCC 数据模型；简单的强一致性是不够的。

对于分布式协调，选择 etcd 可以帮助避免操作难题并节省工程工作量。