Etcd是go语言开发的一个开源的，高可用的分布式key-value存储系统，可以用于配置共享和服务的注册和发现。
Etcd具有以下特点：
· 完全复制：集群中的每个节点都可以使用完整的存档。
· 高可用性：Etcd可用于避免硬件的单点故障或网络问题。
· 一致性：每次读取都会返回跨多主机的最新写入。
· 简单：包括定义良好，面向用户的API（gRPC）。
· 安全：实现了带有可选的客户端证书身份验证和自动化TLS。
· 快速：每秒10000次写入的基准速度。
· 可靠：使用Raft算法实现了强一致，高可用的服务存储目录。
Etcd应用场景：
服务发现
服务发现要解决的也是分布式系统中常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立链接。本质上来说，服务发现就是想要了解集群中是否有监听UDP或者TCP端口，并且通过名字就可以查找和连接。
配置中心
将一些配置信息放到etcd上进行集中管理。
这类场景的使用方式通常是：应用在启动的时候主动从etcd获取一次配置，同时，在etcd节点上注册一个Watcher等待，以后每次配置有更新的时候，etcd都会实时通知订阅者，以此达到获取最新配置信息的目的。
分布式锁
因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种，一种是保持独占，一种是控制时序。
一，保持独占：即所有获取锁的用户最终只有一个可以得到。etcd为此提供了一套实现分布式锁原子操作CAS(CompareAndSwap)的API。通过设置prevExist的值，可以保证多个节点同时去创建某个目录，只有一个成功。而创建成功的用户就可以认为是获取到了锁。
二，控制时序：即所有想获取锁的用户都会被安排执行，但是获得锁得顺序也是全局唯一的，同时决定了执行顺序。etcd为此也提供了一套API(自动创建有序键)，对一个目录建立值时指定为POST动作，这样etcd会自动在目录下生成一个当前最大的值为键，存储这个新的值(客户端的编号)。同时还可以使用API按顺序列出所有当前目录下的键值。此时这些就是客户端的时序，而这些键中存储的值可以是代表客户端的编号。
Etcd相对ZooKeeper的优缺点：
etcd实现的这些功能，ZooKeeper都可以实现。那么为什么要使用Etcd而不使用ZooKeeper呢？其实相比之下
ZooKeeper有如下缺点:
1.复杂:ZooKeeper的部署维护复杂，管理员需要掌握一系列的只是和技能；而Paxos强一致性算法也是素来以复杂难懂而闻名于世。另外ZooKeeper的使用也比较复杂，需要安装客户端，官网只提供了Java和C两种语言的接口。
2.Jave编写。因为Java本身偏向于重型应用，它会引入大量的依赖。而运维人员则普遍希望保持强一致性，高可用的机器集群尽可能的简单，这样维护起来也不易出错。
3.发展缓慢。Apache基金会项目特有的"Apache Way"在开源界饱受争议，其中最大的原因是由于基金会庞大的结构以及松散的管理导致项目发展缓慢。
Etcd的优点:
1.使用GO语言编写部署简单；使用HTTP作为接口使用简单；使用Raft算法保证强一致性让用户易于理解
2.数据持久化；Etcd默认数据一更新就进行持久化。
3.安全。Etcd支持SSL客户端安全认证。
最后Etcd作为一个年轻的项目，真正告诉迭代和开发中，这既是一个优点也是一个缺点。优点是它的未来具有无限可能性，缺点是无法得到大项目长时间使用的检验。然而，目前CoreOS,Kubernetes和CloudFoundry等一些知名项目均在生产环境使用了Etcd，所以总的来说，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表示存储的具体日志内容。
Etcd集群:
注：etcd作为一个高可用的键值存储系统，天生就是为了集群化而设计的。由于Raft算法在做决策时需要多数节点的投票，所以etcd一般都部署集群推荐奇数个节点，推荐数量为3，5或者7个节点构成一个集群。
