本文介绍如何在基于 goraft 实现的 raft 分布式集群中，准确感知 leader 变更事件，并在新 leader 节点上自动触发自定义通知（如打印日志、发送 http 请求或广播消息），从而实现高可用状态感知。
本文介绍如何在基于 goraft 实现的 raft 分布式集群中，准确感知 leader 变更事件，并在新 leader 节点上自动触发自定义通知（如打印日志、发送 http 请求或广播消息），从而实现高可用状态感知。
在使用 goraft（配合 raftd 示例）构建的 4 节点 Raft 集群（如 2001–2004）中，Leader 自动故障转移是核心能力；但默认情况下，goraft 并未暴露 Leader 变更的回调接口，也未提供开箱即用的通知机制。用户常需在新 Leader 上执行初始化操作（如加载缓存、重连下游服务、上报监控等），这就要求我们精准捕获“我已成为 Leader”这一关键状态。
最直接且可靠的方式，是利用 goraft 内置的事件分发机制：其 setState() 方法在状态切换（尤其是晋升为 Leader）时，会调用 DispatchEvent() 触发 LeaderChangeEventType 事件。我们无需修改业务逻辑层（如 server.go），而应在 goraft 库源码的 server.go 文件中增强事件响应逻辑——这是符合 Raft 实现原理、侵入性最小、稳定性最高的方案。
✅ 推荐做法：在 goraft/server.go 中注入 Leader 通知逻辑
定位到 goraft 源码中的 setState() 函数（通常位于 goraft/server.go 第 287 行附近）。原始代码仅派发事件，未做业务响应：
if prevLeader != s.leader {
s.DispatchEvent(newEvent(LeaderChangeEventType, s.leader, prevLeader))
}
我们在此处插入自定义通知逻辑。例如，打印当前 Leader 地址与数据路径：
if prevLeader != s.leader {
if s.leader == s.Name() { // 确保仅在本节点成为 Leader 时触发
log.Printf("[LEADER NOTIFICATION] ✅ I am the new LEADER: %s (data: %s)",
s.connectionString(), s.path)
}
s.DispatchEvent(newEvent(LeaderChangeEventType, s.leader, prevLeader))
}
? 注意：s.connectionString() 和 s.path 是 goraft 原生字段（connectionString() 在 raft/server.go 中定义，返回 http://host:port 格式），可直接使用；log 包需提前导入（import "log"）。
? 进阶实践：发送 HTTP 通知或触发钩子函数
若需将 Leader 变更同步至外部系统（如配置中心、告警平台），可进一步扩展：
if prevLeader != s.leader && s.leader == s.Name() {
// 异步发送 Webhook（避免阻塞 Raft 主线程）
go func() {
payload := map[string]string{
"event": "leader_elected",
"node": s.Name(),
"address": s.connectionString(),
"timestamp": time.Now().Format(time.RFC3339),
}
data, _ := json.Marshal(payload)
_, err := http.Post("https://your-monitoring/api/raft",
"application/json", bytes.NewBuffer(data))
if err != nil {
log.Printf("[WARN] Failed to notify leader change: %v", err)
}
}()
}
⚠️ 重要注意事项
- 不要修改 raftd/server.go 中的 ListenAndServe：该文件属于应用层封装，不感知 Raft 内部状态机，无法可靠捕获 Leader 切换时机。
- 避免轮询 raftServer.State()：主动轮询不仅低效，还可能因竞态导致误判（如短暂 Candidate 状态）。
- 确保日志/网络操作异步化：Leader 切换是关键路径，所有通知逻辑必须 go 启动，防止阻塞 Raft 提交循环。
- 验证多节点行为：启动全部 4 个节点后，手动 kill 当前 Leader（如 kill -9 2001），观察其余节点日志中是否仅有一个输出 I am the new LEADER —— 这是正确性的黄金验证标准。
- 升级兼容性提醒：此方案需 fork goraft 仓库并维护定制分支；若未来升级 goraft 版本，需同步校验 setState() 结构变更。
通过上述改造，你的 Raft 集群便具备了“自我宣告”能力：每个节点在成为 Leader 的瞬间，即可自主执行运维动作，真正实现去中心化、可观测、可干预的智能集群管理。
