要理解 watchableStore 我们首先得搞清楚 store，store 其实是 ConsistentKV，而 watchableStore 其实只是实现了 watchable 的功能而已，所有的 KV interface 都是由 store 来完成的。

创建 store

简化后流程如下（省略了一些不关键的代码）

// NewStore returns a new store. It is useful to create a store inside
// mvcc pkg. It should only be used for testing externally.
func NewStore(lg *zap.Logger, b backend.Backend, le lease.Lessor, ig ConsistentIndexGetter) *store {
	s := &store{
			// 在内存中创建 btree 索引
			kvindex: newTreeIndex(lg),
      // 初始化的时候 revision 从 1 开始
			currentRev:     1,
			compactMainRev: -1,
			// 先入先出的 job 调度队列
			fifoSched: schedule.NewFIFOScheduler(),
		}
		s.ReadView = &readView{s}
		s.WriteView = &writeView{s}
		if s.le != nil {
      // lessor 在 lease 过期 之后会调用这个 RangeDeleter 来删除 mvcc 中对应的资源
			s.le.SetRangeDeleter(func() lease.TxnDelete { return s.Write() })
		}
	
		tx := s.b.BatchTx()
		tx.Lock()
    // key bucket 就是用来存 key-value 的
		tx.UnsafeCreateBucket(keyBucketName)
    // meta bucket 用来存 etcd 相关的元数据，比如 finishedCompactRevision scheduledCompactRevision
		tx.UnsafeCreateBucket(metaBucketName)
		tx.Unlock()
		s.b.ForceCommit()
	
		s.mu.Lock()
		defer s.mu.Unlock()

    // 从文件中恢复 mvcc
		if err := s.restore(); err != nil {
			panic("failed to recover store from backend")
		}
	
		return s
}

restore

• 先修改一些与 metrics 相关的内容
• 计算得到 min 和 max revision ，分别为revision{main: 1} 和 revision{main: math.MaxInt64, sub: math.MaxInt64}
• 从 bolt 的 meta bucket 中恢复出 finishedCompactRevision 和 scheduledCompactRevision
  • scheduledCompactRevision 表示下一个将要执行的 compact 对应的 revision
  • finishedCompactRevision 表示最后一个完成的 compact 中的 revision，将这个值存入 store.compactMainRev
• 通过 rkvc, revc := restoreIntoIndex(s.lg, s.kvindex) 获取到两个 channel
  • rkvc chan← revKeyValue 接收 revKeyValue 结构体，然后将其恢复到 treeIndex 中，恢复的过程有点类似 redo 了一遍
  • 在 close rkvc 之后，可以从 revc 中获取到 currentRev
• 循环从 key bucket 中获取到 key value，每次最多获取 restoreChunkKeys(10000) 个，将获取到的 keys（revisions） 和 values（KeyValues) 转化成 revKeyValue 结构，然后传入 rkvc channel 中来恢复 kvindex
• 最终从 revc channel 中获取到 currentRev
• 通过 keyToLease ，恢复 lessor 中的对应关系
• 如果 scheduledCompactRevision > finishedCompactRevision 则说明有未完成的 compact 存在，继续执行 compact

Watchable

在了解清楚了 store 的存储和索引机制之后，我们来看看它是怎么实现 watch 的功能。

首先理解一下完整的调用链。这里有很多知识点，画重点，要考的

client 通过一次 gRPC 请求跟 etcd 服务器建立一个 gRPC stream，同时 etcd 服务器为这个客户端维护了一个 watchStream，然后客户端通过 gRPC stream 发送一个 WatchCreateRequest 请求 etcd 创建一个 watcher channel，至此 watch 通道创建完毕。

stream 的模型如下，理论上一个 client 对应一个 gRPC stream 和 watch stream，同一个 client 的多个 watcher 共享一个 stream 达到多路复用的效果，通过事件中的 watcher id 来确定归属