etcd功能（长篇图解etcd核心应用场景及编码实战）

大家好啊
  
  
  
  
  
  
，我是字母哥  
  
  
  
  
  
 ，今天写一篇关于etcd的文章
 


 


 


 


 


 


 ，其实网上也有很多关于etcd的介绍
 
 
 
 
 
 
，我就简明扼要   
   
   
   
   
   
 ，总结提炼
 

 

 

 

 

 

 ，期望大家通过这一篇文章掌握etcd的核心知识以及编码技能！

本文首先用大白话给大家介绍一下etcd是什么？这部分内容网上已经有很多了             。 etcd有哪些应用场景？这些应用场景的核心原理是什么？ 最后不能光动嘴不动手
  
 
  
 
  
 
  
 
  
 
  
 
 。先搭建一个etcd单机版

 

 

 

 

 

 
，再使用java的客户端操作etcd数据












。

本文旨在帮助大家理解etcd             ，从宏观角度俯瞰etcd全局
 
 

 
 

 
 

 
 

 
 

 
 

 ，掌握etcd的基本操作技能 
  
  
  
  
  
  。后续我还会写一个系列的文章












，将每一种应用场景代码化                   ，期待大家关注我和我的公众号：字母哥杂谈
  
  
  
  
  
  
 。后续计划章节内容如下：

《搭建高可用etcd集群》 《基于etcd实现分布式锁（java代码实现）》 《基于etcd实现配置变更通知（java代码实现）》 《基于etcd实现服务注册与发现（java代码实现）》 《基于etcd实现分布式系统节点leader选举（java代码实现）》

一
  
  
  
  
  
  
、白话etcd与zookeeper

用过linux的朋友请举手 
 
 
 
 
 
 
 
 
 
 
 
 ，好的



















，我看见了！ 在 linux 中所有自动安装的系统软件配置文件都存储在一个名为/etc的目录中
 


 


 


 


 


 


。“d             ”表示distributed分布式            ，etcd为分布式模型  
 
  
 
  
 
  
 
  
 
  
 
  ，所以etcd的核心应用场景是：分布式系统的配置信息存储 
 
 
 
 
 
 。

网上很多文章上来第一句话照搬英文官网：etcd 是一个高度一致的分布式键值存储系统
   
   
   
   
   
   
 。很多朋友看完就问了












，这玩意和redis有啥区别？ 笔者要说
  
  
  
  
  
  
，真的不要这么比  
  
  
  
  
  
 ，etcd从名字上就已经告诉你了
 


 


 


 


 


 


 ，它是存储配置信息(元数据)的
 

 

 

 

 

 

。和redis在架构应用上就不在一个层面
 
 
 
 
 
 
，它对标的产品应该是zookeeper 

 

 

 

 

 

 。虽然zookeeper在很多java的分布式系统的应用中比较广泛   
   
   
   
   
   
 ，但是etcd作为后起之秀
 

 

 

 

 

 

 ，乘kubernetes的东风

 

 

 

 

 

 
，大有超越zookeeper的趋势             。

zookeeper是使用java写的             ， etcd是使用go语言编写的

 
 

 
 

 
 

 
 

 
 

 
 

。zookeeper使用了TCP协议
 
 

 
 

 
 

 
 

 
 

 
 

 ，其交互报文规则是完全自定义的












，如果不使用zookeeper提供的SDK就无法操作数据











。而etcd使用的是google的gRPC协议                   ，普适性更好一些                    。 zookeeper对于一次请求 
 
 
 
 
 
 
 
 
 
 
 
 ，开启一个socket进行监听
 
 
 
 
 
 
 
 
 
 
 
 
。而etcd的监听管道channel可以反复被利用



















，从IO性能到系统资源的利用的角度            ，etcd无疑是更优秀的


















。 zookeeper使用zab协议保证集群节点配置信息的一致性  
 
  
 
  
 
  
 
  
 
  
 
  ，etcd使用raft协议             。期望详细了解raft协议的












，点击《raft协议中文介绍》
  
 
  
 
  
 
  
 
  
 
  
 
 。

大部分功能和zookeeper都是一样的
  
  
  
  
  
  
，目前看java程序员用zookeeper的更多  
  
  
  
  
  
 ，其他程序员用etcd更多












