1. 课程导入与全景认知

在量化交易与行情系统的开发中，很多工程师第一次真正"踩坑"，往往不是因为策略逻辑写错，而是因为行情 API 的调用被拒绝、连接被限流、数据出现缺口。行情接口通常由交易所或数据服务商提供，它们对单位时间内的请求次数、订阅数量、连接数都有严格约束；而行情本身又具有高频、连续、不可回溯的特点。一旦请求被限流或失败，如果处理不当，轻则数据延迟，重则策略基于残缺数据做出错误决策。本课程要解决的，正是"如何在速率限制的约束下，稳定、完整、可恢复地获取行情数据"这一核心问题。

核心问题：约束与可靠性的矛盾

行情 API 的速率限制（Rate Limit）本质是服务方对客户端资源消耗的配额管理。常见形式包括：每秒请求数（如 10 次/秒）、每分钟请求数（如 1200 次/分钟）、并发连接数上限、单连接订阅标的数量上限，以及按权重计费的配额（不同接口消耗不同权重）。当客户端超过配额，服务端通常返回 HTTP 429（Too Many Requests）或特定错误码，部分交易所还会返回"当前限制"与"重置时间"等字段。

而重试机制要解决的是另一面：网络抖动、服务端瞬时过载、连接中断都会造成请求失败。简单粗暴地"失败就立刻重试"会放大流量，把瞬时故障变成持续限流，形成雪崩。因此，速率限制与重试不是两个独立话题，而是一体两面——限流是为了不触发限制，重试是为了在限制内优雅恢复。理解这一点，是整门课程的主线。

学习目标：从认知到可运行

完成本课程后，你应当能够独立完成以下事情，而不只是"知道概念"：

• 读懂限流规则：能从交易所文档中提取请求频率、权重、并发、订阅上限等约束，并换算成自己系统的预算模型。
• 设计限流器：能实现令牌桶或漏桶，把"每秒 N 次"转化为可执行的等待与排队逻辑，并处理权重差异。
• 设计重试策略：能区分可重试错误（429、5xx、超时）与不可重试错误（参数错误、鉴权失败），并实现指数退避加随机抖动。
• 处理数据缺口：能在限流导致数据缺失时，通过补拉、分页、断点续传恢复完整性。
• 观测与调优：能建立成功率、配额余量、重试分布、缺口数等指标，并据此调整参数。

整体知识框架

课程按"认知—机制—实现—工程化—实战"五层递进组织。第一层建立全景认知与术语体系；第二层深入限流算法与重试理论，包括令牌桶、漏桶、滑动窗口、指数退避、抖动、熔断与半开状态；第三层进入代码实现，覆盖请求调度器、限流中间件、重试封装、错误分类；第四层是工程化，涉及多进程/多机共享配额、Redis 分布式限流、监控告警、配置化参数；第五层是实战项目，把上述能力组装成一个可运行的行情采集服务，并做压力测试与故障演练。

需要强调的是，本课程不追求罗列所有交易所的差异，而是提炼出可迁移的通用模型：任何行情 API 都可以抽象为"配额—请求—响应—恢复"的闭环。掌握这个模型，换一家交易所只需替换参数与错误码映射，而不必重写架构。

实战项目介绍

贯穿全课程的实战项目是一个多标的行情采集服务。它的目标场景设定为：同时订阅约 50 个交易对的实时盘口与 1 分钟 K 线，服务端限制为每秒 10 次请求、单连接最多订阅 20 个标的、每分钟权重上限 1200。项目需要在这些约束下稳定运行，并在人为注入 429 与网络中断时自动恢复，最终保证 K 线无缺口。

项目会分阶段交付：先实现单线程请求与基础限流，再加入重试与退避，然后引入连接分片解决订阅上限，接着加入缺口检测与补拉，最后接入监控面板。每个阶段都有明确的验收标准，例如"连续运行 30 分钟，429 触发次数低于 5 次""注入 10 次断连后，K 线缺口为 0"。这些标准属于教学设定，用于帮助你建立可验证的工程习惯。

一个先导示例：限流参数如何影响重试

为了让你提前感受本课程的核心矛盾，看一个简化示例。假设服务端限制为每秒 10 次请求，你的采集器需要拉取 50 个标的的盘口，每个标的 1 次请求。若不加控制地并发发出，第 11 个请求起就会收到 429。此时若采用"立即重试"，失败请求会继续挤占配额，形成恶性循环。

# 教学示例参数（非实测）
rate_limit = 10          # 次/秒
targets = 50             # 标的数
naive_burst = 50         # 一次性并发请求数
expected_429 = naive_burst - rate_limit   # 约 40 次被限流

# 改进：令牌桶 + 指数退避（伪代码）
for target in targets:
    token = bucket.acquire(timeout=1.0)   # 拿不到令牌就等待
    resp = request(target)
    if resp.status == 429:
        wait = min(base * 2**attempt, max_wait) * random_jitter()
        sleep(wait)
        retry(target)

这段伪代码揭示了两个关键点：第一，限流器要在请求之前生效，而不是失败之后补救；第二，退避时间必须随重试次数增长并带随机性，否则多个客户端会在同一时刻再次碰撞。后续章节会把这两点展开为完整实现。

术语约定

为避免歧义，本课程统一以下说法：配额指服务端允许的调用额度；权重指单次请求消耗的配额单位；限流指客户端主动控制发送速率；退避指失败后延迟再试；熔断指连续失败后暂时停止请求；缺口指应到未到的行情数据。全文涉及时间窗口时，默认以服务端返回的重置时间为准，客户端本地时钟仅作参考。

现在你已经建立了全景认知：问题是什么、要学什么、框架如何组织、项目长什么样。接下来的章节将从最基础的限流算法开始，逐步把这些概念变成可运行的代码。