云原生分布式键值存储服务-etcd初识

Posted 2021-04-03 唱起儿歌写代码

— 1 —

etcd的发展历史

Etcd最初是由CoreOS开发的，用于对集群管理系统中的OS升级以及配置文件的存储和分发进行分布式并发控制。因此，etcd已被设计为提供高可用性和高一致性的小型KVStore服务。

Etcd当前隶属于Cloud Native Computing Foundation（CNCF），并被大型互联网公司广泛使用，例如Amazon Web Services（AWS），Google，Microsoft和阿里巴巴。

CoreOS于2013年6月向GitHub提交了第一版的初始代码。

2014年6月，Kubernetes V0.4在社区中发布。Kubernetes是由Google开发并为社区做出贡献的容器管理平台。它从一开始就吸引了很多注意力，因为它整合了Google在容器调度和集群管理方面的多年经验。Kubernetes V0.4使用etcd V0.2作为核心实验元数据的存储服务。从那时起，etcd社区发展迅速。

2015年2月，etcd发布了第一个正式的稳定版本V2.0。在V2.0中，etcd重新设计了Raft共识算法，提供了一个简单的树数据视图，并支持每秒1000次以上的写入，可以满足当时大多数情况的要求。在etcd V2.0发布之后，经过不断的迭代和改进，其原始数据存储解决方案逐渐成为性能瓶颈。之后，etcd启动了V3的解决方案设计。

2017年1月，etcd发布了V3.1，这标志着etcd技术的成熟。etcd V3提供了一组新的API，这些API支持更有效的一致性读取方法，并提供了gRPC代理来提高etcd的读取性能。此外，V3解决方案包含许多GC优化，每秒支持超过10,000次写入。

2018年，超过30个CNCF项目将etcd用作核心数据存储。在2018年11月，etcd成为CNCF孵化项目。进入CNCF之后，etcd拥有400多个贡献小组，其中包括来自AWS，Google和阿里巴巴等八家公司的九个项目维护者。

2019年，谷歌和阿里巴巴联合创建了etcd V3.4，进一步提高了etcd的性能和稳定性，以应对超大型公司的苛刻场景。

— 2 —

架构和内部机制分析

整体架构

Etcd是一种分布式可靠的KVStore系统，用于将关键数据存储在分布式系统中。

一个etcd集群由三个或五个节点组成。多个节点通过raft共识算法相互协作。该算法选择一个主节点作为领导者，负责数据同步和分发。当领导者发生故障时，系统会自动选择另一个节点作为领导者，以再次完成数据同步。仅需选择一个节点即可读取和写入数据，而etcd可以完成内部状态和数据协作。

仲裁是etcd中的关键概念。它定义为（n + 1）/ 2，表示群集中超过一半的节点构成仲裁。在三节点集群中，只要有两个节点可用，etcd仍会运行。同样，在五节点集群中，只要有三个节点可用，etcd仍将运行。这是etcd群集高可用性的关键。

为了使etcd在某些节点发生故障后继续运行，必须解决复杂的分布式一致性问题。在etcd中，分布式共识算法由Raft共识算法实现。下面简要描述该算法。Raft共识算法仅在任何两个仲裁具有共享成员时才可以工作。也就是说，任何有效的仲裁必须包含一个共享成员，该成员包含集群中所有已确认和已提交的数据。基于此原理，为Raft共识算法设计了一种数据同步机制，用于在更换领导者后同步最后仲裁所提交的所有数据。这可确保在群集状态更改时保持数据一致性。

Etcd具有复杂的内部机制，但为客户提供了简单直接的API。如上图所示，您可以通过etcd客户端访问群集数据，或通过HTTP直接访问etcd，这与curl命令类似。etcd中的数据表达很简单。您可以将etcd的数据存储理解为存储键值数据的有序映射。etcd还提供了一种监视机制来为客户端订阅数据更改。监视机制实时获取etcd中的增量数据更新，以使数据与etcd同步。

API介绍

