什么是etcd ？
etcd 是一个开源的分布式键值存储，用于保存和管理分布式系统保持运行所需的关键信息。最值得注意的是，它管理流行的容器编排平台 Kubernetes 的配置数据、状态数据和元数据。
与所有分布式工作负载一样，容器化工作负载具有复杂的管理要求，这些要求会随着工作负载的扩展而变得更加复杂。Kubernetes通过协调所有集群（可以在多个位置的多台计算机上运行）等任务，例如配置、部署、服务发现、负载均衡、作业调度和运行状况监控，从而简化了管理这些工作负载的过程。
但为了实现这种协调，Kubernetes 需要一个数据存储，该数据存储在任何给定时间点提供关于系统状态（其所有集群和 Pod 以及其中的应用程序实例）的单一、一致的真实来源。etcd 是用于创建和维护此真实版本的数据存储。
为什么选择 etcd？
作为保持分布式工作负载运行的数据主干并非易事。但 etcd 是为这项任务而构建的，从头开始设计，具有以下特性：
-
完全复制：etcd 集群中的每个节点都可以访问完整的数据存储。
-
高可用性：etcd 被设计为没有单点故障，并且可以优雅地容忍硬件故障和网络分区。
-
可靠一致： 每个数据“读取”都会返回所有集群中的最新数据“写入”。
-
快速：etcd 的基准测试为每秒 10,000 次写入。
-
安全: etcd 支持自动传输层安全性 （TLS） 和可选的安全套接字层 （SSL） 客户端证书身份验证。由于 etcd 存储了重要且高度敏感的配置数据，因此管理员应在部署中实施基于角色的访问控制，并确保与 etcd 交互的团队成员被限制在执行其工作所需的最低特权访问级别。
-
简单： 任何应用程序，从简单的 Web 应用程序到高度复杂的容器编排引擎（如 Kubernetes），都可以使用标准的 HTTP/JSON 工具在 etcd 中读取或写入数据。
Raft 共识算法
etcd 建立在 Raft 共识算法之上，以确保集群中所有节点的数据存储一致性——对于容错分布式系统来说，这是一个桌面赌注。
Raft 通过一个选_定的领导_节点来实现这种一致性，该领导节点管理集群中其他节点（称为_追随者_）的复制。领导者接受来自客户端的请求，然后将其转发给追随者节点。一旦领导者确定_大多数_跟随节点已将每个新请求存储为日志条目，它就会将该条目应用于其本地状态机，并将该执行的结果（“写入”）返回给客户端。如果跟随者崩溃或网络数据包丢失，领导者将重试，直到所有追随者一致地存储所有日志条目。
如果跟随节点在指定的时间间隔内未能收到来自领导者的消息，则举行选举以选择新的领导者。追随者声明自己是_候选人_，其他追随者根据其可用性投票给它或任何其他节点。一旦选出新的领导者，它就会开始管理复制，并且该过程会重复进行。此过程使所有 etcd 节点能够维护数据存储的高可用性、一致复制的副本。
etcd 和 Kubernetes
etcd 包含在核心 Kubernetes 组件中，用作创建正常运行、容错的 Kubernetes 集群的主键值存储。Kubernetes API 服务器将每个集群的状态数据存储在 etcd 中。Kubernetes 使用 etcd 的“监视”功能来监控这些数据，并在发生更改时重新配置自身。“watch”函数存储表示集群实际和理想状态的值，并且可以在它们发散时启动响应。
etcd 与 ZooKeeper 与 Consul
还开发了其他数据库来管理跨分布式应用程序集群之间的坐标信息。最常与 etcd 进行比较的两个是 ZooKeeper 和 Consul。
ZooKeeper
ZooKeeper 最初是为了协调 Apache Hadoop 集群中的配置数据和元数据而创建的。Apache Hadoop 是一个开源框架或应用程序集合，用于在商用硬件集群上存储和处理大量数据。ZooKeeper 比 etcd 更古老，使用 ZooKeeper 的经验教训影响了 etcd 的设计。
因此，etcd 具有 ZooKeeper 所没有的一些重要功能。例如，与 ZooKeeper 不同，etcd 可以执行以下操作：
-
允许动态重新配置群集成员身份。
-
在高负载下执行读/写操作时保持稳定。
-
维护多版本并发控制数据模型。
-
提供可靠的密钥监控，在不发出通知的情况下永远不会丢弃事件。
-
使用将连接与会话分离的并发基元。
-
支持多种语言和框架（ZooKeeper 有自己的自定义 Jute RPC 协议，支持有限的语言绑定）。
Consul
Consul 是一个用于分布式系统的服务网络解决方案，其功能介于 etcd 和 Kubernetes 的 Istio 服务网格之间。与 etcd 一样，Consul 包含基于 Raft 算法的分布式键值存储，并支持 HTTP/JSON 应用程序编程接口 （API）。两者都提供动态集群成员身份配置，但 Consul 对配置数据的多个并发版本的控制不那么强，并且它可靠工作的最大数据库大小较小。
etcd 与 Redis
与 etcd 一样，Redis 是一个开源工具，但它们的基本功能不同。
Redis 是一种内存数据存储，可以用作数据库、缓存或消息代理。与 etcd 相比，Redis 支持更广泛的数据类型和结构，并且具有更快的读/写性能。
但 etcd 具有卓越的容错能力、更强的故障转移和持续的数据可用性能力，最重要的是，etcd 将所有存储的数据持久化到磁盘上，从根本上牺牲了速度来获得更高的可靠性和保证的一致性。由于这些原因，Redis 更适合用作分布式内存缓存系统，而不是存储和分布式系统配置信息。
Redis 对于用户会话数据可能并不理想，因为需要快速响应时间，并且可以容忍某些数据丢失或不一致。另一方面，Etcd 通过在解析之前跨多个节点执行 fsync 来优先考虑一致性，从而实现高持久性，但由于数据存储在磁盘上的文件中，性能较低。
为什么要使用 etcd？可以使用redis实现配置管理/服务发现吗？
Redis 是一种高性能数据存储系统，它利用内存，但缺乏持久性。在服务器发生故障时，可以轻松完成数据丢失。另一方面，Etcd 的数据存储在磁盘上的文件中，并在多个节点之间进行 fsync 以确保一致性，使其具有高度持久性，但性能不高。
对于 kubernetes，使用 etcd 进行集群状态和配置是一个合理的选择，但对于用户会话数据来说，这并不是最佳选择。Redis 通常在应用程序中用于此目的，因为它提供快速响应时间以及承受一定程度的数据丢失或不一致的能力。
Redis 与 etcdv3 的性能差异，Etcd 的原因应该比 Redis 慢得多：Etcd 可能使用 SSD，但 Redis 仍然是内存中的数据库，因此应该具有更高的性能。Etcd 使用共识 （Raft） 提供强一致性，应该比 Redis 慢。由于 Redis 不能保证一致性。Redis 分布式系统 etcd 分布式缓存。
使用 etcd 作为主存储/数据库是否可以？
Kubernetes 依靠 etcd（一种确保高可用性的键值存储）来持久存储对象信息，例如部署、Pod 和服务详细信息。
Etcd 的访问控制仅限于主节点的 API，从而阻止了集群中除主节点之外的节点对 etcd 存储的任何访问。
与 Redis 不同，Redis 可以缓存在RAM中，也可以持久化在磁盘中，etcd无法存储在内存中，只能持久化在磁盘存储。
Etcd 旨在专门容纳 Kubernetes 对象，并且缺乏对各种数据类型的支持。相反，像 Redis 这样的键值存储在数据类型适应方面提供了更大的灵活性。
虽然 etcd 确保了高可用性，但它不能提供有效的查询和索引。另一方面，所有 NoSQL 键值存储都旨在优先考虑快速搜索和查询。
Etcd 是一个分布式键值存储，保证了强一致性。它为分布式系统或计算机组需要访问的数据提供了可靠的存储解决方案。它可以在网络分区期间处理领导选举情况，而不会出现任何问题，甚至可以承受机器故障，包括领导节点中的故障。
虽然很明显 etcd 不能替代 NoSQL 数据库，通过上面的内容我们很容易看到 etcd 并不能代替传统数据库。
