3. 识别行情API的速率限制信号

在行情API的调用过程中，限流并不是“突然发生”的，服务端通常会在拒绝请求之前或同时，通过状态码和响应头把限流信息明确告知客户端。能否准确识别这些信号，直接决定了重试策略是“盲目重试”还是“有依据地等待”。本节聚焦三类可观测信号：HTTP 429状态码、四类标准限流响应头，以及限流维度（按什么计数）的分析方法。

一、HTTP 429：最直接的限流信号

当客户端在单位时间内发送的请求数超过服务端配额时，服务端通常返回 429 Too Many Requests。它与 5xx 有本质区别：5xx 表示服务端处理失败，重试可能成功；429 表示服务端明确拒绝处理，请求根本没有进入业务逻辑，重试必须等待配额恢复。因此，在重试决策中，429 应被单独归类为“可重试但需延迟”的错误，而不是与网络超时混为一谈。

需要注意，429 并非唯一表现。部分行情服务商在超限时返回 403 Forbidden 并附带限流说明，或在 WebSocket 场景下直接断开连接并返回自定义错误码。因此识别逻辑不能只判断 429，还应结合响应体中的错误码字段（如 code: "RATE_LIMIT_EXCEEDED"）做二次确认。

二、四类限流响应头的含义与解析

标准限流响应头提供了“配额窗口”的完整画像，四者配合才能算出正确的等待时间：

• X-RateLimit-Limit：当前窗口允许的最大请求数，例如 600，表示每分钟（或每窗口）配额上限。
• X-RateLimit-Remaining：当前窗口剩余可用请求数，例如 12。它是最重要的“预警信号”——剩余量接近 0 时就应主动降速，而不是等到 429。
• X-RateLimit-Reset：配额重置时间。它有两种常见格式：Unix 时间戳（如 1718000460）或距重置的秒数（如 37）。解析时必须先判断格式，否则会把“37秒后重置”误算成“1970年”。
• Retry-After：通常出现在 429 响应中，明确告知“多少秒后可重试”，可能是秒数或 HTTP 日期。它的优先级最高——服务端已经给出了权威等待时间，客户端不应再用自己的退避算法覆盖它。

下面是一段典型的响应头解析逻辑（示例参数，非实测数据）：

function parseRateLimit(headers) {
  const limit = Number(headers['x-ratelimit-limit']);
  const remaining = Number(headers['x-ratelimit-remaining']);
  const resetRaw = headers['x-ratelimit-reset'];
  const retryAfter = headers['retry-after'];

  // 判断 reset 是时间戳还是剩余秒数
  let resetAt;
  if (resetRaw > 1e9) {
    resetAt = Number(resetRaw) * 1000;      // Unix 秒级时间戳
  } else {
    resetAt = Date.now() + Number(resetRaw) * 1000;
  }

  const waitMs = retryAfter
    ? Number(retryAfter) * 1000
    : Math.max(0, resetAt - Date.now());

  return { limit, remaining, resetAt, waitMs };
}

这段代码的关键在于 resetRaw > 1e9 这个判断：当前 Unix 时间戳早已超过 10 亿，而“剩余秒数”通常只有几十到几百，两者量级差异明显，用阈值区分是工程上简单可靠的做法。

三、限流维度分析：搞清楚“按什么计数”

只知道“超限了”还不够，必须知道服务端按什么维度计数，否则重试仍然会失败。行情API常见的限流维度包括：

• 按接口路径：行情快照、K线、深度盘口各自独立配额，一个接口超限不影响另一个。
• 按API Key：同一密钥下所有请求共享配额，多进程部署时会互相挤占。
• 按IP：同一出口IP共享配额，NAT环境或容器集群共用一个公网IP时极易触发。
• 按权重：不同接口消耗不同“点数”，深度盘口可能一次消耗5点，而最新成交价只消耗1点。此时 X-RateLimit-Remaining 的下降速度与请求数不成正比。

判断维度的方法很直接：观察 X-RateLimit-Remaining 的递减规律。若每次请求减1，说明按请求数计数；若某接口一次减5，说明存在权重机制；若两个不同API Key的剩余量互不影响，说明按Key隔离。这些观察结果应记录到客户端的限流模型中，用于后续的主动节流。

四、从信号到动作：把识别结果接入重试逻辑

识别信号的最终目的是驱动正确的动作。一个实用的处理原则是：429 响应不消耗业务重试次数，但必须消耗等待时间。也就是说，遇到 429 时应按解析出的 waitMs 精确休眠，然后重试；若连续多次 429 且 Retry-After 持续增大，说明客户端整体请求速率已远超配额，此时应触发全局降速，而不是继续单请求重试。

另一个容易被忽视的点是时钟偏差。若客户端本地时间比服务端快，用 X-RateLimit-Reset 时间戳减去本地时间可能得到负数或偏小的值，导致提前重试再次被拒。稳妥做法是对计算结果做下限保护（如至少等待 200ms），并在多次观测后估算本地与服务端的时间偏移量。

五、限流维度分析的实际操作

在接入一个新的行情服务商时，建议用一个小脚本做维度探测：固定时间窗口内，分别用单Key单接口、单Key多接口、多Key单接口三种方式发请求，记录每次响应中的 X-RateLimit-Remaining。若单Key多接口时剩余量共享下降，说明按Key计数；若不同接口各自下降，说明按路径计数；若更换出口IP后剩余量恢复，说明存在IP维度。探测结果应整理成一张限流模型表，作为后续主动节流和容量规划的依据。

掌握这三类信号后，客户端就从“被动挨打”变成了“可观测、可预测、可控制”。429 告诉你已经越界，响应头告诉你边界在哪里、还有多久恢复，维度分析告诉你边界是按什么划的——三者结合，重试才真正有据可依。