mirror of
https://gitcode.com/JianFeeeee/webui4frpc.git
synced 2026-10-15 12:14:37 +00:00
50c7729779
用户报「只要 .60 和 .106 重启，.30 不重启就会脱环」。线上取证确认是分裂脑，
且违反设计文稿（docs/cluster-api.md §容错行为：非leader宕机应"环跳过死亡节点，
任务重挂"；leader宕机应"上邻居晋升 + StartRing"——环都应继续转）。
实测状态（cycle 两边同为 458198，共享同一段历史）：
.60 视角: leader=.30 节点: [.60 alive, .30 alive=False, .106 alive] topology=3
.30 视角: leader=.30 节点: [.60 alive, .30 alive=False, .106 alive] topology=0 pending=3
两个节点同时自认 leader、互判对方已死；.30 的 topology 被清空成 0、三条转发
全部退回 pending 且无人处理，环停止推进。
## 根因：领导权是"自封"的
becomeLeader() 无条件把自己设为 leader，不问环上是否已有存活 leader。
于是分区两侧各自"心跳失败 → 晋升"，两个环同时运行。更糟的是 WatchLeader
里 MarkOffline + OfflineReassign 是**无条件**的：被分区的那一侧会把仍然活着的
leader 标死，并把它的全部转发搬进 pending —— 这正是两边 topology=0、
pending=3 的直接来源。
## 修法
1. becomeLeader() 先问环：若存在**其它**存活且自称 leader 的节点，就拒绝晋升
（我们才是被分区的一侧），保留存活 leader 的环。真正失去 leader（全员离线）
时无此节点，晋升照常发生。
2. 抽出 takeOverFromDeadLeader()：MarkOffline → 条件晋升 → **仅在真正接管后**
才 OfflineReassign 并 StartRing。原先无条件重挂是破坏活环的直接原因。
同时让这段逻辑可测（WatchLeader 本身是无限循环 goroutine，不能直接测）。
## 关于"leader 要证明自己活着"
我一开始判断错方向，曾加过一个 leader 反向心跳自检 —— 那纯属多余且会引入新的
自封风险：OnToken 每次都会 UpsertNode(self, Alive:true) 自我保活，重启节点按设计
本就该主动用缓存上家/leader 重入（retryRejoinCached，线上三台缓存均完好）。已撤销。
## 测试
新增 4 条并全部双向验证（回退修复行 → 变红 → 还原变绿）：
- TestBecomeLeaderDeclinesToLiveLeader —— 环上已有存活 leader 时拒绝晋升
- TestBecomeLeaderPromotesWhenSoleSurvivor —— 守卫不能破坏真正的 failover
- TestTakeoverLeavesLiveLeadersForwardsAlone —— 拒绝接管时**不得**动对方转发
- TestTakeoverReassignsWhenSoleSurvivor —— 真正接管时转发必须重挂
★ 写测试时踩到一个陷阱：`AdoptState` 是 `e.state = s` 赋值，State.Nodes 是切片，
同一 seed 分给三个引擎会**共享底层数组**，互相改写——看起来像生产 bug，其实只是
测试构造问题（真实进程各自从 token 反序列化）。测试改为经 JSON 往返，各自独立持有。
★ 另一个自省：`git add -A` 把工作区里两个与本次无关的既有文件（docs/how-it-works.md、
scripts/probe-with-virtual-frps.sh）卷进了这个提交，已 reset 分离，它们另立提交。
本仓库再次印证：**只用 `git add <具体路径>`**。
go build / go vet / go test ./... 全绿，gofmt 干净。