etcd

官方定义：

A highly-available key value store for shared configuration and service discovery.

它是一个键值存储仓库，并且可用于配置共享和服务发现

 

 

具有以下4个特点：

简单：基于HTTP+JSON的API让你用curl命令就可以轻松使用。

安全：可选SSL客户认证机制。

快速：每个实例每秒支持一千次写操作。

可信：使用Raft算法充分实现了分布式。

 

 

使用场景：

使用场景一：服务发现

服务发现（Service Discovery）要解决的是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接。

从本质上说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且通过名字就可以进行查找和连接。要解决服务发现的问题，需要有下面三大支柱，缺一不可。

1）一个强一致性、高可用的服务存储目录。基于Raft算法的etcd天生就是这样一个强一致性高可用的服务存储目录。

2）一种注册服务和监控服务健康状态的机制。用户可以在etcd中注册服务，并且对注册的服务设置key TTL，定时保持服务的心跳以达到监控健康状态的效果。

3）一种查找和连接服务的机制。通过在etcd指定的主题下注册的服务也能在对应的主题下查找到。为了确保连接，我们可以在每个服务机器上都部署一个proxy模式的etcd，这样就可以确保能访问etcd集群的服务都能互相连接。

 

 

使用场景二：消息发布与订阅（配置中心）

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

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

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

 

 

使用场景三：负载均衡（集群管理）

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

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

 

 

使用场景四：分布式锁

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

锁服务有两种使用方式，一是保持独占，二是控制时序。

1)保持独占，即所有试图获取锁的用户最终只有一个可以得到。etcd为此提供了一套实现分布式锁原子操作CAS（CompareAndSwap）的API。通过设置prevExist值，可以保证在多个节点同时创建某个目录时，只有一个成功，而该用户即可认为是获得了锁。

2)控制时序，即所有试图获取锁的用户都会进入等待队列，获得锁的顺序是全局唯一的，同时决定了队列执行顺序。etcd为此也提供了一套API（自动创建有序键），对一个目录建值时指定为POST动作，这样etcd会自动在目录下生成一个当前最大的值为键，存储这个新的值（客户端编号）。同时还可以使用API按顺序列出所有当前目录下的键值。此时这些键的值就是客户端的时序，而这些键中存储的值可以是代表客户端的编号。

 

使用场景五：分布式队列

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

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

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

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

 

使用场景六：集群监控与LEADER竞选

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

前面几个场景已经提到Watcher机制，当某个节点消失或有变动时，Watcher会第一时间发现并告知用户。

节点可以设置TTL key，比如每隔30s向etcd发送一次心跳使代表该节点仍然存活，否则说明节点消失。

这样就可以第一时间检测到各节点的健康状态，以完成集群的监控要求。

 

 

Etcd与Zookeeper的比较：

Zookeeper相较Etcd有如下缺点：

1）复杂。Zookeeper的部署维护复杂，管理员需要掌握一系列的知识和技能；而Paxos强一致性算法也是素来以复杂难懂而闻名于世；另外，Zookeeper的使用也比较复杂，需要安装客户端，官方只提供了java和C两种语言的接口。

2）Java编写。这里不是对Java有偏见，而是Java本身就偏向于重型应用，它会引入大量的依赖。而运维人员则普遍希望机器集群尽可能简单，维护起来也不易出错。

3）发展缓慢。Apache基金会项目特有的“Apache Way”在开源界饱受争议，其中一大原因就是由于基金会庞大的结构以及松散的管理导致项目发展缓慢。

而Etcd作为一个后起之秀，其优点也很明显：

1）简单。使用Go语言编写部署简单；使用HTTP作为接口使用简单；使用Raft算法保证强一致性让用户易于理解。

2）数据持久化。etcd默认数据一更新就进行持久化。

3）安全。etcd支持SSL客户端安全认证。

 

 

ETCD概念词汇表：

Raft：etcd所采用的保证分布式系统强一致性的算法。

Node：一个Raft状态机实例。

Member： 一个etcd实例。它管理着一个Node，并且可以为客户端请求提供服务。

Cluster：由多个Member构成可以协同工作的etcd集群。

Peer：对同一个etcd集群中另外一个Member的称呼。

Client： 向etcd集群发送HTTP请求的客户端。

WAL：预写式日志，etcd用于持久化存储的日志格式。

snapshot：etcd防止WAL文件过多而设置的快照，存储etcd数据状态。

Proxy：etcd的一种模式，为etcd集群提供反向代理服务。

Leader：Raft算法中通过竞选而产生的处理所有数据提交的节点。

Follower：竞选失败的节点作为Raft中的从属节点，为算法提供强一致性保证。

Candidate：当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始Leader竞选。

Term：某个节点成为Leader到下一次竞选开始的时间周期，称为一个Term。

Index：数据项编号。Raft中通过Term和Index来定位数据。