基于Raft分布式Kv存储：leaderHeartBeatTicker

源码里的准确名字是leaderHearBeatTicker()。它是Leader 的周期性调度器控制什么时候启动下一轮心跳或日志复制真正构造AppendEntries、发送快照和处理各节点复制进度的是doHeartBeat()。Raft 要求 Leader 定期向所有 Follower 发送AppendEntries没有新日志时它就是空心跳用来防止 Follower 选举超时。整体结构源码可以简化成void Raft::leaderHearBeatTicker() { while (true) { while (m_status ! Leader) { sleep(HeartBeatTimeout); } lock(); wakeTime now(); remaining HeartBeatTimeout m_lastResetHearBeatTime - wakeTime; unlock(); if (remaining 1ms) { sleep(remaining); } if (heartbeat_was_reset_after(wakeTime)) { continue; } doHeartBeat(); } }项目将心跳间隔配置为25ms选举超时随机范围配置为300500ms。也就是说在正常情况下一个选举超时区间内大约有 1220 次心跳机会。一、最外层无限循环while (true)Ticker 与 Raft 节点生命周期一致。它不会完成一次心跳就退出而是永久执行等待成为 Leader → 等到下一次心跳截止时间 → 调用 doHeartBeat → 重新计算下一次截止时间节点可能经历Follower → Candidate → Leader → Follower → Leader所以 Ticker 不能只在第一次成为 Leader 时运行一次。二、非 Leader 时轮询等待while (m_status ! Leader) { usleep(1000 * HeartBeatTimeout); }Follower 和 Candidate 不应该主动发送 Leader 心跳因此代码每隔25ms检查一次角色。这里的换算是HeartBeatTimeout 25ms usleep 参数单位 微秒 1000 × 25 25000μs 25ms如果节点一直是 Follower这个循环会一直执行当sendRequestVote()获得多数票并把状态改为 Leader内部循环结束。这是一种简单的轮询设计。代价是非 Leader 节点仍然每25ms醒来一次更合适的工程实现通常会用条件变量在角色变成 Leader 时主动唤醒 Ticker。三、为什么不直接睡固定 25ms代码没有简单地写sleep(25ms); doHeartBeat();而是计算suitableSleepTime milliseconds(HeartBeatTimeout) m_lastResetHearBeatTime - wakeTime;把它重新排列下一次截止时间 上次心跳时间 心跳间隔 还需等待时间 下一次截止时间 - 当前时间即deadline lastReset 25ms remaining deadline - now这样心跳周期以“上次实际触发心跳的时间”为基准不会简单地从 Ticker 本轮开始时间重新计算。四、 正常时间示例假设上次心跳时间1000ms 心跳间隔 25ms 当前时间 1010ms计算得到截止时间 1000 25 1025ms 剩余时间 1025 - 1010 15msTicker 再睡15ms然后在约1025ms调用doHeartBeat();doHeartBeat()完成一轮请求构造和分发后会执行m_lastResetHearBeatTime now();下一轮继续以这个新时间为起点。五、 Ticker 已经晚了怎么办假设上次心跳时间1000ms 心跳截止时间1025ms 当前时间 1032ms此时remaining 25 1000 - 1032 -7ms代码只有在剩余时间大于约1ms时才睡眠因此这里不再等待直接调用doHeartBeat()。这可以处理线程调度延迟 互斥锁竞争 进程短暂停顿 前面的代码执行过久但它不会补发错过的每一次心跳。例如错过了三个周期也只会立即发送一轮然后从新的发送时间重新计时。六、wakeTime的作用wakeTime是本轮计算开始时的时间快照wakeTime now();Ticker 睡眠期间另一个路径可能已经调用了doHeartBeat()。例如Candidate 刚获得多数票 → sendRequestVote 将它改为 Leader → 启动线程立即调用 doHeartBeat与此同时leaderHearBeatTicker()也可能发现节点已经成为 Leader并开始计时。如果另一个线程先发送心跳它会更新m_lastResetHearBeatTimeTicker 睡醒后检查m_lastResetHearBeatTime wakeTime如果成立表示从我开始本轮等待之后其他线程已经发送过一轮心跳。于是执行continue;重新根据最新心跳时间计算而不是紧接着再发送一轮重复心跳。七、 为什么叫“重置心跳计时器”这里并没有真正的系统 Timer 对象所谓“重置”只是更新时间戳m_lastResetHearBeatTime now();Ticker 每次根据这个时间戳计算截止时间因此修改时间戳就等价于重新启动定时器旧截止时间 旧 lastReset 25ms 新截止时间 新 lastReset 25ms这个设计和electionTimeOutTicker()很相似只是选举超时300500ms每轮随机 心跳间隔固定25ms八、doHeartBeat()会再次检查角色Ticker 在等待期间Leader 可能收到更高任期的响应并退回 Follower。可能出现Ticker 看到 status Leader → 开始睡眠 → 收到更高任期消息变成 Follower → Ticker 睡醒 → 调用 doHeartBeatdoHeartBeat()自己会持锁并再次判断if (m_status Leader) { // 才真正发送 }因此即使 Ticker 的角色判断已经过期也不会以 Follower 身份构造 Leader RPC九、 Ticker 触发的不只是空心跳leaderHearBeatTicker()名字容易让人误以为它只发送空包。实际上它调用的doHeartBeat()是整个复制调度入口。对每个 FollowernextIndex lastSnapshotIncludeIndex → leaderSendSnapShot() → InstallSnapshot RPC nextIndex lastSnapshotIncludeIndex → sendAppendEntries() → AppendEntries RPC而AppendEntries中entries 为空 → 纯心跳 entries 不为空 → 日志复制所以这个 Ticker 同时驱动维持 Leader 权威 阻止 Follower 超时 复制新日志 修复日志冲突 推进 commitIndex 向严重落后的节点发送快照十、时间从“发送”还是“回复”开始计算源码在doHeartBeat()创建完各个发送线程之后就更新m_lastResetHearBeatTime now();它不会等待所有 Follower 回复。因此心跳周期是本轮 RPC 开始分发 → 等待25ms → 下一轮 RPC 开始分发而不是本轮所有RPC完成 → 等待25ms → 下一轮开始这能避免一个慢 Follower 拖延其他节点的心跳但也意味着 RPC 如果超过25ms同一个 Follower 可能同时存在多轮尚未完成的AppendEntries。源码通过任期检查和max(matchIndex, ...)部分抵抗乱序回复但旧失败响应仍可能让nextIndex回退工程上更适合为每个 Follower 设置独立复制任务保证单节点方向上的 RPC 串行化。(raw.githubusercontent.com)