etcd简介
etcd是一个开源的、分布式的、强一致性的、可靠的键值存储系统。常用于存储分布式系统的关键数据。它可以在网络分区期间可以优雅地处理leader选举，并且可以容忍机器故障。
关键特性：
分布式强一致性键值存储监听数据变化
键值存储
etcd的存储格式，仅支持键值（key-value）存储，etcd的键（key）以目录树结构方式组织，就是key的命名和存储类似我们的目录结构。
key的命名例子:
/sreio
/sreio/site/name
/sreio/site/domain
/sreio/status/urlskey以这种目录树结构方式存储，etcd支持前缀搜索，例如：搜索key 以 /sreio 为前缀的所有键值。
强一致性
etcd通过Raft协议保证etcd各个节点数据的一致性，任何时刻，都可以从任意etcd节点查询到正确的数据。
监听数据变化
支持监听某个key，或者某一批key的数据变化，当这些key的数据发生变化，就会立即通知监听客户端。
etcd和redis的差异
etcd和redis都支持键值存储，也支持分布式特性，redis支持的数据格式更加丰富，但是他们两个定位和应用场景不一样，关键差异如下：
- redis在分布式环境下不是强一致性的，可能会丢失数据，或者读取不到最新数据。
- redis的数据变化监听机制没有etcd完善。
- 因为etcd的强一致性机制，导致性能上要低于redis。
基于上面的关键差异，如果系统没有强一致性要求，需要缓存系统redis比较合适，如果需要存储分布式系统的元数据，辅助分布式系统协调通知、关键配置 etcd比较合适，这些场景对读写的吞吐量没有缓存要求那么高，但是对数据一致性要求比较高，例如：如果我们开发一个分布式系统，是主从架构，需要实现自动选举一个节点作为主节点，这个选举状态数据的存储引擎，必须是高可用、强一致性的，否则每个节点读取到的状态数据都不一致、或者读取不到数据，集群就乱了，不知道谁是主节点。
etcd和ZooKeeper是定位类似的项目，跟redis定位不一样。
应用场景
- 分布式系统配置管理
- 服务注册与发现
- 选主，就是选举leader
- 应用调度
- 分布式锁
