3. Raft日志复制：Log Entry结构、AppendEntries RPC、日志匹配与一致性检查

日志复制是Raft协议的核心数据路径，也是etcd性能压测中最容易暴露瓶颈的环节。本节从Log Entry的磁盘/内存结构出发，逐步拆解AppendEntries RPC的完整生命周期，并深入日志匹配（Log Matching）与一致性检查（Consistency Check）的数学原理，为后续压测场景中的延迟抖动、吞吐拐点、Leader切换等异常现象提供底层分析依据。

3.1 Log Entry结构

每个Log Entry在Raft中是一个不可变的数据单元，etcd在实现时将其映射为raftpb.Entry结构体。一个Entry包含以下核心字段：

etcd在内存中维护一个不压缩的日志切片（raftLog.entries），每个元素指向一个Entry。日志从Index=1开始编号，Index=0保留为虚拟的快照占位符。日志的物理存储（WAL）与内存结构保持最终一致，但WAL采用预写日志格式，按Term和Index顺序追加。

3.2 AppendEntries RPC

AppendEntries是Leader向Follower复制日志的唯一RPC接口。它既是心跳载体，也是日志推送通道。一次完整的AppendEntries RPC包含以下请求参数和响应字段：

下图展示了AppendEntries RPC在Leader与Follower之间的完整交互流程，包含一致性检查失败时的回退机制：

3.3 日志匹配与一致性检查

日志匹配（Log Matching）是Raft保证日志一致性的核心机制，它基于一个简单的归纳性质：如果两个日志在相同Index位置拥有相同Term，那么这两个日志从起始位置到该Index的所有内容都相同。这个性质通过AppendEntries RPC中的PrevLogIndex和PrevLogTerm检查来维持。

一致性检查的具体步骤可以归纳为以下流程：

1. Term检查：Follower收到AppendEntries请求后，首先比较请求中的Term与自己的currentTerm。如果请求Term更小，直接拒绝并返回自己的Term。
2. 日志存在性检查：Follower检查自己的日志中是否存在Index = PrevLogIndex的条目。如果不存在（日志太短），返回ConflictIndex = len(log)，ConflictTerm = None。
3. Term匹配检查：如果PrevLogIndex存在，但该位置的Term与请求中的PrevLogTerm不匹配，Follower返回ConflictTerm = log[PrevLogIndex].Term，以及该Term在日志中第一次出现的Index作为ConflictIndex。
4. Leader回退：Leader收到失败响应后，根据ConflictIndex和ConflictTerm快速回退自己的nextIndex，避免逐条递减的低效行为。

下图展示了Leader在一致性检查失败后，如何利用ConflictTerm进行快速回退的算法逻辑：

3.4 日志复制性能模型

从压测角度，日志复制的端到端延迟可以分解为以下公式：

端到端延迟 = 客户端→Leader网络RTT
           + Leader本地Propose延迟（序列化+写入内存队列）
           + Leader磁盘fsync延迟（WAL写入）
           + 并行AppendEntries RPC延迟（到多数派Follower）
           + 多数派Follower磁盘fsync延迟
           + Follower→Leader响应网络RTT
           + Leader本地Commit处理延迟（更新commitIndex+应用状态机）

其中，并行AppendEntries RPC延迟由最慢的多数派Follower决定，这是Raft协议固有的性能瓶颈。在压测中，可以通过以下指标量化每个环节：

3.5 一致性检查的压测验证方法

在压测环境中，可以通过以下步骤主动触发一致性检查失败，验证集群的恢复行为：

1. 制造日志不一致：使用etcdctl snapshot restore在某个Follower上恢复一个旧快照，使其日志落后于Leader。
2. 观察回退行为：启动该Follower并加入集群，监控etcd_server_leader_log_entries_exported_total指标，该指标会因日志重传而飙升。
3. 测量恢复时间：记录从Follower加入集群到其committed_index追上Leader的时间，该时间与日志差距大小和网络带宽成正比。
4. 压测负载影响：在持续写入压测中重复上述步骤，观察正常请求的P99延迟是否因日志重传而出现毛刺。