爱数博客

Etcd简介

• Etcd是采用Go语言编写的一个分布式key-value 存储，它通过Raft协议进行leader选举和数 据备份，对外提供高可用的数据存储，能有效应对网络问题和机器故障带来的数据丢失问 题。同时它还可以提供服务发现、分布式锁、分布式数据队列、分布式通知和协调、集群选 举等功能。
• 在kubernetes集群中，Etcd用于保存集群所有的网络配置和对象的状态信息。
• Etcd主要解决的是分布式系统中数据一致性的问题，而分布式系统中的数据分为控制数据和 应用数据，Etcd处理的数据类型为控制数据，对于很少量的应用数据也可以进行处理。

Etcd主要功能

• 基本的key-value存储
• 监听机制
• key的过期及续约机制，用于监控和服务发现
• 原子CAS和CAD，用于分布式锁和leader选举

Etcd特点

• 完全复制：集群中的每个节点都可以使用完整的存档
• 高可用性：Etcd可用于避免硬件的单点故障或网络问题
• 一致性：每次读取都会返回跨多主机的最新写入
• 简单：包括一个定义良好、面向用户的API（gRPC）
• 安全：实现了带有可选的客户端证书身份验证的自动化TLS
• 可靠：使用Raft算法实现了强一致、高可用的服务存储目录
• 监测变更：监测特定的键或目录以进行更改，并对值的变更做出反应
• 快速：根据官方提供的benchmark数据，单实例支持每秒2K+读操作

Etcd集群中的术语

Etcd架构及组件

Etcd主要分为四个部分【http server、store、raft、WAL】 HTTP Server： 用于处理用户发送的API请求以及其他etcd节点的同步与心跳信息请求

Store: 用于处理 etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现。

Raft： Raft 强一致性算法的具体实现，是 etcd 的核心。

WAL：Write Ahead Log（预写式日志/日志先行），是 etcd 的数据存储方式，也是一种实现事务日志的标准方法。etcd通过 WAL 进行持久化存储，所有的数据提交前都会事先记录日志。Snapshot 是为了防止数据过多而进行的状态快照；Entry 表示存储的具体日志内容。

Etcd应用场景

Etcd应用场景很多，主要的有以下六种：

• 服务发现
• 消息发布与订阅（配置中心）
• 负载均衡（集群管理）
• 分布式锁、分布式队列
• 集群监控
• LEADER竞选

服务发现

服务发现要解决的也是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口，并且通过名字就可以查找和连接。

要解决服务发现的问题，需要具备以下三点： 1.一个强一致性、高可用的服务存储目录。基于 Raft 算法的 Etcd 天生就是这样一个强一致性高可用的服务存储目录; 2.一种注册服务和监控服务健康状态的机制。用户可以在 Etcd 中注册服务，并且对注册的服务设置key TTL，定时保持服务的心跳以达到监控健康状态的效果; 3.一种查找和连接服务的机制。通过在 Etcd 指定的主题下注册的服务也能在对应的主题下查找到。为了确保连接，我们可以在每个服务机器上都部署一个 Proxy 模式的 Etcd，这样就可以确保能访问 Etcd 集群的服务都能互相连接。 例如随着 Docker 容器的流行，多种微服务共同协作，构成一个相对功能强大的架构的案例越来越多。透明化的动态添加这些服务的需求也日益强烈。通过服务发现机制，在 Etcd 中注册某个服务名字的目录，在该目录下存储可用的服务节点的 IP。在使用服务的过程中，只要从服务目录下查找可用的服务节点去使用即可。

消息发布与订阅（配置中心）

在分布式系统中，最为适用的组件间通信方式是消息发布与订阅机制。

具体而言，即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦相关主题有消息发布，就会实时通知订阅者。

通过这种方式可以实现分布式系统配置的集中式管理与实时动态更新。

负载均衡（集群管理）

利用Etcd维护一个负载均衡节点表。Etcd可以监控一个集群中多个节点的状态，当有一个请求发过来后，可以轮询式地把请求转发给存活着的多个节点。

类似KafkaMQ，通过Zookeeper来维护生产者和消费者的负载均衡。同样也可以用Etcd来做Zookeeper的工作

分布式锁

因为Etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。

锁服务有以下两种使用方式：

• 保持独占，即所有试图获取锁的用户最终只有一个可以得到。Etcd为此提供了一套实现分布式锁原子操作CAS（CompareAndSwap）的API。通过设置prevExist值，可以保证在多个节点同时创建某个目录时，只有一个成功，而该用户即可认为是获得了锁；
• 控制时序，即所有试图获取锁的用户都会进入等待队列，获得锁的顺序是全局唯一的，同时决定了队列执行顺序。Etcd为此也提供了一套API（自动创建有序键），对一个目录建值时指定为POST动作，这样Etcd会自动在目录下生成一个当前最大的值为键，存储这个新的值（客户端编号）。同时还可以使用API按顺序列出所有当前目录下的键值。此时这些键的值就是客户端的时序，而这些键中存储的值可以是代表客户端的编号。

分布式队列

在保证队列达到某个条件时再统一按顺序执行。这种方法的实现可以在/queue这个目录中另外建立一个/queue/condition节点。

condition可以表示队列大小。比如一个大的任务需要很多小任务就绪的情况下才能执行，每次有一个小任务就绪，就给这个condition数字加1，直到达到大任务规定的数字，再开始执行队列里的一系列小任务，最终执行大任务。

condition可以表示某个任务在不在队列。这个任务可以是所有排序任务的首个执行程序，也可以是拓扑结构中没有依赖的点。通常，必须执行这些任务后才能执行队列中的其他任务。

condition还可以表示其它的一类开始执行任务的通知。可以由控制程序指定，当condition出现变化时，开始执行队列任务。

集群监控与LEADER竞选

通过Etcd来进行监控实现起来非常简单并且实时性强，用到了以下两点特性：

• Watcher机制，当某个节点消失或有变动时，Watcher会第一时间发现并告知用户；
• 节点可以设置TTL key，比如每隔30s向Etcd发送一次心跳使代表该节点仍然存活，否则说明节点消失。 这样就可以第一时间检测到各节点的健康状态，以完成集群的监控要求。

参考资料

1. https://Etcd.io/