1. ETCD和RAFT整体架构
2. RAFT算法
Raft强一致性算法的具体实现Leader选举和数据备份
https://www.jianshu.com/p/5aed73b288f7
论文译文
https://www.infoq.cn/article/raft-paper/
2.1 选举
一个新的集群启动时，或者老的leader故障时，会选举出一个新的leader.
https://www.cnblogs.com/sunsky303/p/11451755.html
选举机制动画
http://thesecretlivesofdata.com/raft/
2.2 日志复制
leader必须接受客户端的日志条目并且将他们同步到集群的所有机器
Leader选出后接受客户端请求，Leader把请求日志作为日志条目加入到日志中，然后向其他Follower节点复制日志，但超过半数的日志复制成功，则Leader将日志应用到状态机，并向客户端返回执行结果，同时Follower也将结果提交。如果存在Follower没有成功复制日志,Leader会无限重试。
1,Leader提交log到WAL，并广播每个node
2,node收到后log到WAL，并返回
3,多数node返回后，修改状态为commit并存到DB，返回用户
4,通知其他node，commit这条log，并保存到db
2.3 安全性
保证任何节点只要在它的状态机中生效了一条日志条目，就不会在相同的key上生效另一条日志条目
3. API Server
用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求.
4. WAL
Write Ahead Log（预写式日志），是etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd就通过WAL进行持久化存储。WAL中，所有的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容.
5. KV Store
kv数据的存储引擎，v3支持不同的后端存储，当前采用boltdb。通过boltdb支持事务操作.
6. Node状态
6.1 leader
负责日志的同步管理，处理来自客户端的请求，与Follower保持这heartBeat的联系
6.2 follower
刚启动时所有节点为Follower状态，响应Leader的日志同步请求，响应Candidate的请求，把请求到Follower的事务转发给Leader
6.3 candidate
负责选举投票，Raft刚启动时由一个节点从Follower转为Candidate发起选举，选举出Leader后从Candidate转为Leader状态。
6.3.1 静态配置
这种方式比较适用于离线环境，在启动整个集群之前，你就已经预先清楚所要配置的集群大小，以及集群上各节点的地址和端口信息。那么启动时，你就可以通过配置ETCD_INITIAL_CLUSTER参数进行etcd集群的启动
ETCD_INITIAL_CLUSTER="infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380"
ETCD_INITIAL_CLUSTER_STATE=new
6.3.2 动态自发现配置
通过自发现的方式启动etcd集群需要事先准备一个etcd集群。
如果你本地没有可用的etcd集群，etcd官网提供了一个可以公网访问的etcd存储地址。
6.3.3 DNS发现
etcd还支持使用DNS SRV记录进行启动。所以你要在DNS服务器上进行相应的配置
