ETCD 简介

Jerry Lau

于 2024-05-08 14:15:02 发布

阅读量962

点赞数 30

分类专栏： ETCD 文章标签： etcd 数据库

本文链接：https://blog.csdn.net/Jerrylau213/article/details/138570321

版权

ETCD 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

ETCD 简介

1-etcd介绍

etcd 是 CoreOS 团队于 2013 年 6 月发起的开源项目，它的目标是构建一个高可用的分布式键值(key-value)数据库。具有以下特点：

简单：安装配置简单，而且提供了 HTTP API 进行交互，使用也很简单
键值对存储：将数据存储在分层组织的目录中，如同在标准文件系统中
监测变更：监测特定的键或目录以进行更改，并对值的更改做出反应
安全：支持 SSL 证书验证
快速：根据官方提供的 benchmark 数据，单实例支持每秒 2k+ 读操作
可靠：采用 raft 算法，实现分布式系统数据的可用性和一致性

etcd 采用 Go 语言编写，它具有出色的跨平台支持，很小的二进制文件和强大的社区。 etcd 机器之间的通信通过 Raft 算法处理。

etcd 是一个高度一致的分布式键值存储，它提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据。它可以优雅地处理网络分区期间的 leader 选举，以应对机器的故障，即使是在 leader 节点发生故障时。

从简单的 Web 应用程序到 Kubernetes 集群，任何复杂的应用程序都可以从 etcd 中读取数据或将数据写入 etcd。

2- 使用场景

etcd 比较多的应用场景是用于服务注册与发现，除此之外，也可以用于键值对存储，应用程序可以读取和写入 etcd 中的数据。

一个简单的用例是将数据库连接详细信息或功能标志存储在 etcd 中作为键值对。可以观察这些值，使我们的应用在更改时可以重新配置自己。高级用法是利用 etcd 的一致性保证来实施数据库 leader 选举或在一组 follower 之间执行分布式锁定。

2.1 键值对存储

A highly-available key value store for shared configuration and service discovery.
一个用于配置共享和服务发现的键值存储系统。

归根结底，etcd 是一个键值存储的组件，其他的应用都是基于其键值存储的功能展开。etcd 的存储有如下特点：

采用kv型数据存储，一般情况下比关系型数据库快。
支持动态存储(内存)以及静态存储(磁盘)。
分布式存储，可集成为多节点集群。
存储方式，采用类似目录结构。
- 只有叶子节点才能真正存储数据，相当于文件。
- 叶子节点的父节点一定是目录，目录不能存储数据。

2.2Etcd 数据结构与特性

Etcd 在其数据模型和组织结构上更接近于 ZooKeeper和对象存储，而不是 Redis。它使用层次化的键值对来存储数据，支持类似于文件系统路径的层次结构，能够很灵活地单 key 查询、按前缀查询、按范围查询。

Etcd 的核心数据结构

1.Key(键):Etcd 中的基本数据单元，类似于文件系统中的文件名。每个键都唯一标识一个值，并且可以包含子键，形成类似于路径的层次结构。

2.Value(值):与键关联的数据，可以是任意类型的数据，通常是字符串形式。只有 key、value，是不是比 Redis 好理解多了?我们可以将数据序列化后写入 value。

Etcd 有很多核心特性，其中，应用较多的特性是:

1.Lease(租约):用于对键值对进行 TTL 超时设置，即设置键值对的过期时间。当租约过期时，相关的键值对将被自动删除。

2.Watch(监听):可以监视特定键的变化，当键的值发生变化时，会触发相应的通知。

有了这些特性，我们就能够实现注册中心的服务提供者节点过期和监听了。
此外，Etcd 的一大优势就是能够保证数据的强一致性。
Etcd 如何保证数据一致性?

从表层来看，Etcd 支持事务操作，能够保证数据一致性。
从底层来看，Etcd 使用 Raft 一致性算法来保证数据的一致性,
Raft 是一种分布式一致性算法，它确保了分布式系统中的所有节点在任何时间点都能达成一致的数据视图。

具体来说，Raft 算法通过选举机制选举出一个领导者(Leader)节点，领导者负责接收客户端的写请求，并将写操作复制到其他节点上。当客户端发送写请求时，领导者首先将写操作写入自己的日志中，并将写操作的日志条目分发给其他节点，其他节点收到日志后也将其写入自己的日志中。一旦大多数节点(即半数以上的节点)都将该日志条目成功写入到自己的日志中，该日志条目就被视为已提交，领导者会向客户端发送成功响应。在领导者发送成功响应后该写操作就被视为已提交，从而保证了数据的一致性。

如果领导者节点宕机或失去联系，Raf 算法会在其他节点中选举出新的领导者，从而保证系统的可用性和一致性。新的领导者会继续接收客户端的写请求，并负责将写操作复制到其他节点上，从而保持数据的一致性。

上面这段不理解也没关系，我们可以使用官方提供的 Etcd Playground 来可视化操作 Etcd，便于学习。