一、etcd的官方定义:
A highly-available key value store for shared configuration and service discovery.
中文:用于配置共享和服务发现的高可用键值存储仓库。
etcd 是由Go 语言编写的分布式、高可用的一致性键值存储系统。基于Raft协议,通过复制日志文件的 方式来保证数据的强一致性。
etcd架构设计特点:
- etcd支持RESTful风格的HTTP+JSON的API;
- etcd v3增加了对gRPC的支持,同时提供rest gateway进行转化;
- 使用Go编写,跨平台,部署维护简单;
- Raft算法保证强一致性,Raft算法容易理解。
- 支持TLS客户端安全认证
- 单实例支持每秒一千次以上的写操作(v2),极限写性能可达10K+Qps(v3)
- 可靠,使用Raft算法充分保证了分布式系统数据的强一致性。
etcd(server)大致可分为:网络层(HTTPS server)、Raft模块、复制状态机、存储模块。
- 网络层:提供网络数据读写功能,监听服务端口,完成集群节点之间数据通信,手法客户端数据。
- raft模块:Raft强一致性算法的具体实现。
- 存储模块:涉及KV存储、WAL文件、Snapshot管理等,用于处理etcd支持的各类功能的事务,包括数据索引、节点状态变更、监控与反馈、事件处理与执行等。是etcd对用户提供的大多数API功能的具体实现。
- 复制状态机:这是一个抽象模块,状态机的数据维护在内存中,定期持久化到磁盘,每次写请求都会持久化到WAL文件,并根据写请求的内容修改状态机数据。除了在内存中存有所有数据的状态以及节点的索引之外,etcd还通过WAL进行持久化存储。基于WAL的存储系统其特点就是所有的数据在提交之前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照。
ETCD集群各节点通过网络来传递数据:
- Leader 向Follwer发送心跳包,Follwer向Leader回复消息。
- Leader 向Follwer发送日志追加信息。
- Leader 向Follwer发送Snapshot数据。
- Candidate节点发起选举,向其他节点发起投票请求。
- Follwer将收到的写操作转发给Leader。
etcd数据通道:
- Stream类型通道:用于处理数据量较少的消息,如心跳、日志追加消息等。点到点之间维护1个HTTP长连接,交替向链接中写入数据和读取数。每个Stream类型通道关联2个goroutine。
- Pipline类型通道:用于处理数据量较大的消息,如Snapshot。点到点之间维护通过HTTP短链接传输数据,用完即关闭。Pipline类型通道还可以并发发出多个消息,它维护着一组goroutine,每一个goroutine都可向对端发出POST请求(携带数据),收到回复后。链接关闭。
Pipline类型通道也可以传输小数据量的消息,当且仅当Stream类型链接不可用时。
etcd架构:
- 网络层与raft模块之间的交互:etcd通过Raft模块中抽象的RaftNode拥有一个消息盒子,RaftNode将各种类型的消息放入消息盒子中,由专门的goroutine将消息写入channel(go中的channel),而管道的另一端连接在网络层的不同类型的传输通道上,同样。也有专门的goroutine在等待(select)消息的到达。而网络层收到的消息,也是通过管道传给RaftNode。网络层与Raft模块直接通过go语言中的channel来完成数据通信。
- etcd与客户端的交互:etcd server在启动之初会监听服务端口,待服务端口收到客户端请求后,解析消息体,通过管道创Raft模块。客户端与所有的etcdserver都是通过客户端的端口使用HTTP通信。etcdserver的客户端端口主要原来提供对外服务。
- etcd server 直接的交互:etcd server 之间通过peer端口使用HTTP进行通信。etcdserver的peer端口主要用来协调Raft的相关消息,包括各种提议的协商。
二、etcd的典型应用场景:
1、服务注册与发现
本质上,服务发现主要是为了了解集群中是否有进程在监听UDP或TCP端口,并且通过名字就可以进行查找和链接。
2、消息发布和订阅
- etcd管理应用配置信息更新
- 分布式日志收集系统
- 系统中心需要动态自动获取与干预修改信息的请求内容
3、负载均衡
- etcd本身分布式架构存储的信息支持负载均衡
- 利用etcd维护一个负载均衡节点表
4、分布式通知与协调
- 通过etcd进行低耦合的liveness probe
- 通过etcd完成系统调度
- 通过etcd完成工作汇报
5、分布式锁
- 保持独占:etcd提供了一套实现分布式锁原子操作CAS(CompareAndSwap)的API。通过设置prevExist值,可以保证在多个节点上同时创建某个目录时,只有一个节点能够成功,而成功的那个即可获得分布式锁。
- 控制时序:试图获得锁的所有用户都会进入等待队列,获得锁的顺序是全局唯一的,同时还能决定队列的执行顺序。etcd提供了一条API(自动创建有序键),他会将一个目录的键值指定为POST动作,这样,etcd就会在目录下生成一个当前最大的值作为键,并存储这个新的值。同时还可以使用API按顺序列出所有目录下的键值。此时,这些键的值就是客户端的时序。这些键中存储的值则代表客户端的编号。
6、分布式队列
分布式队列的常规用法与分布式锁的控制时序类似,即通过创建一个先进先出的队列来保证顺序。
7、集群监控与leader选举
1、Watcher机制,当某个节点消失或发送变动时,Watcher会第一时间发现并告知用户。、
2、节点可以设置TTL key,比如每隔30S向etcd发送一次心跳信号,以此代表该节点依然存活,否则就说明节点已经消失了。
这样就可以第一时间检测到各节点的健康状态。以完成集群的监控要求。
另外,使用分布式锁,还可完成leader竞选。碎玉一些需要长时间进行CPU计算或者使用I/O的操作,只需要由竞选出的leader计算或者处理一次,再把结果复制给其他的Follwer即可,从而避免重复劳动,节省计算资源。
Leader应用的经典场景是在搜索系统中建立全量索引。如果各个机器分别进行索引的建立,那么将难以保证索引的一致性。通过etcd的CAS机制竞选leader,再由leader进行索引计算,最后将计算结果分发到其他节点即可。
三、etcd的优势
- etcd更加稳定可靠,专注于分布式一致性KV存储
- 在服务注册与发现上,etcd使用节点租约(Lease),并支持多Group(多key)
- etcd支持稳定的watch
- etcd支持MVCC(多版本并发控制)
- etcd支持更大规模的数据,支持存储百万到千万级别的key
- 相比ZooKeeper,etcd性能更好。v3版本可以做到每秒说万次的写操作和数十万次的读操作。