4. Raft在etcd中的实现：核心模块与工程化细节

etcd 对 Raft 协议的实现并非简单照搬，而是针对生产环境的高可用、高性能需求进行了大量工程化改造。核心代码集中在 raft/raft.go 和 raft/node.go 两个文件中，分别对应 Raft 状态机的核心逻辑与上层驱动接口。

4.1 整体架构：从 Node 到 Raft 状态机

etcd 的 Raft 实现采用分层设计，上层应用（如 etcdserver）通过 Node 接口与底层 Raft 状态机交互，底层状态机则负责处理日志复制、选举和持久化。

4.2 raft.go：Raft 状态机的核心实现

raft.go 是 Raft 算法的纯逻辑实现，不依赖任何 I/O 或并发原语。其核心数据结构是 raft 结构体，包含以下关键字段：

4.3 核心流程：Step 函数与消息驱动

Raft 状态机采用消息驱动模型，所有外部事件（收到消息、超时、提案）都通过 Step() 方法进入状态机。Step 函数根据当前角色和消息类型分发到对应的处理函数：

// raft.go 简化版 Step 函数
func (r *raft) Step(m pb.Message) error {
    switch m.Type {
    case pb.MsgHup:
        // 选举超时触发
        r.campaign()
    case pb.MsgVote, pb.MsgVoteResp:
        // 投票消息
        r.handleVote(m)
    case pb.MsgProp:
        // 客户端提案
        r.handleProposal(m)
    case pb.MsgApp, pb.MsgAppResp:
        // 日志复制
        r.handleAppendEntries(m)
    case pb.MsgSnap:
        // 快照传输
        r.handleSnapshot(m)
    case pb.MsgHeartbeat, pb.MsgHeartbeatResp:
        // 心跳
        r.handleHeartbeat(m)
    case pb.MsgTimeoutNow:
        // 预投票超时
        r.handleTimeoutNow(m)
    }
    return nil
}

4.4 node.go：异步驱动与线程安全封装

node.go 是 Raft 状态机与外部世界的桥梁。它封装了 raft 结构体，提供线程安全的异步接口，并通过 channel 与上层应用通信。

Node 接口定义：

// node.go 核心接口
type Node interface {
    // 提交提案
    Propose(ctx context.Context, data []byte) error
    // 提交配置变更
    ProposeConfChange(ctx context.Context, cc pb.ConfChange) error
    // 步进驱动，接收消息
    Step(ctx context.Context, m pb.Message) error
    // 返回 Ready 通道，应用层从中读取待处理事件
    Ready() <-chan Ready
    // 通知状态机已处理完 Ready 数据
    Advance()
    // 应用快照
    ApplyConfChange(cc pb.ConfChange) *pb.ConfState
    // 返回当前状态
    Status() Status
    // 报告不可恢复错误
    ReportUnreachable(id uint64)
    // 报告快照已应用
    ReportSnapshot(id uint64, status SnapshotStatus)
    // 停止节点
    Stop()
}

4.5 Ready 结构体：状态机与应用的同步契约

etcd 通过 Ready 结构体实现状态机与上层应用之间的批量同步。每次调用 Advance() 后，状态机生成一个新的 Ready 实例，包含需要应用层处理的所有数据：

4.6 日志存储：unstable 与 storage 两层设计

etcd 的日志存储采用两层架构，兼顾内存访问速度和持久化可靠性：

• unstable (不稳定存储)： 位于 raftLog.unstable，存储尚未持久化的日志条目。这些条目在写入 WAL 并调用 Advance() 后会被清空。
• storage (稳定存储)： 由应用层实现（通常基于 WAL + 内存索引），存储已持久化的日志。etcd 默认使用 raftstorage 包提供的实现。

// raft.go 中 raftLog 结构体
type raftLog struct {
    // 存储已持久化的日志（应用层实现）
    storage Storage
    // 存储尚未持久化的日志
    unstable unstable
    // 已提交的最大索引
    committed uint64
    // 已应用到状态机的最大索引
    applied uint64
}

// unstable 结构体
type unstable struct {
    // 快照数据（如果有）
    snapshot *pb.Snapshot
    // 日志条目缓冲区
    entries []pb.Entry
    // entries 中第一条日志的索引偏移
    offset uint64
}

4.7 Progress 跟踪：Leader 对 Follower 的进度管理

Leader 节点通过 Progress 结构体跟踪每个 Follower 的日志复制进度，这是实现流水线复制和批量发送的基础：

三种进度状态：

• Probe： 初始状态或发生冲突时，每次只发送一条日志，等待确认后再发送下一条。
• Replicate： 日志复制正常时，批量发送多条日志，实现流水线优化。
• Snapshot： Follower 落后太多，需要发送快照进行追赶。

4.8 工程化优化总结

etcd 在实现 Raft 协议时做了以下关键工程化改造：