kubernetes-etcd 原理

1、主要功能

基本的key-value存储

监听(watch)机制

key的过期及续约机制，用于监控和服务发现

原子CAS(compare and swap)和CAD(compare and delete)，用于分布式锁和leader选举

2、etcd基于RAFT的一致性

2.1 选举方法

选举过程中的角色有领导者(leader)、跟随者(foller)和候选者(candidate)三种。

选举阶段：

初始启动时，节点处于follower状态并设定一个election timeout，如果这一时间周期内没有收到来自leader的heartbeat，节点发起选举；

将自己切换为candidate之后，向集群其它follwer节点发送请求，询问其是否选举自己成为leader；

当收到来自集群中过半数节点的接受投票后，节点成为leader，开始接收保存client的数据并向其它follower节点同步日志；

如果没有达成一致，则candidate随机选择一个等待间隔再次发起投票，得到集群中半数以上follower接受的candidate成为leader；

维持地位阶段：

leader节点依靠定时向follower发送heartbeat来保持其地位；

任何时候如果其他follower在election timeout期间都没有收到来自leader的heartbeat，同样会将自己的状态切换为candidate并发起选举，每成功选举一次，新leader的任期都会比之前leader的任期大1；

2.2 日志复制

当前leader收到客户端的日志后应该把日志追加到本地的Log中，然后通过heartbeat把该Entry同步给其他follower；

follower收到日志后记录日志然后向leader发送ACK，当leader收到超过半数follower的ACK信息后将该日志设置为已提交并追加到本地磁盘中, 并通知客户端；

随后在下个heartbeat中leader将通知所有follower将该日志存储在自己的本地磁盘中；

2.3 安全性

安全性是用于保证每个节点都执行相同序列的安全机制；

如果当某个follower在当前leader 提交日志时变得不可用了，稍后可能该follower又会被选举为leader，这时新leader可能会用新的log覆盖先前已经提交的log，这就导致节点执行不同序列；Safety就是用于保证选举出来的leader一定包含先前提交日志的机制。

选举安全性(Election Safety) : 每个任期只能选举出一个leader；

leader完整性(Leader Completeness) : 指Leader日志的完整性，当Log在任期Term1被commit后，那么以后任期Term2、Term3等的leader必须包含该Log；

Raft在选举阶段就使用Term的判断用于保证完整性；当请求投票的该candidate的Term较大或Term相同Index更大则投票，否则拒绝该请求。

2.4 失效处理

leader失效：其他没有收到heaterbeat的节点会发起新的选举，而当leader恢复后由于日志step number小会自动成为follwer，日志也会被新leader的日志覆盖；

follower失效：只要这一节点再次加入集群时重新从leader节点处复制日志即可；

多个candidate：冲突后candidate将随机选择一个等待时间再次发起投票，得到半数以上follower接受的candidate将成为leader；

3 v3版本架构

3.1 store实现

etcd v3 store分为两部分，一部分是内存中的索引，基于Google开源的btree实现的，另外一部分是后端存储。

按照它的设计，backend可以对接多种存储，当前使用的是boltdb。boltdb是一个单机的支持事务的kv存储，etcd事务是基于boltdb事务实现的。

etcd在boltdb中存储的key是revision，value是etcd自己的key-value组合，故etcd会在boltdb中把每个版本都保存下，从而实现了多版本机制。

reversion主要由两部分组成，第一部分是main rev，每次事务进行加一，第二部分sub rev，同一个事务中的每次操作加一。

可以看出如果要从boltdb中查询数据，必须通过revision，但客户端都是通过key来查询value，所以ETCD的内存kvindex保存的就是key和revision之间的映射关系。

3.2 watch机制实现

• v3版本中的watch机制支持watch某个固定的key，也支持watch一个范围，所以watchGroup中包含两种watcher，一种是key watchers，数据结构是每个key对应的一组watcher，另外一种是range watchers，数据结构是一个intervalTree，方便通过区间查找对应的watcher。
• 同时，每个watchableStore包含两种watcherGroup，一种是synced，一种是unsynced，前者表示该group的watcher数据都已经同步完毕，在等待新的变更，后者表示该group的watcher数据同步落后于当前最新变更，还在追赶。
• 当etcd收到客户端的watch请求，如果请求携带了revision参数，则比较请求的revision和store当前的revision，如果大于当前revision，则放入synced组中，否则放入unsynced组。同时etcd会启动一个后台的goroutine持续同步unsynced的watcher，然后将其迁移到synced组。这种机制下，实现了etcd v3支持从任意版本开始watch；