。都是基于习惯
 


 


 


 


 


 


 ，但笔者推荐etcd 
  
  
  
  
  
  。

二  
  
  
  
  
  
 、etcd的4个核心机制

etcd以key-value的形式进行数据的存储. 配合下面的这四种机制,使得etcd的应用场景更加的广泛.

Prefix 机制：即前缀机制
 
 
 
 
 
 
，也称目录机制   
   
   
   
   
   
 ，客户端向etcd放入2个键值对配置, 假如一个key是“/test/key1" , 另一个key是"/test/key2". 则通过前缀"/test"查询etcd
 

 

 

 

 

 

 ，返回一个列表包含key为“/test/key1" 和"/test/key2"的键值对数据； Watch 机制：即监听机制

 

 

 

 

 

 
，watch机制针对某个key进行监听,也支持针对前缀进行范围监听. 当被监听的key 或前缀范围发生变化的时候             ，客户端会收到变更通知； Lease 机制：即租约机制（TTL
 
 

 
 

 
 

 
 

 
 

 
 

 ，Time To Live）












，支持为key-value增加一个存活时间,超过这个时间key-value将过期被删除. 支持解约(删除key-value),续约(增加TTL时间)等操作. Revision 机制：每个key带有一个 全局唯一的Revision 号                   ，每一次事务加1 
 
 
 
 
 
 
 
 
 
 
 
 ，它是全局唯一的



















，所以通过Revision可以判定数据写操作的顺序,对于实现分布式锁和队列非常有帮助.

三
 


 


 


 


 


 


 、Leader选举与客户端交互

使用etcd的时候            ，为了保证高可用  
 
  
 
  
 
  
 
  
 
  
 
  ，通常采用集群的部署方式
  
  
  
  
  
  
 。部署奇数个节点












，通常建议是3个或5个
  
  
  
  
  
  
，因为etcd集群之间需要通过网络交互保证配置信息的一致性


 


 


 


 


 


 


。分布式多节点保证了高可用  
  
  
  
  
  
 ，但是节点太多了也不好
 


 


 


 


 


 


 ，越多的节点网络消耗越大 
 
 
 
 
 
 。至于为什么是奇数个？这就涉及到Leader选举的问题
 
 
 
 
 
 
，奇数个方便投票出结果
   
   
   
   
   
   
 。

etcd使用raft算法保证集群内各个节点之间数据一致性
 

 

 

 

 

 

。raft算法将集群内的节点分为Leader, Follower, Candidate(候选人)这三个角色 

 

 

 

 

 

 。

集群初始化的时候   
   
   
   
   
   
 ，每个节点都是Follower角色             。通过raft算法选举投票
 

 

 

 

 

 

 ，选出一个节点作为Leader

 
 

 
 

 
 

 
 

 
 

 
 

。 Leader作为主节点

 

 

 

 

 

 
，与其他节点维持心跳             ，并同步数据至其他节点











。 当Follower一段时间内没有收到leader的心跳
 
 

 
 

 
 

 
 

 
 

 
 

 ，就会将自己角色改为Candidate候选者












，并发起一次新的选举                   ，选举新的Leader                    。

客户端在操作etcd集群数据的时候：

读操作：客户端可以访问任意节点进行数据的读操作 写操作：客户端访问任意节点进行写操作 
 
 
 
 
 
 
 
 
 
 
 
 ，如果该节点是Follower



















，则将请求转发给Leader
 
 
 
 
 
 
 
 
 
 
 
 
。由Leader负责数据的写操作(增删改)            ，将数据持久化  
 
  
 
  
 
  
 
  
 
  
 
  ，并向Follower发送同步数据的消息


















。

四
 
 
 
 
 
 
、etcd的应用场景

4.1. kubernetes大脑

目前












，etcd的最典型的应用场景就是作为Kubernetes 集群的大脑             。

如果把kubernetes比作一个大饭店
  
  
  
  
  
  
，那么etcd就是这个饭店的进销存+客户关系管理系统
  
 
  
 
  
 
  
 
  
 
  
 
 。