本节描述了etcd提供的五组API。

• 创建和删除：如上图所示，创建和删除操作很简单。只需一个键和一个值即可将数据写入群集，而只需要键即可删除数据。

• Get： etcd支持按指定键查询和按指定键范围查询。

• 监视： etcd提供了一种监视机制来实时订阅etcd中的增量数据更新。Watch允许您指定键或键前缀。

• 事务： etcd提供了一种简单的事务机制，可以在满足一组条件时执行某些操作，或者在不满足条件时执行其他操作。这类似于代码中使用的if ... else语句。etcd确保所有操作的原子性。

• 租约：租约API是分布式系统中的常见设计模式。

数据版本机制

要正确使用etcd API，必须知道相应的内部数据版本。

etcd使用术语来表示集群领导者的术语。当领导者更改时，期限值将增加1。当领导者发生故障，领导者的网络连接异常或集群停止并重新启动时，领导者也会更改。

修订版是全局数据的版本。当创建，修改或删除数据时，修订的值将增加1。特别是，修订始终会在集群中的所有领导者术语中全局增加。此功能可为集群中的任何更改提供唯一的修订。因此，您可以支持多版本并发控制（MVCC）或基于修订的数据监视。

etcd记录每个键值数据节点的三个版本：

• create_revision是创建时键值数据的修订版。

• mod_revision是对数据操作的修订。

• 计数器指定键值数据已被修改的次数。

下图显示了术语和修订版本。

在领导者任期内，所有修改操作的任期值均为2，而rev值每次均稳定增加1。重新启动集群后，所有修改操作的术语值都更改为3。在新领导者的术语期间，所有术语值均为3且保持不变，而rev值每次每次都继续增加1。在两位领导人任期内，转速值稳步上升。

MVCC和watch机制

本节描述如何使用etcd的多个版本来实现并发控制和数据订阅（watch）。

在etcd中，可以为同一key多次修改数据，并且每次数据修改都对应一个版本号。etcd记录每次修改的数据，这意味着一个key在etcd中具有多个历史版本。如果在查询数据时未指定版本，则etcd返回key的最新版本。etcd还支持按版本查询历史数据。

使用Watch订阅数据时，可以从任何历史时间或指定的修订版本创建观察者，以在客户端和etcd之间创建数据管道。etcd推送自指定修订版以来发生的所有数据更改。etcd提供的Watch机制立即通过数据管道将key的修改后的数据推送到客户端。

如下图所示，etcd的所有数据都存储在B +树（以灰色显示）中，并且B +树存储在磁盘上并以mmap模式映射到内存以便快速访问。灰色的B +树保留了修订版到值的映射关系，并支持按修订版查询数据。修订值稳定地增加1。因此，当您使用Watch订阅指定修订后的数据时，只需要订阅B +树的数据更改。

在etcd中维护了另一个B +树（蓝色），该树管理键到修订的映射。使用key查询数据时，客户端通过蓝色的蓝色B +树将key转换为修订版，然后通过灰色的B +树查询数据。

Etcd记录每个修改，这导致连续的数据增长，占用内存和磁盘空间，并影响B +树查询效率。etcd使用定期压缩机制来清理在一定时间之前创建的同一key的多个历史版本的数据。结果，灰色的B +树继续稳步增长，并留有一些缝隙。

事务

本节描述etcd的微型事务处理机制。etcd的事务机制很简单。可以将其视为if-else程序，并且if语句中可以提供多个操作，如下图所示。

If语句包含两个条件。如果Value（key1）的值大于bar的值，并且Version（key1）的值是2，请运行Then语句，将key2的数据修改为valueX并删除key3的数据。如果不满足任何条件，请将key2的数据更改为valueY。

Etcd确保整个交易操作的原子性。也就是说，If语句中所有比较条件的视图都是一致的。它还确保了多个操作的原子性，这意味着将执行Then语句中的所有操作。

