我们先了解整个 raft library 与外界是如何交互的，再从若干场景中去分析代码，理论上场景足够多，就能把代码覆盖全，跟 testcase 一个道理。
一、设计
1. 目标
一般开发一个系统或第三方库时，需要先确定对外暴露的接口，即如何与外界交互。
而确定对外暴露的接口，需要先确定其在整个系统中的职责与边界。
想象 ETCD 的核心业务功能只是简单的 KV 存储， 提供 Key 的 put、get、delete，结构如下图表示
那么我们需要怎么封装 raft library 才能支撑起该功能？或者说以上哪些内容需要封装到 raft library ？
2. 方案
ETCD如上图所示封装了 raft library ，
raft library 封装了整个 raft 状态机 的运作 <==> 每个使用了 raft library 的服务，成为了 raft 状态机 里的节点
需要特别注意的是，
- raft library 只封装了图中的 应用层的交互（接口、返回）、 raft状态机处理（数据同步、选举、节点变更、心跳等）
- 数据传输 则封装在另一个组件 rafthttp.Transport 中
一条 put(k, v) 其流程可以简单地理解为如下
- Leader 应用层 在 put(k, v) 前， 通知其 raft library 要执行的操作
- Leader 的 raft library 和 其他 Follower 的 raft library 协商一致
- Leader 的 raft library 通知其应用层协商结果，应用层真正执行 put(k, v)
- Leader 的 raft library 通知其他 Follower 的 raft library
- 其他 Follower 的 raft library 通知其应用层，应用层真正执行 put(k, v)
二、代码分析
raft library 所有的代码都在 etcd/raft 包下
raft library 在源码文件 etcd/raft/node.go 定义了一个接口 Node， 用于表示图中所示的 raft-node-N
归纳一下，提供了以下几类方法（代码中很多bean，都直接用了protobuf，没再独立隔离一层）
1. 周期性的执行任务
Tick()
leader 需要周期性地给 follower 发心跳包
follower 需要周期性地判断一下 接收的心跳包有无超时，有则发起新一轮选举
所以不管是 leader 还是 follower，都需要周期性的执行任务
实际运行时，应用层会提供一个定时任务，然后到点自动执行该接口，
即 Node 只提供具体的任务执行，而触发时点交由应用层控制
2. 暴露给应用层的接口
//应用层调用该接口触发选举，但好像除了 testcase 没看到有嘛其他地方调用
Campaign(ctx context.Context) error
//应用层调用该接口向 raft 状态机 提交一条提案，比如Put、Delete
Propose(ctx context.Context, data []byte) error
//应用层调用该接口向 raft 状态机 提交一条配置变更提案，比如增加节点、删除节点
ProposeConfChange(ctx context.Context, cc pb.ConfChange) error
//换leader
TransferLeadership(ctx context.Context, lead, transferee uint64)
//应用层读取数据之前，会调用该接口，
//返回目前可以读的数据Index，即协商一致的最新提案Index
ReadIndex(ctx context.Context, rctx []byte) error
//这个我还没看咯
ApplyConfChange(cc pb.ConfChange) *pb.ConfState
3. 数据返回 ready chan
Ready() <-chan Ready
上述所列的，暴露给应用层的接口，都只有返回 error，没有返回 业务数据，这是因为采用的是异步的方式，
应用层调用接口后，直接结束，然后开始监控读取 ready chan，（这边有可能在同一个线程堵塞读取，有可能请求直接结束，然后在别的线程堵塞读取）
raft library 处理之后，再将结果写入 ready chan (ready 是一个 struct，后续再详细介绍)
4. Advance
// Advance notifies the Node that the application has saved progress up to the last Ready.
// It prepares the node to return the next available Ready.
//
// The application should generally call Advance after it applies the entries in last Ready.
//
// However, as an optimization, the application may call Advance while it is applying the
// commands. For example. when the last Ready contains a snapshot, the application might take
// a long time to apply the snapshot data. To continue receiving Ready without blocking raft
// progress, it can call Advance before finishing applying the last ready.
Advance()
应用层消费完 ready chan 数据之后，要告诉 raft 状态机 可以继续下一步的处理，需要调用该接口通知 raft 状态机
其实这么解释，还是很茫然，所谓的 “继续下一步的处理” 具体指的是神马处理，这个笔者一开始看源码的注释时也是很懵。
后续在具体的场景再详细介绍，这边为了控制篇幅，就不做过多的解释了。
5. 暴露给传输层的接口
Step(ctx context.Context, msg pb.Message) error
如上图所示，节点之间需要进行数据传输，消息接收方会调用该接口，把消息传入 raft 状态机，进行处理
这是接收方调用的接口，那发送方呢？ (发送方如何告知传输方有哪些数据要传输)
这边也是通过 ready chan，实际运行时，会将要发送的消息写至 etcd/raft/raft.go:raft.msgs []pb.Message，再写到 ready chan
type Ready struct {
...
// Messages specifies outbound messages to be sent AFTER Entries are
// committed to stable storage.
// If it contains a MsgSnap message, the application MUST report back to raft
// when the snapshot has been received or has failed by calling ReportSnapshot.
Messages []pb.Message
...
}
6. 其他辅助接口
//获取当前 raft 状态机 明细的状态
Status() Status
ReportUnreachable(id uint64)
ReportSnapshot(id uint64, status SnapshotStatus)
//如字面的意思，节点下线
Stop()
接口 Node 定义了以下内容
- 暴露给应用层的API，Propose、ProposeConfChange 等
- 暴露给应用层的数据返回，Ready()
- 还有一些其他方法
但是没有定义与 数据传输 的交互，这个很诡异，实际上是放在了 etcd/raft/raft.go:raft.msgs []pb.Message
