raft 写请求源码走读

---

0. 概述

在上一篇文章中介绍了 raft 读请求源码走读，本文继续结合 etcd-raft 源码介绍 raft 写请求流程。

需要说明的是，本文使用的是单节点集群环境，后续会补充多节点集群环境加以介绍。

1. 写请求流程

1.1 客户端写入请求

客户端通过 PUT 请求写入键值对请求：

curl -L http://127.0.0.1:12380/my-key -XPUT -d hello

该请求被 httpKVAPI 处理：

func (h *httpKVAPI) ServeHTTP(w http.ResponseWriter, r *http.Request) {  
    key := r.RequestURI  
    defer r.Body.Close()  
    switch r.Method {  
    case http.MethodPut:                // 匹配 PUT 方法，处理写请求
       v, err := io.ReadAll(r.Body)  
       if err != nil {  
          log.Printf("Failed to read on PUT (%v)\n", err)  
          http.Error(w, "Failed on PUT", http.StatusBadRequest)  
          return  
       }  
  
       h.store.Propose(key, string(v))  // 调用 h.store.Propose 提交该请求
	   w.WriteHeader(http.StatusNoContent)
    }
    ...
}

func (s *kvstore) Propose(k string, v string) {  
    var buf strings.Builder  
    if err := gob.NewEncoder(&buf).Encode(kv{k, v}); err != nil {  
       log.Fatal(err)  
    }  
    s.proposeC <- buf.String()  
}

httpKVAPI.ServeHTTP 的重点在于 httpKVAPI.store.Propose 方法。该方法的作用是将写请求键值对编码后写入 kvstore.proposeC 通道。

那么谁在消费 proposeC 呢？

1.2 应用层消费 proposeC

应用层 raftNode 消费客户端写入 proposeC 的写请求。

首先查看 raftNode 的启动流程及整体结构。

1.2.1 raftNode 启动流程

在 main.go 中 newRaftNode 会创建应用层 RaftNode 节点：

func main() {
	...
	proposeC := make(chan string)  
	defer close(proposeC)  
	confChangeC := make(chan raftpb.ConfChange)  
	defer close(confChangeC)
	
	var kvs *kvstore  
	getSnapshot := func() ([]byte, error) { return kvs.getSnapshot() }  
	
	// 创建 RaftNode 节点，并且将客户端写入的 proposeC 作为参数传递给 newRaftNode
	commitC, errorC, snapshotterReady := newRaftNode(*id, strings.Split(*cluster, ","), *join, getSnapshot, proposeC, confChangeC)
	...
}

func newRaftNode(id int, peers []string, join bool, getSnapshot func() ([]byte, error), proposeC <-chan string,  
    confChangeC <-chan raftpb.ConfChange,  
) (<-chan *commit, <-chan error, <-chan *snap.Snapshotter) {  
    commitC := make(chan *commit)  
    errorC := make(chan error)  
  
    rc := &raftNode{  
       proposeC:    proposeC,       // proposeC 传入 raftNode
       ... 
    }  
    go rc.startRaft()  
    return commitC, errorC, rc.snapshotterReady  
}

创建 raftNode 后，调用 raftNode.startRaft 方法启动一个协程异步运行 startRaft 方法：

func (rc *raftNode) startRaft() {  
    ...
    go rc.serveRaft()        // 启动协程监听 raft api
    go rc.serveChannels()    // 启动协程监听 raftNode 的通道
}

重点介绍 raft.serveChannels 方法：

func (rc *raftNode) serveChannels() {  
    ... 
  
    // send proposals over raft  
    go func() {  
       confChangeCount := uint64(0)  
  
       for rc.proposeC != nil && rc.confChangeC != nil {  
          select {  
          case prop, ok := <-rc.proposeC:      // 在这里消费 proposeC 的写请求键值对
             if !ok {  
                rc.proposeC = nil  
             } else {  
                // blocks until accepted by raft state machine  
                rc.node.Propose(context.TODO(), []byte(prop))  
             }    
          }  
       }  
       // client closed channel; shutdown raft if not already  
       close(rc.stopc)  
    }()  
  
    // for-select 事件循环 
    for {  
       select {  
       case <-ticker.C:  
          rc.node.Tick()  
  
       // store raft entries to wal, then publish over commit channel  
       case rd := <-rc.node.Ready():  
          ...
       }  
    }  
}

