Skip to main content
我们公布按博彩商实测的延迟数值，且每条更新都携带可供核验的时间戳。所以不必凭信任接受这些数字 —— 本页给出一套试用方案，让评估以您自己的分布数据收尾，而不是一个印象。

​
每条更新能让您测量什么

两个指标，分开评判 —— 因为它们的归属方不同： 第二个指标读数偏慢，对第一个指标不构成任何结论；先测清两者再归因。两者都在比较您的时钟与我们的时钟，因此在相信 100 毫秒以内的读数之前，请先跑好 NTP。完整时间戳链见延迟与新鲜度，部署位置见服务器位置。

​
试用方案

1

限定在您真正交易的范围

用 sportIds、tournamentIds 和 bookmakers 过滤条件登录，只订阅将来真正承载您交易量的博彩商与运动。在订阅 odds 的同时订阅 bookmakers —— 您会希望采集的数据里带有陈旧度信号。
2

记录原始数据，事后聚合

每条更新记录博彩商、oddsId、两个差值，以及赛事当时是否为滚球。聚合为按博彩商的分位数（p50 / p95），并区分滚球与赛前 —— 公布的数值是按交付模式区分的，您的对照也应如此。
3

对照我们公布的数值

按博彩商：您实测的 p50 对照延迟与新鲜度中的代表性 p50，尾部对照 GET /bookmakers 上的 maxDelayLiveInSec / maxDelayPregameInSec 上界。这些上界就是我们的承诺；请以此要求我们。
4

演练故障路径

数据源之间的速度差异更多体现在故障中而非稳态 —— 见下文演练。
5

与现有数据源同场竞速

通过 externalProviders 一次性完成赛事映射，在选项键上对齐，并对同一次改线为两个数据源分别计时 —— 映射与方法见并行第二数据源。

​
演练故障路径

稳态延迟是容易的部分；生产环境中真正拉开数据源差距的是恢复行为。三项演练，试用期内均可安全进行：
  • 恢复（resume） —— 断开连接几秒，携带 serverEpoch 与每频道 lastSeenId 重连，验证遗漏的更新被无缝重放。这是短暂中断的既定路径。
  • 重新快照 —— 保持断开超过重放窗口（resumeWindowMs），让网关发出 snapshot_required，然后为完整恢复计时：一次 REST 快照，按键以较新的 changedAt 合并。该耗时就是您的最坏情况上界 —— 请确认它是您可以接受的。
  • 陈旧度统计 —— 在试用期内按博彩商统计 staleOdds 事件的次数与持续时间。上游失联会被显式上报而非隐藏；一个从不显示陈旧的数据源未必更新鲜，它可能只是没有告诉您。
前两项的机制见恢复和重放；标志位见状态信号。

​
覆盖范围，以 API 为准

请用实时响应而不是宣传材料核对您的需求清单：
  • 您的密钥能看到的博彩商 —— 枚举 GET /bookmakers；访问权限按密钥授权，这才是您的合同对应的权威清单。
  • 各运动的盘口 —— GET /markets?sportId=… 逐线值返回您可能收到报价的每个盘口与选项。
  • 赛程深度 —— 拉取您所需赛事的一个代表性星期的 GET /fixtures，与您自己的赛程需求做差异对比。
目录结构见覆盖范围、博彩商覆盖与盘口覆盖。

​
结果层面的定论

逐条更新的秒表竞速回答「谁先看到」；收盘线价值回答这份速度是否变现。试用结束时，把您本会交易的价格与收盘线做关联：
GET /fixtures/odds/clv 按 oddsId 返回开盘与收盘价格 —— 与实时数据流同键，因此与您试用日志的关联零成本。在试用期标记的线路上跑赢收盘线，才是经得起生产检验的评估结论。方法见 sharp 线路交易与 CLV。

​
一份完成的评估长什么样

  • 按博彩商的观测延迟分布，滚球与赛前分开，与公布的 p50 及上界并列 —— 相符与否一目了然。
  • 实测的 resume 与重新快照耗时，让最坏情况恢复成为一个数字，而不是一个指望。
  • 基于实时 API 响应、对照您需求清单的覆盖差异。
  • 您本会交易线路上的 CLV 关联。
如果您的测量与公布数值不符，我们希望知道：把受影响的博彩商、UTC 时间戳以及您的 serverEpoch / entryId 发到 contact@55-tech.com，我们可以快速定位会话。试用权限也通过同一邮箱安排。