使用etcd的事务处理机制，可以确保在多个竞争中的数据读写一致性。例如，前面提到的Kubernetes项目使用etcd的事务处理机制来确保在多个Kubernetes API服务器上一致地修改相同的数据。

租赁

租赁通常用于表示分布式系统中的分布式租赁。通常，需要使用租赁机制来检测节点在分布式系统中是否处于活动状态。

如上图所示，创建了一个10秒的租约。如果在创建租约后不执行任何操作，则租约会在10秒后自动过期。将key1和key2绑定到租约，以便etcd在租约到期时自动清除key1和key2。

如果要保留租约，则需要定期调用KeeyAlive方法来刷新它。例如，要检查分布式系统中的某个进程是否处于活动状态，可以在该进程中创建租约并定期在该进程中调用KeepAlive方法。如果过程正常，则保留此节点上的租约。如果该过程崩溃，则租约自动过期。

但是，如果大量key需要支持类似的租用机制，并且必须单独刷新每个key的租用，这会对etcd造成很大压力。因此，etcd允许将多个key（例如，具有相似到期时间的key）绑定到同一租约，这可以大大减少租约刷新的开销并提高etcd性能。

— 3 —

典型场景

元数据存储

Kubernetes将其状态数据存储在etcd中以实现高可用性。这样，Kubernetes无需对分布式系统执行复杂的状态处理，从而极大地简化了其系统架构。

服务发现（命名服务）

在分布式系统中，需要多个后端（可能有数百个进程）来提供一组对等服务，例如搜索服务和推荐服务。

为了降低此类后端服务的运行和维护成本（其中有故障的节点被立即替换），后端进程由群集管理系统（如Kubernetes）安排。这样，当用户或上游服务调用此过程时，需要使用服务发现机制来路由服务。通过使用etcd可以有效地实现此服务发现：

• 如果服务进程崩溃，API网关可以使用etcd租用机制删除其流量，以防止呼叫超时。

在这种体系结构中，服务状态数据由etcd接管，并且API网关是无状态的，可以扩展以服务更多的客户。得益于etcd的出色性能，支持了数以万计的后端进程，从而使该体系结构可以为大型企业提供服务。

分布式协调：领导人选举

分布式系统通常采用master + workers设计模型。通常，工作节点提供各种资源，例如CPU，内存，磁盘和网络，而主节点协调这些节点以提供外部服务，例如分布式存储和分布式计算。典型的Hadoop分布式文件系统（HDFS）和Hadoop分布式计算服务都采用类似的设计模型。这样的设计模型有一个普遍的问题：主节点的可用性。当主节点发生故障时，群集中的所有服务将停止运行，并且无法为用户提供服务。

典型的解决方案是启动多个主节点。主节点包含控制逻辑，并且多个节点之间的状态同步非常复杂。最典型的方法是选择一个主节点作为提供服务的领导者，并使另一个主节点处于等待状态。

分布式协调：分布式系统并发控制

在分布式系统中，执行某些任务（例如升级操作系统，升级操作系统上的软件或执行计算任务）时，需要控制任务并发性，以防止后端服务出现瓶颈并确保业务稳定性。如果任务缺乏实现协调的主节点，则可以使用etcd来执行此操作。

在这种模式下，您可以使用etcd实现分布式信号量，并使用etcd租约机制自动删除有故障的节点。如果进程的运行周期很长，则可以将一些生成的状态数据存储到etcd。这样，如果进程失败，则可以从etcd恢复某些执行状态，而不必再次完成整个计算逻辑。这提高了整体任务的效率。

摘要

让我们总结一下我们在本文中学到的知识：

• 第一部分描述了etcd的出现以及它演变过程中的几个重要时刻。

• 第二部分介绍etcd的体系结构和基本API，以及基本的etcd数据操作以及etcd的工作方式。

• 第三部分介绍了三种典型的etcd场景以及这些场景中的分布式系统的设计思想。

更多历史文章可以戳：

文末

我是Allen, 和你分享自己成长路上的点点滴滴

包括技术文章和日常思考。