etcd
初识etcd
etcd是一个分布式可靠的键值存储系统。它提供了与ZooKeeper相似的功能，但是使用Go语言编写而不是Java语言。Etcd使用Raft协调算法而不是ZooKeeper采用的Paxos算法。在云计算方面，Go是一个大有前景的语言，被誉为云时代的C语言。
对比与ZooKeeper，etcd更轻量级，etc更加关注一下几点：
- 简单：curl命令可以调用的API接口（http+JSON）
- 保密：可选的SSL客户端认证
- 快速：标准检测每个实例每秒1000读写能力
- 可靠：恰到地实现分布式协调，采用Raft一致性算法
etcd虽然是一个很年轻的项目，但是，已经在CoreOS、Kubernetes和CloudFoundry等知名厂商的生产环境中广泛使用。足见etcd具有一定得发展前景。如果你偏向使用成熟的Java客户端去调用etcd，有几个Java客户端库提供选择。
1.boonproject/etcd 支持etcd v2， Async/Sync和waits
2.[justinsb/jetcd](https://github.com/justinsb/jetcd或者
[diwakergupta/jetcd](https://github.com/diwakergupta/jetcd）支持etcd v2
3.jurmous/etcd4j 支持etcd v2, Async/Sync, waits 和 SSL。如果你关注高性能，比较喜欢Go语言技术栈。有两个Go语言的客户端库提供选择：
A. etcd/client 官方维护的Go语言客户端
早期版本
B. go-etcd 官方客户端，可能更适合etcd早期版本（< 2.0.0）
etcd架构
从etcd的架构图中我们可以看到，etcd主要分为四个部分。
- HTTP Server： 用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求。
- Store：用于处理etcd支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是etcd对用户提供的大多数API功能的具体实现。
- Raft：Raft强一致性算法的具体实现，是etcd的核心。
- WAL：Write Ahead Log（预写式日志），是etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd就通过WAL进行持久化存储。WAL中，所有的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容。
通常，一个用户的请求发送过来，会经由HTTP Server转发给Store进行具体的事务处理，如果涉及到节点的修改，则交给Raft模块进行状态的变更、日志的记录，然后再同步给别的etcd节点以确认数据提交，最后进行数据的提交，再次同步。
应用场景
Etcd的应用场景包括服务发现（Service Discovery）、消息发布与订阅、负载均衡、分布式通知与协调、分布式锁、分布式队列。如果你属性ZooKeeper, 你会发现etcd实现了ZooKeeper的功能。
- 服务发现：服务发现就是在一个分布式集群中，如何发现服务端并建立连接。即，发现对应服务的IP和端口，建立连接而已。
- 消息发布与订阅：在构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息订阅者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。
- 负载均衡：分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把应用节点部署多分，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。因为每个对等服务节点上都存有完整的服务功能，利用合理的负载均衡策略，访问流量就可以分流到不同的机器上。
- 分布式通知与协调：这个功能与消息发布和订阅有些相似，但是，也有一定得区别。它们都用到了etcd中的Watcher机制，通过注册与异步通知机制，实现分布式环境下不同系统或者模块之间的通知与协调，从而对数据变更做到实时处理。不同系统都在etcd上对同一个目录进行注册，同时设置Watcher观测该目录的变化。只要某个系统更新了etcd的目录，其它设置了Watcher的系统就会收到通知，并作出相应处理。
- 分布式锁：etcd采用Raft算法保证数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。
- 分布式队列：创建一个先进先出的队列，保证顺序。另一种比较有意思的实现是在保证队列达到某个条件时再统一按顺序执行。