深入浅出之etcd

系列文章目录

浅谈分布式系统与一致性协议（一）
浅谈分布式系统与一致性协议（二）
浅谈分布式系统与一致性协议（三）
深入浅出之etcd
深入浅出之etcd(二)
etcd版本之v3
etcd之安全性阐述
etcd的多版本并发控制

---

分布式系统的难点在于“部分失败”。部分失败指信息在网络的两个节点之间传送出现了故障，发送者不知道接收者是否收到了这个信息，并且导致这种故障的原因很多，接收者也可能在发生网络错误之前收到了信息，也可能没收到。

现在的键值数据库基本都是分布式的，Zookeeper是其中久负盛名的一个，它有很成熟，丰富的特性，但它有自己的缺点，具体如下：

• 复杂：ZooKeeper部署维护比较复杂，管理员必须掌握一系列知识，Zookeeper使用的Pzxos强一致性算法不易于理解
• Zookeeper仅提供Java和C两种接口，另外，它对资源的占用比较高

etcd简介

etcd是一个Go语言编写的分布式，高可用的一致性键值存储系统，用于提供可靠的分布式键值存储，配置共享，服务发现等功能。etcd可以用于存储关键数据和实现分布式调度，在现代化的集群运行中起到了关键作用。etcd以一致和容错的方式存储数据。分布式系统可以使用etcd实现一致性键值存储，配置管理，服务管理，服务发现和分布式系统的协同等功能。etcd的常用使用场景为：服务发现，分布式锁，分布式数据队列，分布式通知与协调，主备选举等。

etcd是基于Raft算法的，通过复制日志文件的方式保证数据的强一致性（了解Raft算法可见 分布式系统与一致性协议）。当客户端应用写一个key时，首先会存储到etcd的leader上，然后通过Raft算法复制到集群的所有成员上，以此维护各个节点的状态的一致性与实现可靠性。虽然etcd是一个强一致性的系统，但是也支持非Leader的读取数据的操作，写操作仍然需要Leader的支持，所以当发生网络分区时，写操作仍可能失败。

etcd具有一定的容错能力，假设集群中共有n个节点，即便集群中有（n-1）/2个节点故障，剩下的（n+1）/2个节点也能达成一致，使操作成功。因此，它能够有效的应对网络分区和机器故障带来的数据丢失问题

etcd默认数据一更新就持久化，数据持久化存储使用了WAL格式（write aheadb log，预写式日志）。WAL记录了数据变化的全过程，在etcd中所有的数据在提交之前都先写入WAL；etcd的Snapshot（快照）文件则存储了某一时刻etcd的所有数据，默认设置为每10000条记录做一次快照，经过快照之后的WAL文件即被删除。

etcd架构简介

etcd提供了数据TTL失效，数据改变监视，多值，目录，分布式锁原子操作等功能，可以方便的跟踪和管理集群节点的状态。etcd（server)大体上分为网络层（http server，Raft模块，复制状态机和存储模块。etcd架构图如下：

网络层：提供网络数据读写功能，监听服务端口，完成集群节点之间数据通信，收发客户端数据

Raft模块：Raft强一致性算法的具体实现。
存储模块：设计KV存储，WAL文件，Snapshot管理等，用于处理etcd支持的各类功能的事务，包括数据索引，节点状态变更，监控与反馈，事件处理与执行等，是etcd对用户提供的大多数API功能的具体实现
复制状态机：这是一个抽象模块，状态机的数据维护在内存中，定期持久化到磁盘，每次写请求都会持久化到WAL文件，并根据写请求的内容修改状态机数据。除了在内存中存有所有数据的状态以及节点的索引外，etcd还通过WAL进行持久化存储。基于WAL的存储系统其特点是所有的数据在提交之前都会先记录日志。Snapshot是为了防止数据过多而进行的状态快照。

通常一个请求发送过来，首先经由HTTP Server转发给存储模块进行具体的事务处理，然后涉及的节点状态的更新，则交给Raft模块进行日志记录，同步给其他的etcd节点，只有当半数以上的节点确认了该节点状态修改后，才会进行数据持久化

