实时行情接入:限频、抖动、断线

客户端                      请求数   成功   429   500  断线读  成功率%
A 朴素轮询（失败立刻重试）      128    86    21     8    13    67.2
B 固定间隔重试（3 步）          97    86     0     7     4    88.7
C 指数退避+抖动+熔断            92    84     0     5     3    91.3

一、三条必须实现的机制

抖动这一条最容易被省掉。 如果所有客户端都是"失败后等 2 秒、4 秒、8 秒",那它们会在同一时刻集体重试——把一次故障变成一次雪崩。

二、这个实验一开始是错的

def fetch(self, step: int):
    # ⚠️ 必须用客户端的时间步，不能用「源自己被调用了多少次」
    self.t = step

三、断线重连之后:最容易错的一步

重连成功后不能直接续着推,必须先做两件事:

1. 拉一次快照补齐断线期间的缺口——否则你的持仓/行情状态是残的
2. 按主键去重(symbol + 时间戳)——因为补齐的快照会和后续推送重叠

漏掉 ① → 状态残缺且不报错;漏掉 ② → 同一根 K 线被消费两次。

这两种错都不会抛异常,只会让你的结果慢慢变得不可解释——这正是 p1.6 讲的那类问题。

四、实时接入的三条纪律(接 p1.5)

第 ③ 条最容易被忽略。系统里每一次"这条数据我不要了"的决定,都必须留下一个计数器;否则数据缺了一段,你连"是不是我自己丢的"都答不出来。

五、一个必须说清的取舍

本节 A 拿到的数据(86 条)比 C(84 条)略多。

这是实测结果,不能藏。但要连着后半句一起读:

A 付出了 21 次 429,而 C 是 0 次。

真实环境里,持续触发限频通常会被降级或封禁——那时 A 的「更多数据」会一次性归零。

用两条数据换 21 次限频,是一笔看起来赚、实际上在借高利贷的交易。

🔧 动手做:C 那套复杂机制,到底什么时候才值?(8 分钟)

默认源下,B(固定间隔)和 C(退避+熔断)看着差不多——429 都是 0、成功率 88.7% vs 91.3%。那 C 多出来的复杂度,是白费吗?

压测它:把第 20 行 RATE_LIMIT = 5 改成 2(模拟一个严得多的源),重跑 python p86_realtime.py。

你会看到(实测):

想明白:平时源宽松,B 够用,C 的退避+熔断根本看不出价值。但源一变严、故障一变长,只有 C 扛得住。 这类机制不是给顺境写的,是给出事那天写的——而你事先不知道哪天出事。这才是"复杂度要花在刀刃上"的真正含义:不是平时炫技,是灾难时保命。

📌 免责:本课为技术教学,行情源为离线模拟,不构成投资建议。