在 serveChannels 中应用层 raftNode 从 proposeC 中消费写请求。

如果 proposeC 关闭将 proposeC 设为 nil 不允许写入。

如果正常读取写请求，则进入 raftNode.node.Propose 处理。

raftNode 组合 node 对象，node 是算法层的入口，通过提供的一系列方法暴露给应用层调用。Propose 即为暴露的其中一个方法。

1.2.2 算法层处理写请求

1.2.2.1 算法层初始化流程

为了介绍逻辑的完整性，这里有必要在进入 raftNode.startRaft 方法查看算法层 node 是如何创建的：

func (rc *raftNode) startRaft() {
	...

	c := &raft.Config{  
	    ID:                        uint64(rc.id),  
	    ElectionTick:              10,  
	    HeartbeatTick:             1,  
	    Storage:                   rc.raftStorage,  
	    MaxSizePerMsg:             1024 * 1024,  
	    MaxInflightMsgs:           256,  
	    MaxUncommittedEntriesSize: 1 << 30,  
	}  
	  
	if oldwal || rc.join {  
	    rc.node = raft.RestartNode(c)  
	} else {  
	    // 首次创建 raftNode.node
	    rc.node = raft.StartNode(c, rpeers)  
	}
	...
}

func StartNode(c *Config, peers []Peer) Node {  
    n := setupNode(c, peers)  
    go n.run()  
    return n  
}	

在 raft.StartNode(或 raft.RestartNode) 创建 raftNode.node 对象。实际是异步启了一个协程运行 node.run 方法。

1.2.2.2 node.Propose 处理写请求提交

上一节创建 node后，应用层调用 raftNode.node.Propose 方法提交写请求到算法层：

func (n *node) Propose(ctx context.Context, data []byte) error {  
	// 将写请求数据封装为 Entry，将 Entry 封装为 Message
    return n.stepWait(ctx, pb.Message{Type: pb.MsgProp, Entries: []pb.Entry{{Data: data}}})  
}

func (n *node) stepWait(ctx context.Context, m pb.Message) error {  
	// 等待提交写请求处理完成
    return n.stepWithWaitOption(ctx, m, true)  
}

func (n *node) stepWithWaitOption(ctx context.Context, m pb.Message, wait bool) error {  
    ...
    ch := n.propc  
    pm := msgWithResult{m: m}    // 将 Message 封装为 msgWithResult
    if wait {  
       pm.result = make(chan error, 1)  
    }  
    select {  
    case ch <- pm:               // 将 msgWithResult 写入 node.propc 通道
       if !wait {  
          return nil  
       }  
    case <-ctx.Done():  
       return ctx.Err()  
    case <-n.done:  
       return ErrStopped  
    }  
    select {  
    case err := <-pm.result:     // 等待 msgWithResult.result 返回结果
       if err != nil {  
          return err  
       }  
    ...
    }  
    return nil  
}

算法层 node.Propose 将数据封装为 msgWithResult 发给 node.propc 通道，并且监听 msgWithResult.result 通道等待返回结果。

那么 msgWithResult 的数据是在哪里消费的呢？

1.2.2.3 消费 msgWithResult

在 1.2.2.1 算法层初始化流程 介绍了创建 node 对象后会异步启动 node.run 协程，这里继续看协程内部在做什么：

func (n *node) run() {  
    var propc chan msgWithResult  
    var readyc chan Ready  
    var advancec chan struct{}  
    var rd Ready  
  
    r := n.rn.raft  
    lead := None  
  
    for {  
       ... 
       if lead != r.lead {  
          if r.hasLeader() {  
             if lead == None {  
                r.logger.Infof("raft.node: %x elected leader %x at term %d", r.id, r.lead, r.Term)  
             } else {  
                r.logger.Infof("raft.node: %x changed leader from %x to %x at term %d", r.id, lead, r.lead, r.Term)  
             }  
             // 如果集群有 leader 则将 node.propc 赋给 propc
             // 意味着只在有 leader 的情况下处理写请求提交
             propc = n.propc  
          } else {  
             r.logger.Infof("raft.node: %x lost leader %x at term %d", r.id, lead, r.Term)  
             // 如果集群无 leader 将 propc 设为 nil
             // 意味着无 leader 时不会处理写请求提交
             propc = nil  
          }  
          lead = r.lead  
       }  
  
       select {      
       case pm := <-propc:     // 从 node.propc 中读取 msgWithResult 对象
          m := pm.m            // 获取消息
          m.From = r.id        // 消息是在同一个 raft 节点处理的，将 m.From 设为当前 raft 节点的 id
          err := r.Step(m)     // 调用 raft.Step 处理消息
          if pm.result != nil {  
             pm.result <- err  
             close(pm.result)  
          }  
       ... 
       }  
    }  
}

