热备的判断条件定好之后,还有一件事要防:误判。号群本身正常,检测却因为别的原因不通,备用线被触发接管,号群白换了一次地址。这种接管看着完成了,实际只是多折腾一遍。误判的来源有几处,知道了来源,防起来才有针对性。
| 来源 | 表现 | 应对 |
|---|---|---|
| 本地网络抖动 | 短时间内集中失败,很快恢复 | 连续失败两次以上才判定 |
| 检测目标不可达 | 换个检测目标立刻恢复 | 检测目标准备两个以上 |
| 游戏服务端维护 | 游戏登录异常,连通测试正常 | 连通测试与游戏状态分开看 |
| 检测脚本本身出错 | 所有线路同时报异常 | 先确认检测脚本还活着 |
误判的几处来源
本地抖动与检测目标
最常见的误判来自本地网络抖动。多开环境所在的网络偶尔丢包,检测请求超时,判断条件被满足,接管被触发。防的办法是拉长判定窗口,连续两次以上失败才算异常,两次之间留出足够间隔。第二个来源是检测目标本身不可达,目标站点临时故障会被误认成线路问题。应对的办法是准备两个不同归属的检测目标,两个都不通才判定异常。代理IP的线路状态和检测目标的可用性分开看,判断才准。
一个目标不通,先换一个再判断。
游戏状态与检测脚本
游戏服务端自己的维护窗口,会造成游戏登录异常但连通测试正常的情况。检测如果只看游戏能不能登录,维护期就会误判成线路问题。做法是把连通测试和游戏状态分开,连通测试负责判断线路,游戏状态只作为参考。第三个来源是检测脚本本身出错,表现是所有线路同时报异常,这时候先去确认脚本还在跑,再考虑是不是线路的问题。代理IP的接管被一个挂掉的脚本触发,是最冤枉的一种。
误判发生之后
误判已经发生的时候,动作要简单:把流量切回主用线,记录这一次误判,然后回去调判断条件。不要因为一次误判就把整套机制关掉,那是另一种浪费。连续误判多次再考虑改条件,单次误判调数值就够了。记录里写清楚误判的原因,积累几次之后能看出规律,是从判定窗口调,还是从检测目标调。代理IP的误导触发记录和正常接管的记录分开存,回看的时候不容易混。
误判的成本是一次多余的换线;比误判更贵的,是因为怕误判而把热备整个关掉。
罗布乐思的号群误判多半出在检测环节,把判定窗口和检测目标这两处做扎实,代理IP的接管就不会白触发。

