Raft日志复制核心是Leader主动发起AppendEntries RPC，携带prevLogIndex和prevLogTerm校验日志连续性；RPC失败时Leader需根据Follower返回的lastLogIndex递减nextIndex重试，并正确维护每个Follower的nextIndex和matchIndex。
raft日志复制的核心是AppendEntries RPC的正确实现
日志复制不是靠定时轮询或消息队列，而是由Leader主动向Follower发起AppendEntries RPC来驱动。关键在于每次RPC必须携带准确的prevLogIndex和prevLogTerm，用于让Follower校验日志连续性。如果Follower发现prevLogIndex位置的日志term不匹配，就拒绝该RPC并返回当前lastLogIndex和lastLogTerm——Leader收到后需递减nextIndex重试。
常见错误是Leader未维护每个Follower的nextIndex和matchIndex，导致反复发送已提交日志、或跳过未复制条目。正确做法是：初始化时设nextIndex为leaderLastIndex + 1；每次RPC失败后，用Follower返回的lastLogIndex更新nextIndex = min(nextIndex - 1, lastLogIndex + 1)（注意边界）。
实操建议：
-
AppendEntries请求体必须包含Leader的currentTerm、leaderId、prevLogIndex、prevLogTerm、待追加的entries[]（可为空）、以及leaderCommit - Follower收到后先检查
term：若请求term - 日志冲突检测必须严格：仅当
prevLogIndex≤ Follower日志长度，且对应位置的term ==prevLogTerm才接受追加 - 追加新日志前，要先截断Follower从
prevLogIndex + 1开始的所有后续日志（即“log matching property”保障）
状态机提交必须满足“committed”定义且只提交一次
Raft规定：一条日志条目只有在被存储在**大多数节点**上，并且Leader的commitIndex ≥ 该条目的index时，才被视为committed。注意，这个“大多数”是指当前配置下的多数，不是初始集群大小；配置变更期间要按新旧两套规则分别判断。
立即学习“C++免费学习笔记（深入）”；
常见陷阱是Leader在收到多数Follower的AppendEntries成功响应后，立刻把commitIndex推进到最新复制成功的index——这不对。因为可能刚复制的是一个term较老的日志，而中间有gap。正确方式是：Leader需从lastApplied + 1开始，倒序检查每个index，确认该index的日志term等于当前Leader term，且已被≥ majority个节点复制（即matchIndex[i] ≥ index），才将commitIndex设为该index。
实操建议：
- Leader维护一个数组
matchIndex[n]，记录每个Follower已复制成功的最大log index；每次AppendEntries成功后更新对应项 - 提交逻辑应独立于RPC处理线程，例如在主循环中定期调用
advanceCommitIndex()，避免并发修改commitIndex - 状态机应用（apply）必须严格按index顺序：只允许
lastApplied + 1的日志进入applyToStateMachine()，且应用后立即更新lastApplied - 绝不允许重复apply同一index：可在状态机内部用
appliedIndex做守卫，或由Raft模块保证调用幂等
C++里需要特别注意日志持久化与内存安全的边界
Raft要求日志在AppendEntries返回成功前写入磁盘（或至少fsync），否则节点崩溃后可能丢失已“复制”的日志，破坏安全性。C++没有内置异步刷盘，容易误用std::ofstream直写而不调用flush() + fsync()。
另一个高危点是日志索引与vector下标混用。Raft日志index从1开始，但C++ vector从0开始。若直接用logs[index]访问，会越界或错位。必须统一抽象出LogEntry& getEntry(uint64_t index)，内部做index - 1转换，并检查index > 0 && index 。
实操建议：
- 日志序列化推荐用
flatbuffers或protobuf，避免手写二进制格式；写盘前先序列化到std::string或std::vector<uint8_t></uint8_t>，再用write()+fsync() - 使用
std::shared_ptr<logentry></logentry>管理日志内容，避免深拷贝大消息体；但注意RPC序列化时需解引用获取原始数据 - 所有跨线程访问
logs、commitIndex、lastApplied的地方，必须加锁（如std::shared_mutex读多写少）或用原子变量（仅适用于int64_t类简单字段） - 测试时强制kill进程+重启，验证
readPersistedLogs()能否正确加载最后一条有效日志（注意截断日志文件末尾脏数据）
测试日志复制正确性不能只看“不panic”，要看term和index是否严格守序
很多C++实现跑通单测就认为OK，但真实场景下网络分区、乱序、重复RPC会让日志term出现“空洞”或倒挂。Raft最易被绕过的安全约束是：**一个term内至多一条leader日志**，且所有follower上的日志term序列必须非递减（允许相等，但不能下降）。
验证时不能只比对最终状态机输出，必须dump每个节点的完整日志序列，检查：log[i].term ，且任意<code>log[i].term == t的位置，i必须是该term在该节点上的唯一index（除非是空日志）。
实操建议：
- 在
appendEntry()和installSnapshot()入口加断言：assert(entry.term >= lastLogTerm)（空日志除外） - 写一个离线校验工具，读取各节点
log.dat，输出每条日志的(index, term, type)三元组，人工或脚本比对term单调性 - 用
libfuzzer或自定义故障注入：在AppendEntries发送/接收路径随机丢包、重复、篡改prevLogTerm，观察是否触发becomeFollower()并重置状态 - 特别关注
installSnapshot后的衔接：快照包含lastIncludedIndex和lastIncludedTerm，后续第一条日志的prevLogIndex必须等于它，且prevLogTerm必须匹配——这里极易因off-by-one导致拒绝恢复
真正难的不是实现RPC往返，而是让所有节点在任意故障组合下，仍能收敛到完全一致的commitIndex和lastApplied。任何绕过term比较、跳过prevLog校验、或忽略matchIndex更新的简化，都会在3节点集群跑20小时后暴露。
