PowerDotNet平台化软件架构设计与实现系列（05）：ETCD分布式键值存储平台

ETCD目前在PowerDotNet已经被用于注册中心和配置管理（常见的配置中心在PowerDotNet中仅仅是一个小小的模块而已）中，作为基础设施的重要组成部分，ETCD的重要性不言而喻。

本文简单总结介绍下个人开发使用和管理ETCD的一些经验。

ETCD诞生于CoreOS公司，它最初是用于解决集群管理系统中OS升级的分布式并发控制以及配置文件的存储与分发等问题。

按照官方解释（A distributed, reliable key-value store for the most critical data of a distributed system），ETCD是一个分布式的可靠的键值对存储系统，用于存储分布式系统中的关键数据。

对于熟悉ZooKeeper的人来说，ETCD提供的功能和ZooKeeper非常相似，比如都是通用的一致性元信息存储，都提供watch机制用于变更通知和分发，也都被分布式系统用来作为共享信息存储等。

实际上，据说ETCD就是受到ZooKeeper与doozerd启发而催生的一个项目，除了拥有与之类似的功能外，更专注于以下四点：

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

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

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

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

下面两段介绍下ETCD基础概念和工作原理，主要抄书，特别鸣谢这篇文章作者，对个人理解提高非常有帮助。

一、ETCD构成

ETCD主要分为四个部分：

1、HTTP Server：用于处理用户发送的API请求以及其它ETCD节点的同步与心跳信息请求。

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

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

4、WAL：Write Ahead Log（预写式日志），是ETCD的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，ETCD就通过WAL进行持久化存储。WAL中，所有的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容。

通常，一个用户的请求发送过来，会经由HTTP Server转发给Store进行具体的事务处理，如果涉及到节点的修改，则交给Raft模块进行状态的变更、日志的记录，然后再同步给别的ETCD节点以确认数据提交。最后进行数据的提交，再次同步。

ETCD作为一个高可用键值存储系统，天生就是为集群化而设计的。ETCD有三种集群化启动的配置方案，分别为静态配置启动、ETCD自身服务发现、通过DNS进行服务发现。

从图上我们能看到，一个 ETCD集群，通常会由 3 个或者 5 个节点组成（由于Raft算法在做决策时需要多数节点的投票，所以ETCD一般部署集群推荐奇数个节点，推荐的数量为3、5或者7个节点构成一个集群），多个节点之间通过 Raft 一致性算法的完成分布式一致性协同，算法会选举出一个主节点作为 leader，由 leader 负责数据的同步与数据的分发。当 leader 出现故障后系统会自动地选取另一个节点成为 leader，并重新完成数据的同步。客户端在多个节点中，仅需要选择其中的任意一个就可以完成数据的读写，内部的状态及数据协同由 ETCD 自身完成。

这里再小结下ETCD的重要概念：

Raft：ETCD的核心，保证分布式系统强一致性的算法。

Node：一个 Raft 状态机实例。

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

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

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

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

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

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

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

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

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