kubernetes作为容器编排服务  
  
  
  
  
  
 ，将面向客户提供的各种服务进行合理的资源分配
 


 


 


 


 


 


 ，服务编排












。 不可避免地
 
 
 
 
 
 
，有一些kubernetes集群的配置和状态数据   
   
   
   
   
   
 ，例如 pod 的数量   
   
   
   
   
   
 、它们的状态
 

 

 

 

 

 

 、命名空间等 
  
  
  
  
  
  。需要有一个统一的记录

 

 

 

 

 

 
、管理的地方
 

 

 

 

 

 

 ，它就是etcd
  
  
  
  
  
  
 。

最重要的是：etcd具备watch监听的功能

 

 

 

 

 

 
，一旦某个配置或者某个状态发生变更             ，集群内所有的服务全都可以通过watch监听机制实时获取到消息
 
 

 
 

 
 

 
 

 
 

 
 

 ，进而做出进一步的响应
 


 


 


 


 


 


。 几乎etcd的所有应用场景












，都是基于watch监听机制产生的                   ，包括我们后面为大家介绍的服务注册发现和订阅通知 
 
 
 
 
 
 。

4.2. 服务注册与发现

其实kubernetes也利用etcd实现服务注册发现机制 
 
 
 
 
 
 
 
 
 
 
 
 ，但是上面的那张图不太好说明



















，我新画了两张图说明etcd在实现服务注册发现机制中的作用


   
   
   
   
   
   
 。

所谓的服务注册实现原理就是：服务在启动的时候            ，向etcd写入一条配置数据  
 
  
 
  
 
  
 
  
 
  
 
  ，该条配置数据说明自己的服务名称












，服务ip地址
  
  
  
  
  
  
，服务端口等信息
 

 

 

 

 

 

。

所谓的服务发现实现原理举例：服务C的某个实例希望访问服务A  
  
  
  
  
  
 ，服务C向etcd询问服务A的访问地址
 


 


 


 


 


 


 ，etcd响应结果：服务A有三个实例
 
 
 
 
 
 
，地址列表如：xxx.xxx.xxx.xxx:端口             、yyy.yyy.yyy.yyy:端口   
   
   
   
   
   
 ，zzz.zzz.zzz.zzz:端口 

 

 

 

 

 

 。服务C不需要访问三个实例
 

 

 

 

 

 

 ，访问其中一个就可以得到结果

 

 

 

 

 

 
，所以它按照自己的负载均衡算法选了一个             ，这个就叫做：客户端负载均衡             。

4.3. 健康检查与状态变更通知

衔接上文：服务C下一次访问服务A的时候
 
 

 
 

 
 

 
 

 
 

 
 

 ，还需要访问etcd么？答案是不需要












，它访问过一次之后                   ，就会自己维护一个服务A访问地址的列表 
 
 
 
 
 
 
 
 
 
 
 
 ，除非这个列表发生变化



















，否则是不会再次去询问etcd的

 
 

 
 

 
 

 
 

 
 

 
 

。

那么一个服务怎么知道另一个服务的列表发生变化呢？比如：服务A的实例注册状态发生变化











。可能是由于某种原因挂掉了            ，可能是OOM或者是网络问题等                    。

服务在注册到etcd之后  
 
  
 
  
 
  
 
  
 
  
 
  ，会保存一个关于该服务的注册配置信息












，该注册配置信息由一个TTL
  
  
  
  
  
  
，etcd同时会与该服务维持心跳
 
 
 
 
 
 
 
 
 
 
 
 
。一旦超过TTL时间  
  
  
  
  
  
 ，无法得到服务的心跳响应
 


 


 


 


 


 


 ，etcd就认为该节点的健康状态出现了问题
 
 
 
 
 
 
，就会将该节点下线（注册配置信息删除）


















。 服务在注册到etcd之后   
   
   
   
   
   
 ，会保持对etcd状态数据变更的监听
 

 

 

 

 

 

 ，一旦获取监听结果：服务A的实例状态发生变更

 

 

 

 

 

 
，该服务就会从etcd重新拉取服务A的注册列表             。

4.4.分布式锁

跨进程跨系统的多线程操作公共资源             ，发生多线程竞争
 
 

 
 

 
 

 
 

 
 

 
 

 ，为了避免线程不安全












