ETCD 源码学习--Raft 提案消息的旅程(十二)

在 ETCD 源码学习过程，不会讲解太多的源码知识，只讲解相关的实现机制，需要关注源码细节的朋友可以自行根据文章中的提示，找到相关源码进行学习。

消息的来源主要有两种，一个是终端的API请求，另个一是节点内部自动发起的消息，比如心跳。而不同消息类型的处理已经在前面的文章中说明，这里不再累赘，本文只介绍一个提案消息发送到 Leader 节点直到被节点应用的流程。

主要流程

1.将提交消息传递到底层 Node 处理（/ectdserver/v3_server.go）。

(1) 终端调用API，设置新键值对，节点 的 Server 接收到请求，执行对应操作 PUT。

(2) 执行 raftRequest 。

(3) 执行 raftRequestOnce。

(4) 执行 processInternalRaftRequestOnce，调用 Propose 将消息传递给 node 模块。

2.Node 对消息处理（/raft/node.go）。

(1) Propose 将消息封装，设置消息类型为 MsgProp，最终由 stepWithWaitOption 进行处理。

(2) stepWithWaitOption  将消息推入 propc  管道，等待被 node 的 后台 goroutine 处理。

(3) run() 是 node 的一个后台goroutine，用于处理各种消息。propc 管道的消息将被交给底层 Raft 模块 Step 方法处理。

3.底层 Raft 对消息处理（/ratf/raft.go）。

(1) Step 方法会根据当前节点的状态和消息类型的不同，调用相应的方法进行处理（这里的场景是 Leader 、提案消息）。

(2) Step 中 step 指向 stepLeader， 所以最终消息会被 stepLeader 处理。

(3) stepLeader 中对消息进行检查，过滤等操作，并将消息集合 entries 追加到 raftlog 的 unstable 中进行临时存储。

(4) 调用 bcastAppend 将消息广播给其他节点。

(5) 广播的最终目的是将同一份消息，生成与节点数量相等副本，并设置目标的节点ID （上层模块根据目标节点ID，发送到目标节点），然后追加到 msgs 管道中，然后等待上层模块处理。

4.Node 对 msgs 管道消息的处理（/raft/node.go）。

(1) run 通过 HasReady 函数检查是否 msgs 管道是否有待处理的消息。

(2) 如果有，调用 newReady 将 msgs 内的消息 封装成 ready 实例。

(3) 将封装的 ready 实例推入 readyc 管道中，等待上层 raftNode 处理，并将 msgs 置空。

4.RaftNode 对 ready 实例的处理 （/etcdserver/raft.go）。

(1) start 作为 raftNode 后台运行的实例处理各种消息。

(2) 调用 node.Ready 判断是否有需要处理的 ready 实例

(3) 根据 ready 不同的消息类型进行处理，比如 CommittedEntries、Snapshot 会封装成 Apply 实例发送到 applyc 管道等待被 server 应用。而 Entries 会被持久化（等待被应用的消息），而 Messages  (对应 msgs 消息)，调用 Transport.send 发送到目标节点。这里要说明是提案消息是不会立即被应用的 server 中，只有当过半的节点响应之后，才会被转化成 CommittedEntries，最终被服务应用。而Transport 如何发送消息，将在后面的章节说明。

5.server 对 apply 实例的处理（/etcdserver/server.go）

(1) run 函数会接收 applyc 中的消息，并应用到服务中，至此，一个提案消息结束了它的旅程。

总结

1.消息主要流程：是 client->httpServer->node->raft->node->raftNode->server

2.存储：Leader 节点接收到 一个提案消息，首先会先存储在 unstable 中，然后 raftNode 进行持久化同时保持在 stable 中。

3.提案消息应用过程：一个提案消息是不会马上被应用到节点，只有当有过半节点响应之后，消息才会被转化成 CommittedEntries 消息，然后被 server 应用。

 

PS：欢迎纠正