配置中心
将一些配置信息放到etcd上进行集中管理。
这类场景的使用方法通常是这样：应用在启动的时候主动从etcd获取一次配置信息，
同时，在etcd节点上注册一个Watcher并等待，以后每次配置有更新的时候，etcd都会
实时通知订阅者，以此达到获取最新配置信息的目的。
分布式锁
因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必须是全局
一致的，所以很容易实现分布式锁，锁服务有两种使用方法，一个是保持独占，而是控制时序。
保持独占即所有获取锁的用户最终只有一个可以得到，etcd为此提供了一套实现分布式锁
原子操作CAS的API,通过设置prevExist值，可以保证再多个节点同时去创建某个时序，
即所有想要获得锁的用户都会被安排执行，但是获得锁的顺序也是全局唯一的，同时决定了执行
顺序，etcd为此也保持了一套API自动创建有序健，对一个目录值时指定为post
动作，这样etcd会自动在目录下生成一个当前最大的值为健，存储这个新的值，同时
还可以使用API按顺序列出所有当前目录下的健值，此时这些健的值就是客户端的时序，而这些健中
存储的值可以是代表客户端的编号。
为什么用etcd而不用zookeeper?
etcd 实现的这些功能，ZooKeeper都能实现，那么为什么要用etcd而非直接使用zookeeper呢
相较之下，zookeeper有如下缺点：
1. 复杂，zookeeper的部署维护复杂，管理员需要掌握一系列的知识和功能；而Paxos强一致性算法也是
素来以复杂难懂而闻名于世；另外，zookeeper的使用也比较复杂，需要安装客户端，官方只提供了java和c
两种语言的接口。
2.java编写，这里不是对java有偏见，而是java本身就偏向于重型应用，它会引入大量的依赖。而
运维人员则普遍希望保持强一致性，高可用的机器集群尽可能简单，维护起来也不易出错。。
3. 发展缓慢，
而etcd 作为一个后起之秀，其优点也很明显
1.简单，使用Go语言编写部署简单；使用HTTP作为接口使用简单，使用Raft算法保证
强一致性
让用户易于理解
2.数据持久化，etcd默认数据一更新就进行持久化
3.安全 etcd 支持SSL 客户端安全认证
从etcd的架构图中我们可以看到，etcd主要分为四个部分。
HTTP Server：用于处理用户发送的API请求以及其他etcd节点的同步与心跳信息请求。
Store:用于处理etcd支持的各类功能的事物，包括数据索引 节点状态变更 监控与
反馈 事件处理与执行等等，是etcd对用户提供的大多数API功能的具体实现。
Raft:Raft 强一致性算法的具体实现，是etcd的核心。
WAL:Write Ahead Log 预写式日志 是etcd的数据存储方式，除了在内存中存在有所有数据的状态
以及节点的索引以外，etcd 就通过WAL进行持久化存储，WAL 中，所有的数据提交前都会实现记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容。
etcd集群
etcd 作为一个高可用的健值存储系统，优点在于集群化处理，由于Raft算法在作决策时需要多数节点的投票，所以etcd一般部署集群推荐奇数个节点，推荐的数量为3 5 或7个节点构成一个集群。
搭建一个3节点集群示例：
在每个etcd节点制定及群成员，为了区分不同的集群最好同时配置一个独一无二的token。
下面是提前定义好的集群信息，其中 n1 n2 n3 表示3个不同的etcd节点。