，需要使用分布式锁
  
 
  
 
  
 
  
 
  
 
  
 
 。如果多线程在单个进程内发生资源竞争                   ，就是用Lock就可以了 
 
 
 
 
 
 
 
 
 
 
 
 ，不需要分布式锁












。比如：你在mysql库里面有一个用户余额数据



















，多个进程内的线程同时更改这个值            ，可能发生并发的数据覆盖 
  
  
  
  
  
  。为了避免这样的问题  
 
  
 
  
 
  
 
  
 
  
 
  ，多个进程排排队












，A先来
  
  
  
  
  
  
，A释放了锁B再来  
  
  
  
  
  
 ，B释放了锁C再来
  
  
  
  
  
  
 。

举例：上图的3个client代表三个服务
 


 


 


 


 


 


 ，都要操作某个资源数据
 


 


 


 


 


 


。

在尝试调用加锁API的时候
 
 
 
 
 
 
，client1获取到的revision=1,它优先获得加锁的资格 
 
 
 
 
 
 。加锁就是加一个带有revision的配置记录
   
   
   
   
   
   
 。其他的所有的服务   
   
   
   
   
   
 ，都通过watch机制监听锁的释放
 

 

 

 

 

 

。 client在尝试调用加锁API的时候
 

 

 

 

 

 

 ，被分配了revision 

 

 

 

 

 

 。并且按照revision进行了排序

 

 

 

 

 

 
，监听距离自己revision差值最小             ，而且小于自己的Revision
 
 

 
 

 
 

 
 

 
 

 
 

 ，不会产生惊群效应             。

4.5.实现消息队列(纯扯淡)

我觉得使用etcd实现消息队列












，是一种纯扯淡的做法

 
 

 
 

 
 

 
 

 
 

 
 

。如果大家有什么异议                   ，欢迎留言！

不是说做不了 
 
 
 
 
 
 
 
 
 
 
 
 ，确实写个demo是可以的











。往etcd里面放数据



















，再通过watch机制进行监听            ，这不就是一个典型的消息队列么？扯淡！如果我只为了实现消息数据的发布订阅  
 
  
 
  
 
  
 
  
 
  
 
  ，其实有很多办法












，我还用搭一个etcd集群？Spring的Event机制
  
  
  
  
  
  
，java的响应式编程  
  
  
  
  
  
 ，哪怕自己搞一个BlockQueue呢
 


 


 


 


 


 


 ，是不是都能实现消息的发布订阅                    。

我们之所以使用kafka
 
 

 
 

 
 

 
 

 
 

 
 

 、RocketMQ这样的消息队列
 
 
 
 
 
 
，肯定是因为我们的异步数据达到一定的规模了
 
 
 
 
 
 
 
 
 
 
 
 
。达到规模的异步消息数据传递根本就不是etcd的应用场景   
   
   
   
   
   
 ，正如本文开头所述：别忘了它叫做etc阿就d
 

 

 

 

 

 

 ，它就是一个为分布式系统存储配置信息的

 

 

 

 

 

 
，不是消息中间件


















。

五












、etcd安装

本文为大家安装一个可以用于实验环境的etcd单机版,我们可以用它进行实验,后续我还会写文章介绍etcd集群的安装方式.

下载etcd的安装包,访问github-etcd,我使用的是linux操作系统64位,所以下载的安装包是:etcd-v3.5.4-linux-amd64.tar.gz .如果网络条件不允许,可以搜索"etcd国内下载加速",选择合适的下载安装包进行安装即可.

首先将安装包解压,解压之后cd进入安装目录,将etcd和etcdctl两个命令copy到/usr/local/bin/目录下面.

tar zxvf etcd-v3.5.4-linux-amd64.tar.gz; cd etcd-v3.5.4-linux-amd64; cp etcd etcdctl /usr/local/bin/;

通过etcd --version命令查看etcd的版本,同时可以验证安装结果.如果不想敲全路径,可以把/usr/local/bin目录加入系统的PATH环境变量.

/usr/local/bin/etcd --version

