0. ETCD简介

本文将从以下几个方面来分析 ETCD （v3.3.12）。

整体架构
启动过程
数据存储
通信方式
TTL实现原理
Lease实现原理
单次事务过程
线性一致性读过程
Watch机制

在介绍上面所有过程之前，我们先来介绍下 ETCD的整体架构以及相关名词术语。

- Node：一个Raft状态机节点；
- Proxy：etcd的一种模式，为etcd集群提供反向代理服务；
- Member： etcd集群中的一个节点。它可以与其他节点进行交互且为客户端提供服务；
- Cluster：由多个Member组成的etcd集群；
- Peer：对处在相同集群中其他节点的称呼；
- Client： 请求客户端；
- Candidate	候选人
- Leader	领导者
- Follower	跟随者
- Term	选举任期，每次选举之后递增1
- Index：索引号，Raft中通过Term和Index来定位数据。
- Vote	选举投票(的ID)
- Commit	提交
- Propose	提议
- WAL：预写式日志
- SoftState：软状态，软状态易变且不需要保存在WAL日志中的状态数据，包括：集群leader、节点的当前状态
- HardState：硬状态，与软状态相反，需要写入持久化存储中，包括：节点当前Term、Vote、Commit
- ReadStates：用于读一致性的数据，后续会详细介绍
- Entries：在向其他集群发送消息之前需要先写入持久化存储的日志数据
- Snapshot：需要写入持久化存储中的快照数据
- CommittedEntries：需要输入到状态机中的数据，这些数据之前已经被保存到持久化存储中了
- Messages：在entries被写入持久化存储中以后，需要发送出去的数据

peer间通信消息类型：

- MsgHup            // 不用于节点间通信，仅用于发送给本节点让本节点进行选举
- MsgBeat           // 心跳消息
- MsgProp           // raft库使用者提议（propose）数据
- MsgApp            // 用于leader向集群中其他节点同步数据的消息
- MsgAppResp        // 消息同步回复
- MsgVote           // 请求投票
- MsgVoteResp       // 投票反馈
- MsgSnap           // 用于leader向follower同步数据用的快照消息
- MsgHeartbeat      // 心跳消息
- MsgHeartbeatResp  // 心跳回复消息
- MsgTransferLeader // 转移主节点
- MsgReadIndex      // 用于线性一致性读
- MsgReadIndexResp  
- MsgPreVote        // 请求预先投票
- MsgPreVoteResp

Etcd整体架构图如下：

下面将简单介绍下：

etcd面向client和peer节点开放http服务以及grpc服务，对于像watch机制就是基于grpc的stream通信模式实现的；
EtcdServer是etcd上层结构体，其负责对外提供服务，且负责应用层的实现，比如操作应用层存储器，管理leassor、watch；
raftNode负责上层与raft层的衔接。其负责将应用的需求传递到raft中进行处理（通过Step函数）、在消息发送到其他节点前将消息保存到WAL中、调用传输器发送消息；
raft是raft协议的承载者；
raftLog用于存储状态机信息：memoryStorge保存稳定的记录，unstable保存不稳定的记录。