源码里的准确名字是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，选举超时随机范围配置为300～500ms。也就是说，在正常情况下，一个选举超时区间内大约有 12～20 次心跳机会。
一、最外层无限循环
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()很相似，只是：
选举超时：300～500ms，每轮随机 心跳间隔：固定25ms八、doHeartBeat()会再次检查角色
Ticker 在等待期间，Leader 可能收到更高任期的响应并退回 Follower。
可能出现：
Ticker 看到 status == Leader → 开始睡眠 → 收到更高任期消息，变成 Follower → Ticker 睡醒 → 调用 doHeartBeatdoHeartBeat()自己会持锁并再次判断：
if (m_status == Leader) { // 才真正发送 }因此，即使 Ticker 的角色判断已经过期，也不会以 Follower 身份构造 Leader RPC
九、 Ticker 触发的不只是空心跳
leaderHearBeatTicker()名字容易让人误以为它只发送空包。实际上，它调用的doHeartBeat()是整个复制调度入口。
对每个 Follower：
nextIndex <= 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)