启动etcd,这里的listen-client-urls和advertise-client-urls配置的作用是允许远程连接,0.0.0.0表示监听当前服务器的所有ip, 监听端口是2379. 假如你的服务器有多块网卡,多个固定ip,你想指定etcd服务在某一个ip上提供服务,就可以用这个ip替换0.0.0.0

/usr/local/bin/etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379

etcd启动之后, 可以通过etcdctl命令向etcd中添加配置,如下所示使用put命令添加一个key=/dir1,value=aaa的键值对数据.可以使用get命令获取该配置信息.

# /usr/local/bin/etcdctl put /dir1 aaa OK # /usr/local/bin/etcdctl get /dir1 /dir1 aaa

六                   、jetcd的编码实现配置管理

下面为大家介绍通过java API的方式操作etcd的数据,首先通过maven的坐标引入jetcd.我使用的版本相对比较旧,最新的版本已经是0.7.8,不过我在使用的时候出现了与netty版本不一致的情况,报错:找不到netty相关的一些类.所以我就回退到0.3.0版本,使用方式上都是一样的.

<dependency> <groupId>io.etcd</groupId> <artifactId>jetcd-core</artifactId> <version>0.3.0</version> </dependency>

下面的代码是使用jetcd操作etcd的配置数据,实现了数据的写操作,读操作,删除操作.详细用法看代码吧.下面的代码是Junit 5的单元测试用例的写法.

import io.etcd.jetcd.ByteSequence; import io.etcd.jetcd.Client; import io.etcd.jetcd.KV; import io.etcd.jetcd.kv.GetResponse; import io.etcd.jetcd.kv.PutResponse; import org.junit.jupiter.api.*; import java.nio.charset.StandardCharsets; import java.util.concurrent.CompletableFuture; import java.util.concurrent.ExecutionException; import static junit.framework.TestCase.assertNotNull; //这个注解配合函数的Order注解,决定测试用例函数的执行顺序 @TestMethodOrder(MethodOrderer.OrderAnnotation.class) public class EtcdTest { private static Client etcdClient; @BeforeAll static void init(){ etcdClient = Client.builder() //这里的etcd服务列表可以写多个,用逗号分隔 .endpoints("http://192.168.161.3:2379".split(",")) .build(); } @Test @Order(1) @DisplayName("etcd写配置操作") void putKV() throws ExecutionException, InterruptedException { KV kv = etcdClient.getKVClient(); ByteSequence key = ByteSequence.from("key-str", StandardCharsets.UTF_8); ByteSequence value = ByteSequence.from("value-str", StandardCharsets.UTF_8); //put key-value配置信息 CompletableFuture<PutResponse> putRsp = kv.put(key,value); assertNotNull(putRsp.get().getHeader()); } @Test @Order(2) @DisplayName("etcd读配置操作") void getKV() throws ExecutionException, InterruptedException { KV kv = etcdClient.getKVClient(); ByteSequence key = ByteSequence.from("key-str", StandardCharsets.UTF_8); //通过key获取值 CompletableFuture<GetResponse> getRsp = kv.get(key); String getBackValue = getRsp.get().getKvs().get(0).getValue().toString(StandardCharsets.UTF_8); System.out.println("从etcd通过key获取value值为：" + getBackValue); } @Test @Order(3) @DisplayName("删除配置操作") void deleteKV() { KV kv = etcdClient.getKVClient(); ByteSequence key = ByteSequence.from("key-str", StandardCharsets.UTF_8); //通过key删除数据 kv.delete(key); } }

上面的代码只介绍了etcd的最基本的key-value操作,其实etcd客户端还提供了很多的API,这些都将在我后续的文章中分布式锁,服务注册发现,配置变更监听,分布式系统Leader选举的内容中为大家介绍.

//租约 Lease lease=etcdClient.getLeaseClient(); //监听 Watch watch =etcdClient.getWatchClient(); //选举 Election election =etcdClient.getElectionClient(); //锁 Lock lock=etcdClient.getLockClient();

欢迎关注我的公告号：字母哥杂谈             ，回复003赠送作者专栏《docker修炼之道》的PDF版本
 
 

 
 

 
 

 
 

 
 

 
 

 ，30余篇精品docker文章             。字母哥博客：zimug.com