node.run 消费 node.propc，并且调用 raft.Step 处理消费的消息：

func (r *raft) Step(m pb.Message) error {    
    switch {  
    case m.Term == 0:  // 消息的 Term 为 0，表示该消息为本地消息
       // local message  
    case m.Term > r.Term:  
	   ...
    case m.Term < r.Term:  
       ...
    }  
  
    switch m.Type {  
    case pb.MsgHup:  
       ...
    case pb.MsgStorageAppendResp:  
       ...
    case pb.MsgStorageApplyResp:  
       ... 
    case pb.MsgVote, pb.MsgPreVote:  
       ... 
    default:  
       err := r.step(r, m)  // 这里的消息类型为 MsgProp 会进到默认分支
       if err != nil {  
          return err  
       }  
    }  
    return nil  
}

消息的类型为 MsgProp 会进入到 raft.step 方法处理。raft.step 是一个指针函数指向不同角色的 step 处理函数。

根据不同角色有如下几种处理函数。

candidate

候选者 candidate 处理 MsgProp 消息：

func stepCandidate(r *raft, m pb.Message) error {  
    switch m.Type {  
    case pb.MsgProp:  
       r.logger.Infof("%x no leader at term %d; dropping proposal", r.id, r.Term)  
       return ErrProposalDropped
    ...
}

候选者并不能直接处理 MsgProp 写请求的提交消息，如果收到将直接丢弃。

follower

func stepFollower(r *raft, m pb.Message) error {  
    switch m.Type {  
    case pb.MsgProp:  
       if r.lead == None {  
          r.logger.Infof("%x no leader at term %d; dropping proposal", r.id, r.Term)  
          return ErrProposalDropped  
       } else if r.disableProposalForwarding {  
          r.logger.Infof("%x not forwarding to leader %x at term %d; dropping proposal", r.id, r.lead, r.Term)  
          return ErrProposalDropped  
       }  
       m.To = r.lead  
       r.send(m)  
    case pb.MsgApp:  
       ... 
    case pb.MsgHeartbeat:  
       ... 
    case pb.MsgSnap:  
       ...  
    case pb.MsgTransferLeader:  
       ...  
    case pb.MsgTimeoutNow:  
       ...
    }  
    return nil  
}

跟随者 follower 收到 MsgProp 写请求提交消息，会判断当前集群有无 leader。如果有，则调用 raft.send 转发该消息给 leader 处理。如果没有，则丢弃该消息。

leader

func stepLeader(r *raft, m pb.Message) error {    
    switch m.Type {  
    case pb.MsgBeat:  
       .... 
    case pb.MsgCheckQuorum:  
       ... 
    case pb.MsgProp:  
       if len(m.Entries) == 0 {  
          r.logger.Panicf("%x stepped empty MsgProp", r.id)  
       }  
       if r.trk.Progress[r.id] == nil {  
          return ErrProposalDropped  
       }  
       if r.leadTransferee != None {  
          r.logger.Debugf("%x [term %d] transfer leadership to %x is in progress; dropping proposal", r.id, r.Term, r.leadTransferee)  
          return ErrProposalDropped  
       }  
  
       for i := range m.Entries {  
          e := &m.Entries[i]  
          var cc pb.ConfChangeI  
          // Entry 类型为 EntryNormal，不匹配
          if e.Type == pb.EntryConfChange {  
             ... 
          } else if e.Type == pb.EntryConfChangeV2 {  
             ...
          }  
          if cc != nil {  
             ... 
          }  
       }  
  
       // 调用 raft.appendEntry 处理 msgWithResult 的Entry
       if !r.appendEntry(m.Entries...) {  
          return ErrProposalDropped  
       }  
       
       // 广播给 follower 节点处理
       r.bcastAppend()  
       return nil

stepLeader 匹配 MsgProp 消息，并且根据消息中的 Entry.Type 执行不同的处理逻辑。对于 EntryNormal 的 Entry 将调用 raft.appendEntry 处理。

func (r *raft) appendEntry(es ...pb.Entry) (accepted bool) {  
    // 调用 raft.raftLog.lastIndex 获取最近的 index
    li := r.raftLog.lastIndex()  
    
    // 更新 Entry 的 Term 和 Index
    for i := range es {  
       es[i].Term = r.Term  
       es[i].Index = li + 1 + uint64(i)  
    }
    
    // 将 Entry 添加到 raft.raftLog
    // 这里两阶段提交的第一阶段添加的是 raft.raftLog.unstable
    li = r.raftLog.append(es...)  
    
    // 获取最新的 last index 并组成 MsgAppResp 的消息发送
    r.send(pb.Message{To: r.id, Type: pb.MsgAppResp, Index: li})  
    return true  
}

func (l *raftLog) lastIndex() uint64 {  
    // 先从 unstable 获取最近的 index
    if i, ok := l.unstable.maybeLastIndex(); ok {  
       return i  
    }  
    
    // 如果 unstable 获取不到最近的 index 就从 raftLog.storage 获取最近的 index
    i, err := l.storage.LastIndex()  
    if err != nil {  
       panic(err) // TODO(bdarnell)  
    }  
    return i  
}

func (l *raftLog) append(ents ...pb.Entry) uint64 {  
    // 如果 Entry 无数据，则返回
    if len(ents) == 0 {  
       return l.lastIndex()  
    }  
    
    // 如果最新的 Entry index 小于 raftLog.committed 触发 panic
    // 正常情况应该是 raftLog.committed 小于插入的 Entry index
    if after := ents[0].Index - 1; after < l.committed {  
       l.logger.Panicf("after(%d) is out of range [committed(%d)]", after, l.committed)  
    }  
    
    // 将 Entry 插入到 raftLog.unstable
    l.unstable.truncateAndAppend(ents)  
    return l.lastIndex()  
}

在 raft.appendEntry 将 Entry 存入 raftLog.unstable 后调用 raft.send 发送类型为 MsgAppResp 的消息：

func (r *raft) send(m pb.Message) {
	if m.From == None {  
	    m.From = r.id  
	}
	
	if m.Type == pb.MsgVote || m.Type == pb.MsgVoteResp || m.Type == pb.MsgPreVote || m.Type == pb.MsgPreVoteResp {  
	    ...
	}
	
	// m.Type 为 MsgAppResp 匹配当前分支
	if m.Type == pb.MsgAppResp || m.Type == pb.MsgVoteResp || m.Type == pb.MsgPreVoteResp {
	r.msgsAfterAppend = append(r.msgsAfterAppend, m)  
	...
}

raft.send 方法处理 MsgAppResp 类型的消息是往 raft.msgsAfterAppend 数据中存入该消息。

存入 raft.msgsAfterAppend 后 node.run 将执行结果传递到 msgWithResult.result 通道内，该结果会被 node.Propose 消费：

func (n *node) run() {
	...
	select {  
	case pm := <-propc:  
	    m := pm.m  
	    m.From = r.id  
	    err := r.Step(m)  
	    if pm.result != nil {  
	       pm.result <- err  
	       close(pm.result)  
	    }
	    ...
	}
	...
}

func (n *node) stepWithWaitOption(ctx context.Context, m pb.Message, wait bool) error {  
    ... 
    select {  
    case err := <-pm.result:  // 消费 pm.result 并返回
       if err != nil {  
          return err  
       }  
    case <-ctx.Done():  
       return ctx.Err()  
    case <-n.done:  
       return ErrStopped  
    }  
    return nil  
}

1.2.2.4 ready 消息

通过上一节的描述 node.Propose 的交互就完成了。node.Propose 作为算法层的入口将 Propose 请求封装成消息发送给 node.run 处理，node.run 将消息（Entry）添加到 raftLog.unstable 中暂存，然后将请求数据封装为 MsgAppResp 类型的消息添加到 raft.msgsAfterAppend 数组。

本小节继续看这里为什么要添加到 raft.msgsAfterAppend 数组。

进入 node.run ：

// node.run 是一个不退出循环
func (n *node) run() {  
    var propc chan msgWithResult  
    var readyc chan Ready  
    var advancec chan struct{}  
    var rd Ready  
  
    r := n.rn.raft  
  
    lead := None  
  
    for {  
	   // 进入 node.rn.HasReady
       if advancec == nil && n.rn.HasReady() {  
          rd = n.rn.readyWithoutAccept()  
          readyc = n.readyc  
       }
       ...
    }
    ...
}

func (rn *RawNode) HasReady() bool {  
    ...
    // 通过 raft.msgAfterAppend 判断是否 ready
    if len(r.msgs) > 0 || len(r.msgsAfterAppend) > 0 {  
       return true  
    }  
    ... 
    return false  
}

可以看到，RawNode.HasReady 通过 raft.msgAfterAppend 判断是否 ready。并且，这里的 advancec 通道并未创建，为 nil。此时，程序会走到 node.rn.readyWithoutAccept：

func (rn *RawNode) readyWithoutAccept() Ready {  
    r := rn.raft  
  
    rd := Ready{  
       // 获取 raft.raftLog.unstable 中的 Entry
       Entries:          r.raftLog.nextUnstableEnts(),  
       CommittedEntries: r.raftLog.nextCommittedEnts(rn.applyUnstableEntries()),  
       Messages:         r.msgs,  
    }  
    
    ... 
    return rd  
}

node.rn.readyWithoutAccept 主要是构造 Ready 对象，接着在 node.run 中将该对象发到 readyc 通道：

func (n *node) run() {  
    ...
    
    for {
	    select {
	    case readyc <- rd:  // 将 ready 发送到 readyc 通道
	    n.rn.acceptReady(rd)  
	    if !n.rn.asyncStorageWrites {  
	       advancec = n.advancec  // 这里 node.rn.asyncStorageWrites 为 false，会走到这里
	    } else {  
	       rd = Ready{}  
	    }  
	    readyc = nil        // 将 readyc 通道关闭，只读不写
	}
}

在发送 ready 到 readyc 后 node.run 会继续往下处理。此时，readyc 通道另一端也在消费 ready。

我们先往下走，看发完 ready 后 node.run 做了什么？

进入 n.rn.acceptReady:

func (rn *RawNode) acceptReady(rd Ready) {
	...
	// 这里异步写为 false
	if !rn.asyncStorageWrites {
		... 
            // needStorageAppendRespMsg 判断 raftLog.unstable 是否有 Entry
            // 如果有调用 newStorageAppendRespMsg 组消息
	    if needStorageAppendRespMsg(rn.raft, rd) {  
	       m := newStorageAppendRespMsg(rn.raft, rd)  
	       rn.stepsOnAdvance = append(rn.stepsOnAdvance, m)  
	    }  
	    
	    // needStorageApplyRespMsg 判断 ready.CommittedEntries 是否有 Entry
	    // 这里在这个阶段无 CommittedEntries，先跳过
	    if needStorageApplyRespMsg(rd) {  
	       m := newStorageApplyRespMsg(rn.raft, rd.CommittedEntries)  
	       rn.stepsOnAdvance = append(rn.stepsOnAdvance, m)  
	    }  
	}
	...
}

// newStorageAppendRespMsg 组类型为 MsgStorageAppendResp 的消息
func newStorageAppendRespMsg(r *raft, rd Ready) pb.Message {  
    m := pb.Message{  
       Type: pb.MsgStorageAppendResp,  
       To:   r.id,  
       From: LocalAppendThread,   
       Term: r.Term,  
    }
    // 判断 raftLog.unstable 是否有 Entry
    if r.raftLog.hasNextOrInProgressUnstableEnts() { 
       last := r.raftLog.lastEntryID()  
       m.Index = last.index        
       m.LogTerm = last.term       
    }  
    ... 
    return m  
}

基本上发完 ready 后，node.run 会组消息类型为 MsgStorageAppendResp 的消息，并添加到 rn.stepsOnAdvance 数组。

这里留了两个问题：

1. 前面发完 ready 后，哪个组件消费 ready？
2. MsgStorageAppendResp 消息发往数组后，在哪里处理的呢？

首先看第一个问题，发完 ready 后哪个组件消费 ready？

1.2.3 应用层处理 ready

应用层的 raftNode.serveChannels 会监听 readyc 通道，消费 ready：

func (rc *raftNode) serveChannels() {
	...
    // event loop on raft state machine updates  
    for {  
       select {  
       // store raft entries to wal, then publish over commit channel  
       case rd := <-rc.node.Ready():  
          // 首先 raftNode 调用预写日志 WAL 将 rd 的状态和数据写入到磁盘日志
          // 这里写入不成功咋办？好像没有写入不成功的处理？
          rc.wal.Save(rd.HardState, rd.Entries)  
          
          // 将 ready.Entries 添加到 raftNode.raftStorage
          rc.raftStorage.Append(rd.Entries)  
           
          // 调用 raftNode.node.Advance 方法往 advancec 通道发消息
          rc.node.Advance()  
       }  
    }  
}

raftNode 处理 ready 后，此时的状态是预写日志存储 Entries，raftStorage 添加 Entries。最后往 advancec 通道写数据通知算法层。

可以想到算法层的 node.run 会监听 advancec 通道并处理，我们直接进入此处逻辑：

func (n *node) run() {
	...
	for {
		select {
		case <-advancec:  
                    // 重点看 node.rn.Advance
		    n.rn.Advance(rd)  
		    rd = Ready{}  
		    advancec = nil
		}
	}
}

func (rn *RawNode) Advance(_ Ready) {  
    // 在这里对数组做处理，从前面可知此时数组存的是 MsgStorageAppendResp 类型的消息
    for i, m := range rn.stepsOnAdvance {  
       // 调用 raft.Step 状态机处理消息
       _ = rn.raft.Step(m)  
       rn.stepsOnAdvance[i] = pb.Message{}  
    }  
    rn.stepsOnAdvance = rn.stepsOnAdvance[:0]  
}

func (r *raft) Step(m pb.Message) error {
	...
	switch m.Type {
	case pb.MsgStorageAppendResp:  
	    if m.Index != 0 {  
               // 进入 raft.raftLog.stableTo 将 raftLog.unstable 的 Entry 清掉
               // 该 Entry 已经存储到 WAL 和 raftStorage 中了
	       r.raftLog.stableTo(entryID{term: m.LogTerm, index: m.Index})  
	    }  
	...
	}
	return nil
}

raftNode 处理完 ready 消息后，会往 advancec 发消息，通知算法层 ready 消息处理完毕。算法层根据消息类型做不同处理，这里将 raftLog.unstable 中的 Entry 清理掉（这个 Entry 已经存在 raftStorage 和 WAL 中了）。

到这里还没有结束。接下来继续进入 node.run 循环，看算法层和应用层是如何进行第二轮交互的。

1.2.4 算法层和应用层交互

func (n *node) run() {
	...
	for {  
            // 在第一轮算法层-应用层交互后，算法层将 advancec 设为 nil
            // 进入 node.rn.HasReady 判断是否可以组 ready
	    if advancec == nil && n.rn.HasReady() {
                // 和前面第一轮交互类似，这里是组 ready 消息，后续将 ready 发往 readyc 通道
	        rd = n.rn.readyWithoutAccept()  
		    readyc = n.readyc  
		}
}

func (rn *RawNode) HasReady() bool {
	// 这个条件分支将被选中此时的 hardState 和 rn.prevHardState 不一致
	// hardState 的 Commit 大于 rn.prevHardState，意味着需要 Commit Entry
	if hardSt := r.hardState(); !IsEmptyHardState(hardSt) && !isHardStateEqual(hardSt, rn.prevHardSt) {  
	    return true  
	}
}

func (rn *RawNode) readyWithoutAccept() Ready {  
    r := rn.raft  
  
    // 不同于第一轮交互，这里的 CommittedEntries 是要 Commit 给客户端的存储的 Entry 
    rd := Ready{  
       Entries:          r.raftLog.nextUnstableEnts(),  
       CommittedEntries: r.raftLog.nextCommittedEnts(rn.applyUnstableEntries()),  
       Messages:         r.msgs,  
    }
    ...
}

类似于第一轮算法层-应用层交互，这里算法层组 ready 发往应用层。不同的是这里的 Entry 是 CommittedEntry。

算法层发完 ready 后会继续进入 node.run 循环：

func (n *node) run() {
	for {
		select {
		case readyc <- rd:
			n.rn.acceptReady(rd)  
			if !n.rn.asyncStorageWrites {  
			    advancec = n.advancec  
			} else {  
			    rd = Ready{}  
			}  
			readyc = nil
		}
	}
}
	
func (rn *RawNode) acceptReady(rd Ready) {
	if !rn.asyncStorageWrites {
	    // 类似于第一轮算法层-应用层交互，这里组消息类型为 MsgStorageApplyResp 的消息加到 rn.stepsOnAdvance，后续算法层收到 advance 信号后会处理
	    if needStorageApplyRespMsg(rd) {  
	    m := newStorageApplyRespMsg(rn.raft, rd.CommittedEntries)  
	    rn.stepsOnAdvance = append(rn.stepsOnAdvance, m)  
	    }
	}
	...
}

继续看应用层是如何处理 ready 的：

func (rc *raftNode) serveChannels() {
	for {  
	    select {
	    case rd := <-rc.node.Ready():
	    // 重点在 raftNode.publishEntries
	    applyDoneC, ok := rc.publishEntries(rc.entriesToApply(rd.CommittedEntries))  
		if !ok {  
		    rc.stop()  
		    return  
		} 
		rc.node.Advance()
	} 
}

func (rc *raftNode) publishEntries(ents []raftpb.Entry) (<-chan struct{}, bool) {
	data := make([]string, 0, len(ents))  
	for i := range ents {  
	    switch ents[i].Type {  
	    case raftpb.EntryNormal:  
	       // 读取 Commit Entry 中的数据存入 data 
	       if len(ents[i].Data) == 0 {  
	          // ignore empty messages  
	          break  
	       }  
	       s := string(ents[i].Data)  
	       data = append(data, s) 
		}
	}
	
	var applyDoneC chan struct{}  
	  
	if len(data) > 0 {  
	    applyDoneC = make(chan struct{}, 1)  
	    select {  
	    // 将数据和 applyDoneC 通道发给 raftNode.commitC
	    case rc.commitC <- &commit{data, applyDoneC}:  
	    case <-rc.stopc:  
	       return nil, false  
	    }  
	}  
	  
	// commit 后更新 raftNode.appliedIndex 
	rc.appliedIndex = ents[len(ents)-1].Index  
	  
	return applyDoneC, true	
}          

应用层收到 ready 后，组 commit 发往 raftNode.commitC 通道。通道的另一头是客户端在消费：

func (s *kvstore) readCommits(commitC <-chan *commit, errorC <-chan error) {  
    for commit := range commitC {  
       if commit == nil {  
          ... 
          continue  
       }  
  
       for _, data := range commit.data {  
          var dataKv kv  
          dec := gob.NewDecoder(bytes.NewBufferString(data))  
          if err := dec.Decode(&dataKv); err != nil {  
             log.Fatalf("raftexample: could not decode message (%v)", err)  
          }  
          // 将数据（键值对）存储到 kvstore.kvStore 中
          s.mu.Lock()  
          s.kvStore[dataKv.Key] = dataKv.Val  
          s.mu.Unlock()  
       }  
       // 写入成功后，关闭 commit.applyDoneC 通知应用层
       close(commit.applyDoneC)  
    }  
    if err, ok := <-errorC; ok {  
       log.Fatal(err)  
    }  
}

客户端会监听 raftNode.commitC 通道，并将通道内的数据编码存储到 kvStore 中。

至此，写入的流程基本结束了。后续就是应用层和算法层的收尾工作。应用层发往 commit 后，发信号到 advancec，通知算法层 commit 已完成，算法层在做相应处理，这里和第一轮交互有点重复，就不赘述了。

2. 小结

可以看到 raft 的写流程是比较复杂的，涉及客户端/应用层/算法层和多个通道的交互，这里只介绍了个大概，部分比较重要的内容如多节点通信等并未介绍，后续会着重开始走读这方面的内容以及学习 raft 的论文加深理解。

这里给出交互流程图如下：

3. 参考资料

• raft 工程化案例之 etcd 源码实现

---