各个节点在任何时候都可能会变成Leader，Follwer，Candidate等角色，同时为了减少创建链接开销，etcd节点在启动时就会创建并维持与集群其他节点之间的链接。

etcd集群的各个节点之间需要通过网络进行数据的传递，具体表现为如下：

• Leader向Follwer发送心跳包，Follwer向Leader回复消息
• Leader向Follwer发送日志追加信息
• Leader向Follwer发送Snapshot数据
• Cnadidate节点发起选举，向其他节点发起投票请求
• Follwer将收到的写操作转发给Leader

因此，etcd集群节点的网络拓扑是一个任意两个节点之间均有长链接互相链接的网络结构，拓扑图大致如下：

etcd数据通道

在etcd中根据不同的用途定义了不同的消息类型，这些不同的消息的大小不同，例如Snapshot的数据量比较大，而Leader向Follwer发送的心跳包比较小，所以网络层必须高效的处理不同数据量的消息。etcd对消息采取了分类处理的方式，抽象出两种类型的消息传输通道，即Stream消息类型通道和pipeline类型通道。

Stream类型通道

Stream类型通道用于处理数据量比较少的消息，例如，心跳，日志追加消息等。点到点之间只维护一个HTTP长连接，交替向链接中写入数据和读取数据。

Stream类型通道是节点启动后主动与其他每一个节点建立链接，通过Channel与Raft模块传递消息。每一个Stream类型通道关联两个go routine，其中一个用于建立HTTP链接，并且从链接上读取数据并解码成消息，在通过Channel传给Raft模块，另一个通过GO语言的Channel从Raft模块中接受消息，然后写入Stream类型通道。

etcd使用了Go的HTTP包实现Stram类型通道，具体过程如下：

1. Server端监听端口，并且在对应的URL上挂载对应的Handler
2. 客户端发送的HTTP GET请求
3. 调用Server端的Handler的ServerHTTP访问，其中http.ResponseWriter对象将作为参数传入Writer-Goroutine，该go routine的主循环就是将Raft模块传出消息写入到这个http.ResponseWriter中。http,Request的Body作为参数传入Reader-Goroutine，这个go routine会循环读取Body中的数据解码成消息，通过Go中的Channel传给Raft模块

Pipeline类型通道

Pipeline类型通道用于处理数据量大的消息，例如，Snapshot，这种类型的消息需要和心跳等数据量小的消息区分开来处理，否则会阻塞心跳包传输，进而影响稳定性。使用Pipelien类型通道进性通信时，点与点之间不维护HTTP长连接，它只通过短链接传输数据，即用完即关闭。Pipeline类型通道也可以传输小数据量的消息，这种情况只在Stream类型的链接不可用时，才会这样做

此外，Pipeline类型通道还可以并行发出多个消息，维护者一组go routine ，每个go routine都可以向对端发出post请求，收到回复后链接关闭。etcd使用HTTP包实现Pipeline类型通道的具体过程如下：

1. 根据配置，启动N个go routine
2. 每一个go routine都阻塞在消息Channel上，待收到消息后，通过POST请求发出数据，等待回复

网络层与Raft模块交互

Raft协议在etcd中被抽象成Raft模块，etcd通过Raft模块中抽象的RaftNode拥有一个消息盒子，RaftNode将各种类型的消息都放在消息盒子中，由专门的go routine将消息盒子中的消息写入Channel，而Channel的另一端就链接在网络层的不同类型的传输管道上，也存在一个专门的go routine等待消息到达。网络层收到的消息也是通过Channel传给RaftNode的，RaftNode中有专门的go routine等待消息。即网络层与Raft模块之间通过Go语言的Channel完成数据通信

etcd server与客户端交互

etcd server启动之初就会监听服务端口，待服务端口收到客户端的请求后，就会解析出消息体，然后通过管道传给Raft模块，当Raft模块按照Raft协议完成操作后，就会回复请求（或者请求超时关闭）。客户端与所有的etcd server都是通过客户端的端口使用HTTP进行通信的。etcd server的客户端端口主要是用来对外提供服务的

etcd server之间的交互

etcd server之间通过peer端口使用HTTP进性通信。etcd server的peer端口主要用来协调Raft的相关信息，包括各种提议的协商