1.Raft协议概览

节点刚启动的时候，都是follower，如果说follower在一定时间内没有收到leader的心跳，那么就会变成candidate来发起投票竞选成为leader，成为leader后，就会心跳给其他人，其他人的等待超时时间就会重新刷新以此承认leader。

1.1 learner

如果只有leader和follower两种角色的时候，会有一些问题。比如某些时候，Follower坏掉了，要换一个新的上来，但新的follower数据跟leader的数据差距太大了，如果这个新的follower发起投票，别的follower的commit都比它大很多，那这次投票就是无效的，再加上这种新的follower为了同步数据，导致网络压力很大，心跳可能发送失败，这样会进一步导致集群不可用的状态更严重了。

2 etcd基于Raft的一致性

3 etcd日志复制

数据的写入都需要发送给leader，那如果写入请求发给了follower会怎样呢？Follower接收到这个请求以后，会在一致性模块里面，把这个请求转给leader，让leader去处理

4 etcd 安全性

5 失效处理

6 wal日志（write ahead log)

7 etcd v3存储，Watch以及过期机制

etcd存储数据的时候，主要分成了2个部分，第一个部分叫做KVStore，KVStore是它存在内存里面的，这是一个in memory的KVStore，这一块主要是用来做索引的。第二个部分：blotdb，真正存数据的地方。
WatchableStore，主要是用于监听的。因为etcd本身是支持监听的，

7.1 存储机制

7.2存储流程

写入请求进来之后，首先会进行预检查，预检查通过了之后，会转发到KVServer,KVServer接收到这个请求会通过propose的方法然后转发到一致性模块，一致性模块会做日志复制，日志复制具体的操作是首先会在memory里面（etcd的内存里面）构建raftLog，它会把相应的命令写入到unstable里面，记录了一下说我现在有一条数据要写入，接下来同时这个请求会写入到本地wal log（这个写入是要落盘的），但这个落盘是用fsync，不然的话效率太低了，写wal log的同时，有一个gorouting把同样的message，发到其他follower那里。follower收到这个请求之后呢，它也要做同样的事情，相当于把这个写操作放入wal log，并且写完以后返回response。Leader如果收到半数以上的回复，就确认这个写入commit了，然后更新MatchIndex，接下来unstable里面的数据放到committed里面，同时leader会请求状态机（MVCC模块）来记录这次数据。

7.3Watch机制