当程序员不再写极致的优化,逐行扣代码后,程序员该回到什么角色。
一、它是什么:不是路由策略,而是"过载标记器"
在 SMG 的策略矩阵里,这个模块容易被人误读。先澄清一点:它并不参与"选哪个 worker"的决策——选 worker 是缓存感知、分桶、轮询这些路由策略的活。它做的是更上游的一件事:
持续监控每个 worker 的延迟指标,给它打上一个"过载"标记,让 HTTP 路由器在选 worker 之前把过载者从候选集里剔除。
它被设计成采集器上的一个"指标钩子"。采集器每隔几秒抓一次各 worker 的 TTFT/TPOT 分位数,算完之后回调这个钩子,由判定逻辑依据阈值决定该 worker 当前是否过载。路由器随后读这个标记做预过滤。
这个分层是有意为之:采集、判定、过滤、路由四件事解耦。latency_aware 关掉时钩子变成空操作,不打标、不过滤,但原始指标照常流动,不会留下脏状态。希望每个策略都能被独立开关、独立演进,而不是搅在一起。
二、核心机制:两级阈值 + 滞回 + 主动探测
2.1 状态机:进入容易、退出难
判定逻辑是一个三态状态机:
未过载 → 看是否该标过载:当 TTFT p90 或 TPOT p90 超过"过载阈值"时,标记为过载并启动探测;
已过载 → 看能否恢复:只有当延迟回落到"降级阈值"以下、且探测也认为恢复了,才清除过载标记。
默认配置下的阈值是非对称的:
维度
进入过载
退出过载
TTFT p90
≥ 30.0s
< 16.0s
TPOT p90
≥ 0.3s (300ms)
< 0.08s (80ms)
这是典型的**滞回(hysteresis)**设计:进入门槛 30s,退出门槛 16s。中间 16–30s 的灰色地带,worker 会被"锁"在过载状态,直到延迟真正回落到降级线以下。
这样设计是吃过反复进出(thrashing)的亏——如果进出阈值一样,延迟在边缘抖一下就进、抖一下就出,路由选路跟着反复跳。而反复跳对缓存是灾难(后文会专门讲)。非对称阈值就是为了把 worker "锁"住,逼它彻底缓过来再放回。
退出判定要求指标严格低于降级阈值,并且探测也确认恢复。这是"双重...
李白
花间一壶酒,独酌无相亲。
举杯邀明月,对影成三人。
月既不解饮,影徒随我身。
暂伴月将影,行乐须及春。
我歌月徘徊,我舞影零乱。
醒时同交欢,醉后各分散。
永结无情游,相期邈云汉。