初识etcd

前言

  etcd来自于两个单词：Unix的“/etc”目录和“distibuted”，etc目录通常保存单机的配置信息，etcd表示存储大型分布式系统的配置数据。

  它是一个分布式、高可用的key-value型存储仓库，通常用于配置共享与服务发现，为分布式系统提供关键数据存储服务。它由CoreOS开发并开源，授权协议为Apache，据官网数据显示，目前有Kubernetes, Cloud Foundry, 以及在Github上超过500个项目在使用ETCD。

特性

  可以提供配置共享和服务发现的系统比较多，如：Zookeeper、Doozer、Consul等，其中可能最为大家熟知的是Zookeeper。ECTD出了拥有与之类似的功能外，还具有以下特性。

• 简单： 拥有基于HTTP+JSON的API，使用curl命令就可以读写数据，跨平台跨语言，无需安装客户端。

• 安全： 可选 SSL 客户端认证机制，支持HTTPS访问，数据传输更为安全。

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

• 稳定：使用Raft算法实现了集群数据的一致性保障，更加稳定。

原理

  ETCD内部使用了Raft算法来维护集群内各节点状态的一致性。也就是说ETCD集群由多个节点组成，整体对外提供服务，每个节点都存储了完整的数据，Raft算法来保证每个节点的数据一致。

• 选主（Leader Election）：

  在ETCD集群中，节点可以分为：Leader（领袖）、Follower（追随者）、Candidate（候选人）三种角色。在集群初始化和Leader宕机后，会面临选主问题，大致流程如下：

1. 当集群初始化时候，每个节点都是Follower角色；

2. Follower等待Leader发送“心跳”（heartbeat），如果超过一定时间没有收到来自Leader的心跳，Follower会转变为Candidate，发送选举请求。这里为了避免进入选主失败循环，每个节点未收到心跳发起选举的时间是一定范围内的随机值，这样能够避免2个节点同时发起选主。

3. 当收到包括自己在内超过半数节点赞成后，选举成功；当收到票数不足半数选举失败，或者选举超时。Leader选举成功后会向其他节点发送“心跳”，Candidate节点收到后，会立即终止选举过程，进入Follower角色。

  Raft官网提供了一个动态展示效果，可以很好的理解选主过程。

width="800" height="580" border="0" src="https://raft.github.io/raftscope/index.html">

• 日志复制（Log Replication）：

  Leader会将每次操作形成日志条目，并且持久化到本地磁盘，然后通过网络发送给其他Follower。Leader收到包括自己在内超过半数节点的成功返回信息后，把日志输入到状态机，并将结果返回到客户端。

  Follower收到日志信息后，首先判断该日志的逻辑时钟（TERM）否过期，以及该日志条目的索引编号（INDEX）是否小于当前已提交日志的INDEX小。若已过期，或者比已提交的日志更早，那么就拒绝追加，并返回该节点当前的已提交的日志的编号。否则，将日志追加，并返回成功。

• 安全性（Security ）：

  Raft协议用来维护节点数据一致性，但是仅仅有“选主”和“日志复制”并不能保证集群内各个节点的数据是一致的。Raft协议中Leader会复制自己的日志到Follower，试想：如果Leader缺失了部分日志，会导致整个集群的日志丢失。为了解决这个问题，Raft协议在选主逻辑中，对能够成为主的节点加以限制，确保选出的节点已定包含了集群已经提交的所有日志。

小结

  目前etcd还是一个年轻的项目，正在快速迭代中，其可靠性还没有得到大项目长时间使用的验证，但是CoreOS、Kubernetes和Cloudfoundry等知名项目均在生产环境中使用了etcd，总的来说，etcd值得你去尝试。