Etcd
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节点以确认数据提交，最后进行数据的提交，再次同步。
如何保证强一致性？
使用raft协议 包括两个过程 选主过程、主从数据同步 ==在etcd中数据只有一个流向，leader到follower==
主从数据同步
- client连接follower或者leader，如果连接的是follower则，follower会把client的请求(写请求，读请求则自身就可以直接处理)转发到leader
- leader接收到client的请求，将该请求转换成entry，写入到自己的日志中，得到在日志中的index，会将该entry发送给所有的follower(实际上是批量的entries)
- follower接收到leader的AppendEntriesRPC请求之后，会将leader传过来的批量entries写入到文件中（通常并没有立即刷新到磁盘），然后向leader回复OK,leader收到过半的OK回复之后，就认为可以提交了，然后应用到leader自己的状态机中，leader更新commitIndex，应用完毕后回复客户端
- 在下一次leader发给follower的心跳中，会将leader的commitIndex传递给follower，follower发现commitIndex更新了则也将commitIndex之前的日志都进行提交和应用到状态机中
总结： 在leader收到数据操作的请求，先不着急更新本地数据（数据是持久化在磁盘上的），而是生成对应的log，然后把生成log的请求广播给所有的follower，每个follower在收到请求之后听从leader的命令，也写入log，然后返回success回去。eader收到过半的OK回复之后，就认为可以提交了，进行二次提交，正式写入数据（持久化），然后再告诉follower，他们也持久化
其中log可以用来恢复数据
剩下的内容将在下一个章节介绍。
