ETCD整体机制
etcd 是一个分布式的、可靠的 key-value 存储系统，它适用于存储分布式系统中的关键数据。
etcd 集群中多个节点之间通过Raft算法完成分布式一致性协同，算法会选举出一个主节点作为 leader，由 leader 负责数据的同步与分发。当 leader 出现故障后系统会自动地重新选取另一个节点成为 leader，并重新完成数据的同步。
etcd集群实现高可用主要是基于quorum机制，即：集群中半数以上的节点可用时，集群才可继续提供服务，quorum机制在分布式一致性算法中应用非常广泛，此处不再详细阐述。
raft数据更新和etcd调用是基于两阶段机制：
第一阶段 leader记录log (uncommited)；日志复制到follower；follower响应，操作成功，响应客户端；调用者调用leader，leader会将kv数据存储在日志中，并利用实时算法raft进行复制
第二阶段 leader commit；通知follower；当复制给了N+1个节点后，本地提交，返回给客户端，最后leader异步通知follower完成通知
ETCD核心API分析
etcd提供的api主要有kv相关、lease相关及watch，查看其源码可知：
kv相关接口：
type KV interface {
// Put puts a key-value pair into etcd.
// Note that key,value can be plain bytes array and string is
// an immutable representation of that bytes array.
// To get a string of bytes, do string([]byte{0x10, 0x20}).
Put(ctx context.Context, key, val string, opts ...OpOption) (*PutResponse, error)
// Get retrieves keys.
// By default, Get will return the value for "key", if any.
// When passed WithRange(end), Get will return the keys in the range [key, end).
// When passed WithFromKey(), Get returns keys greater than or equal to key.
// When passed WithRev(rev) with rev > 0, Get retrieves keys at the given revision;
// if the required revision is compacted, the request will fail with ErrCompacted .
// When passed WithLimit(limit), the number of returned keys is bounded by limit.
// When passed WithSort(), the keys will be sorted.
Get(ctx context.Context, key string, opts ...OpOption) (*GetResponse, error)
// Delete deletes a key, or optionally using WithRange(end), [key, end).
Delete(ctx context.Context, key string, opts ...OpOption) (*DeleteResponse, error)
// Compact compacts etcd KV history before the given rev.
Compact(ctx context.Context, rev int64, opts ...CompactOption) (*CompactResponse, error)
// Txn creates a transaction.
Txn(ctx context.Context) Txn
}
主要有Put、Get、Delete、Compact、Do和Txn方法；Put用于向etcd集群中写入消息，以key value的形式存储；Get可以根据key查看其对应存储在etcd中的数据；Delete通过删除key来删除etcd中的数据；Compact 方法用于压缩 etcd 键值对存储中的事件历史，避免事件历史无限制的持续增长；Txn 方法在单个事务中处理多个请求，etcd事务模式为：
if compare
then op
else op
commit
lease相关接口：
type Lease interface {
// Grant creates a new lease.
Grant(ctx context.Context, ttl int64) (*LeaseGrantResponse, error)
// Revoke revokes the given lease.
Revoke(ctx context.Context, id LeaseID) (*LeaseRevokeResponse, error)
// TimeToLive retrieves the lease information of the given lease ID.
TimeToLive(ctx context.Context, id LeaseID, opts ...LeaseOption) (*LeaseTimeToLiveResponse, error)
// Leases retrieves all leases.
Leases(ctx context.Context) (*LeaseLeasesResponse, error)
// KeepAlive keeps the given lease alive forever. If the keepalive response
// posted to the channel is not consumed immediately, the lease client will
// continue sending keep alive requests to the etcd server at least every
// second until latest response is consumed.
//
// The returned "LeaseKeepAliveResponse" channel closes if underlying keep
// alive stream is interrupted in some way the client cannot handle itself;
// given context "ctx" is canceled or timed out. "LeaseKeepAliveResponse"
// from this closed channel is nil.
//
// If client keep alive loop halts with an unexpected error (e.g. "etcdserver:
// no leader") or canceled by the caller (e.g. context.Canceled), the error
// is returned. Otherwise, it retries.
//
// TODO(v4.0): post errors to last keep alive message before closing
// (see https://github.com/coreos/etcd/pull/7866)
KeepAlive(ctx context.Context, id LeaseID) (<-chan *LeaseKeepAliveResponse, error)
// KeepAliveOnce renews the lease once. The response corresponds to the
// first message from calling KeepAlive. If the response has a recoverable
// error, KeepAliveOnce will retry the RPC with a new keep alive message.
//
// In most of the cases, Keepalive should be used instead of KeepAliveOnce.
KeepAliveOnce(ctx context.Context, id LeaseID) (*LeaseKeepAliveResponse, error)
// Close releases all resources Lease keeps for efficient communication
// with the etcd server.
Close() error
}
lease 是分布式系统中一个常见的概念，用于代表一个分布式租约。典型情况下，在分布式系统中需要去检测一个节点是否存活的时，就需要租约机制。
Grant方法用于创建一个租约，当服务器在给定 time to live 时间内没有接收到 keepAlive 时租约过期；Revoke撤销一个租约，所有附加到租约的key将过期并被删除；TimeToLive 获取租约信息；KeepAlive 通过从客户端到服务器端的流化的 keep alive 请求和从服务器端到客户端的流化的 keep alive 应答来维持租约；检测分布式系统中一个进程是否存活，可以在进程中去创建一个租约，并在该进程中周期性的调用 KeepAlive 的方法。如果一切正常，该节点的租约会一致保持，如果这个进程挂掉了，最终这个租约就会自动过期，在 etcd 中，允许将多个 key 关联在同一个 lease 之上，可以大幅减少 lease 对象刷新带来的开销。
watch相关接口：
type Watcher interface {
// Watch watches on a key or prefix. The watched events will be returned
// through the returned channel. If revisions waiting to be sent over the
// watch are compacted, then the watch will be canceled by the server, the
// client will post a compacted error watch response, and the channel will close.
// If the context "ctx" is canceled or timed out, returned "WatchChan" is closed,
// and "WatchResponse" from this closed channel has zero events and nil "Err()".
// The context "ctx" MUST be canceled, as soon as watcher is no longer being used,
// to release the associated resources.
//
// If the context is "context.Background/TODO", returned "WatchChan" will
// not be closed and block until event is triggered, except when server
// returns a non-recoverable error (e.g. ErrCompacted).
// For example, when context passed with "WithRequireLeader" and the
// connected server has no leader (e.g. due to network partition),
// error "etcdserver: no leader" (ErrNoLeader) will be returned,
// and then "WatchChan" is closed with non-nil "Err()".
// In order to prevent a watch stream being stuck in a partitioned node,
// make sure to wrap context with "WithRequireLeader".
//
// Otherwise, as long as the context has not been canceled or timed out,
// watch will retry on other recoverable errors forever until reconnected.
//
// TODO: explicitly set context error in the last "WatchResponse" message and close channel?
// Currently, client contexts are overwritten with "valCtx" that never closes.
// TODO(v3.4): configure watch retry policy, limit maximum retry number
// (see https://github.com/etcd-io/etcd/issues/8980)
Watch(ctx context.Context, key string, opts ...OpOption) WatchChan
// RequestProgress requests a progress notify response be sent in all watch channels.
RequestProgress(ctx context.Context) error
// Close closes the watcher and cancels all watch requests.
Close() error
}
etcd 的Watch 机制可以实时地订阅到 etcd 中增量的数据更新，watch 支持指定单个 key，也可以指定一个 key 的前缀。Watch 观察将要发生或者已经发生的事件，输入和输出都是流;输入流用于创建和取消观察，输出流发送事件。一个观察 RPC 可以在一次性在多个key范围上观察，并为多个观察流化事件，整个事件历史可以从最后压缩修订版本开始观察。
ETCD数据版本机制
etcd数据版本中主要有term表示leader的任期，revision 代表的是全局数据的版本。当集群发生 Leader 切换，term 的值就会 +1，在节点故障，或者 Leader 节点网络出现问题，再或者是将整个集群停止后再次拉起，都会发生 Leader 的切换；当数据发生变更，包括创建、修改、删除，其 revision 对应的都会 +1，在集群中跨 Leader 任期之间，revision 都会保持全局单调递增，集群中任意一次的修改都对应着一个唯一的 revision，因此我们可以通过 revision 来支持数据的 MVCC，也可以支持数据的 Watch。
对于每一个 KeyValue 数据节点，etcd 中都记录了三个版本：
- 第一个版本叫做 create_revision，是 KeyValue 在创建时对应的 revision；
- 第二个叫做 mod_revision，是其数据被操作的时候对应的 revision；
- 第三个 version 就是一个计数器，代表了 KeyValue 被修改了多少次。
在同一个 Leader 任期之内，所有的修改操作，其对应的 term 值始终相等，而 revision 则保持单调递增。当重启集群之后，所有的修改操作对应的 term 值都加1了。
ETCD之MVCC并发控制
说起mvcc大家都不陌生，mysql的innodb中就使用mvcc实现高并发的数据访问，对数据进行多版本处理，并通过事务的可见性来保证事务能看到自己应该看到的数据版本，同样，在etcd中也使用mvcc进行并发控制。
etcd支持对同一个 Key 发起多次数据修改，每次数据修改都对应一个版本号。etcd记录了每一次修改对应的数据，即一个 key 在 etcd 中存在多个历史版本。在查询数据的时候如果不指定版本号，etcd 会返回 Key 对应的最新版本，同时etcd 也支持指定一个版本号来查询历史数据。
etcd将每一次修改都记录下来，使用 watch订阅数据时，可以支持从任意历史时刻（指定 revision）开始创建一个 watcher，在客户端与 etcd 之间建立一个数据管道，etcd 会推送从指定 revision 开始的所有数据变更。etcd 提供的 watch 机制保证，该 Key 的数据后续的被修改之后，通过这个数据管道即时的推送给客户端。
分析其源码可知：
type revision struct {
// main is the main revision of a set of changes that happen atomically.
main int64
// sub is the the sub revision of a change in a set of changes that happen
// atomically. Each change has different increasing sub revision in that
// set.
sub int64
}
func (a revision) GreaterThan(b revision) bool {
if a.main > b.main {
return true
}
if a.main < b.main {
return false
}
return a.sub > b.sub
}
在etcd的mvcc实现中有一个revision结构体，main 表示当前操作的事务 id，全局自增的逻辑时间戳，sub 表示当前操作在事务内部的子 id，事务内自增，从 0 开始；通过GreaterThan方法进行事务版本的比较。
ETCD存储数据结构
etcd 中所有的数据都存储在一个 btree的数据结构中，该btree保存在磁盘中，并通过mmap的方式映射到内存用来支持快速的访问，treeIndex的定义如下：
type treeIndex struct {
sync.RWMutex
tree *btree.BTree
}
func newTreeIndex() index {
return &treeIndex{
tree: btree.New(32),
}
}
index所绑定对btree的操作有Put、Get、Revision、Range及Visit等，以Put方法为例，其源码如下：
func (ti *treeIndex) Put(key []byte, rev revision) {
keyi := &keyIndex{key: key}
ti.Lock()
defer ti.Unlock()
item := ti.tree.Get(keyi)
if item == nil {
keyi.put(rev.main, rev.sub)
ti.tree.ReplaceOrInsert(keyi)
return
}
okeyi := item.(*keyIndex)
okeyi.put(rev.main, rev.sub)
}
通过源码可知对btree数据的读写操作都是在加锁下完成的，从而来保证并发下数据的一致性。