有效的市场数据消耗对于 Deribit 上的算法交易至关重要。本文概述了如何从 Deribit 的 API 获取最及时、最可靠的市场数据，同时最大限度地减少延迟和系统负载。我们将介绍 Deribit 的市场数据架构、选择正确的接口（WebSocket、FIX 或多播）、原始数据流与聚合数据流、最佳订阅模式以及连接管理。遵循这些最佳实践将有助于确保您尽快收到价格和订单簿更新，而不会使系统或 Deribit 过载
Deribit 的交易平台通过多节点并行系统分发市场数据。 每种工具（订单簿）都会生成自己的事件流 （订单、交易等），然后将其分发到多个处理节点上，以进行格式化并转发给客户。这意味着负载是共享的， 市场数据是并行生成的，例如，比特币和以太坊产品在不同的线程/内核上处理。作为用户，你通常不会看到这种复杂性（而且没有指标表明哪个节点发送了给定更新），但它支撑了 Deribit 处理高吞吐量的能力
活动订购： Deribit 保证在每台仪器的馈送中，事件按其发生的确切顺序传送。序列号（比如 change_id 用于订单簿更新）允许您的客户验证连续性。因此，您可以相信，给定工具的价格更新不会不按顺序发布。（跨工具的时序本质上是异步的，例如 BTC 更新可能与 ETH 更新交错，但每种工具的时间顺序都会被保留
重要
如果您想了解有关订单管理的更多详细信息，请参阅 订单管理-最佳实践。
WebSocket 与 FIX 延迟： 为了接收实时数据， WebSocket 和 FIX 的连接速度同样快 在实践中。两个接口都利用相同的事件流，并在处理更新后立即交付更新。换句话说，对于市场数据，使用FIX而不是WebSocket没有固有的延迟优势，反之亦然，因为它们都提供毫秒级的实时更新。使用适合您的基础架构的任意一种（WebSocket 的 JSON 既方便又功能丰富，而 FIX 使用符合金融行业规范的二进制提要），因为我们知道
Deribit 多播： 对于 尽可能低的延迟，Deribit 为网络距离较近的客户提供多播市场数据源。使用 SBE（简单二进制编码）以 UDP 流的形式提供给位于同地的客户端（以及通过特殊的 AWS 安排） Deribit 的多播信号以最小的开销和延迟提供高性能的公开市场数据广播。将大量数据使用者迁移到多播可以显著减少延迟（无 JSON 解析，没有每个连接的传输延迟），还可以减轻 Deribit API 节点的负载。这是接收 Deribit 数据的最快方式，但它需要更复杂的集成（二进制消息解码）和网络设置（加入多播组，通常在 LD4 或支持的 AWS 区域中
AWS 多播： Deribit 允许 AWS 托管的客户端访问其多播源。该解决方案将多播数据打包到 TCP 流中，并利用 AWS 跨账户共享多播的能力 AWS（伦敦 eu-west-2 或东京 ap-northeast-1）中的客户可以订阅 Deribit 的低延迟提要，并与托管用户同时接收相同的市场数据，延迟与直接 LD4 连接非常相似。换句话说，AWS中继中的所有订阅者都会同时获得更新，从而消除了 “更快” 的连接可能具有的任何优势，并使云用户在即时交易速度方面几乎与物理同地办公相提
提示
如果超低延迟是 不是 对你的策略至关重要，实际上 Deribit 鼓励 你可以使用更高级别的聚合 Feed。使用它们可以减少核心系统的负载，从而提高整体交换性能。总而言之：只有在真正需要时才使用最原生、最快的 Feed；否则，稍微限制的 Feed 或共享事件节点 “足够好”，对客户端和服务器都更友
Deribit 提供两种类型的市场数据渠道： “原始” 饲料与汇总（批处理）饲料。
-
Raw channels deliver every single update as an individual message, with no batching. For example, subscribing to book.<instrument>.raw gives you an order book change notification for every order insertion, update, or deletion in that book. This yields the most granular, up-to-the-moment view of the market. If you want the absolutely earliest signal of a book change or trade, use raw channels . However, raw feeds generate high message volumes, especially in active instruments, which can tax your network and client if not handled efficiently.
注意
原始公共订阅源需要经过身份验证的连接，以防滥用。
-
聚合频道 分批或按固定间隔交付更新。例如，你可以订阅
book.BTC-PERPETUAL.100ms（更新按以下方式分组100ms) 或agg2聚合类型。这些提要以设定的频率将多个更新合并为一条消息或快照。结果是消息频率降低，客户端更容易处理，代价是几毫秒的 如果您不需要逐项详细信息，建议使用汇总的 Feed 以减轻负荷。
注意
这个 agg2 聚合信道以大约 1 秒的间隔对更新进行分组。
总的来说， 原始和聚合信道的处理优先级相同 站在 Deribit 一边。订阅聚合提要并不意味着 Deribit 的发送速度会变慢——数据管道是一样的，只是批处理。你在哪里 将 注意吞吐量的不同之处在于：原始订阅源可能在一秒钟内发送数十条消息，而一个 100 毫秒的源可能会在同一秒内发送 1—2 条消息（每条可能包含多项更改）。更少的消息意味着更少的客户端 JSON 解析和更少的入站队列备份机会
注意
原料聚合: Deribit 努力从不聚合原始订阅源... 但是在极端负载下，即使是 “原始” 订阅量也可能略微汇总在一起的情况很少见。这是由于多个内部进程在处理通知；如果某些节点或 CPU 内核承受巨大压力，则某些事件可能会在到达您之前合并在一起。这种情况在正常运行中不太可能，但请注意，在峰值爆发期间（例如巨大的波动率峰 你可能会偶尔看到原始订单簿变动，实际上同时代表两到三次变化。你的客户端逻辑应该很好地处理这个问题（例如，通过按顺序应用批量更改）——结果实际上是一样的，只是那一刻每条消息没有一次更新
Deribit 的 API 允许灵活订阅多个频道。以下是优化您的订阅内容和订阅方式的做法：
-
仅订阅您需要的内容（窄订阅与宽订阅）： 您可以在不同的范围内订阅。例如，
trades.BTC-PERPETUAL.raw仅提供该工具的交易，而trades.future.BTC.raw会交付 全部 比特币期货在每次到期期间交易。虽然如果你汇总两者最终都会提供相同的信息，但广泛的订阅（trades.future.BTC.raw) 会让你大吃一惊 很多 如果您只关心几个特定的未来，则需要数据。 通常，特异性更有利于性能 — 订阅更窄的频道意味着通过您的连接发送的数据更少，需要解析的 JSON 更少，您在客户端需要做的过滤也更少。广泛订阅（使用广泛的渠道模式，例如所有期权或所有货币工具）很方便，但它们包括许多您可能不感兴趣的活动，这些活动可能会使您的客户或网络不堪重负。如果您知道只需要某些工具，请单独订阅。-
狭义订阅的唯一缺点是 你必须动态跟踪仪器。 例如，如果你想跟踪 全部 比特币的期权，单独订阅每个期权是有效的，但你需要赶上新的期权行使价上市，也需要订阅这些期权（Deribit 定期列出新的到期日/罢工）。这可以通过仪器通知（如下所述）进行管理，但需要更多的逻辑。相比之下，
trades.option.BTC.raw将在新选项出现时自动对其进行覆盖，但代价是会产生大量不必要的噪音。根据你的用例做出决定：如果在几秒钟内缺少新工具很重要，你可以使用一个广泛的订阅；否则，保持范围通常是值得的 -
要管理一组动态订阅（随着新工具的到来和旧工具的到期），请利用 仪器生命周期提要。Deribit 提供了一个渠道 仪器状态。{种类}。{货币} 它会在创建新工具、何时开始交易以及何时关闭或到期时终止发出通知。例如，你可以订阅
instrument.state.option.BTC用于在BTC期权上市或到期时获取活动。许多机构用户订阅instrument.state.any.any（所有工具）来推动其订阅管理逻辑。这比投票好得多 /公共/get_instruments 反复。实际上，Deribit 明确要求客户使用此渠道而不是频繁的仪器查询，这会给系统带来不必要的负担。通过处理这些通知，您可以在新的感兴趣的工具出现后立即自动订阅它们，并取消对终止的工具的订阅。提示
你也可以使用 public/get_expirations 检索给定货币和工具类型的当前有效到期清单的方法，这有助于初始化订阅或在新工具出现时验证到期日期。
-
-
避免过度的 REST 轮询： 与此相关的是，与通过REST进行任何类型的持续轮询相比，更喜欢实时订阅频道。例如，如果您想要实时交易或报价，请不要致电 /public/get_last_trades 或者 /public/get_order_book 循环中 — 使用 WebSocket 提要 (
trades.*和book.*频道）向您推送更新。轮询不仅会带来延迟（你的轮询间隔总是落后），还会消耗速率限制并增加 API 服务器的负载。为不频繁的查询（快照、历史数据或偶尔的状态同步）保留 REST。流媒体API旨在向您推送及时的数据——将其用于任何时间敏感 -
批量订阅请求： Deribit 允许您在单个 API 调用中订阅多个频道，这比逐个订阅效率要高得多。当你的 WebSocket 连接处于打开状态时，准备一个 公开/订阅 你想要的所有频道的数组进行通话。该系统最多可以处理 一条订阅消息中包含 500 个频道, 这在实践中应该足够了.批量订阅可减少发送许多小请求的开销（延迟和负载），并确保您立即开始接收所有数据。例如，与其针对100种产品进行100次单独的公开/订阅通话，不如使用包含这100种产品的 “频道” 列表进行一次通话。以下代码段说明了同时订阅四个频道的单个请求
{
“jsonrpc”：“2.0”，
“ID”：42，
“方法”：“公开/订阅”，
“参数”：{
“频道”：[
“ticker.btc-Perpetual.raw”，
“ticker.eth-Perpetual.raw”，
“book.btc-Perpetual.raw”，
“book.eth-Perpetual.raw”
]
}
回复将确认所有订阅的频道。使用一条消息意味着最大限度地减少往返延迟，并且可以同步开始供稿。（如果你的频道非常多，你可以将它们分成批——例如 2 条消息，每条 500 条——但要避免通过数百个单独的订阅调用向 API 发送垃圾
使用单独的连接进行交易和市场数据。 也许最重要的绩效做法是 将您的订单流量与数据源隔离开来。 Deribit 允许多个 WebSocket（或 FIX）连接，你应该利用这个优势。运行一个专用于的连接 市场数据订阅，还有另一个（或几个）专门用于 订单输入和其他私人操作。原因是，如果将它们组合在一起，大量的传入数据可能会阻塞连接并延迟您的传出订单命令或其确认。尽管 Deribit 的基础设施在不同的线程中处理公共（数据）和私有（订单）消息，但它们仍然在一个套接字上共享相同的 TCP 管道。大量的 JSON 报价可能会填满 TCP 接收缓冲区或客户的处理循环，这意味着您的下一个订单取消可能会在一堆传入的消息后面。通过拆分数据并在不同的套接字上进行交易，您可以确保市场事件的激增不会阻塞您的关键交易信息。
提示
有关连接设置的更多指导，请参阅 连接管理-最佳实践 文章。
提示
Deribit 的 FIX API 提供了 ConnectionOnlyExecutionReports 标志（标记 9010）：开启 登录）如果您为单个账户使用多个 FIX 连接，则可以进一步隔离订单更新。在 FIX 会话中将其设置为 “Y” 意味着该会话将仅接收其所下订单的执行报告，而不会接收来自其他会话的订单的执行报告。如果您有两种或更多使用单独的FIX连接的活跃交易算法，这可能会很有用。
监控您的连接运行状况和延迟： 对于高吞吐量数据流，重要的是要注意是否有任何延迟迹象。Deribit 包括序列号change_id 和 prev_change_id 订单簿更新，增量更新 trade_id 或者 timestamps 用于交易等）— 使用它们来检测您是否错过了消息（例如序列间隔）。如果你怀疑自己错过了数据（可能是由于瞬间的网络问题），你可以像这样调用 REST 端点 /public/get_order_book 重新同步。这种情况很少见，但保持弹性机制是任何实时信息源的最佳做法
最后， 优化您的网络位置。Deribit 的主要服务器位于伦敦（Equinix LD4）。如果低延迟至关重要，请将您的客户托管在尽可能靠近伦敦的地方，甚至可以考虑 同地办公服务。互联网延迟和路由可能会有所不同——许多认真的交易者使用交叉连接。即使是负载均衡器增加的约 1 毫秒或 50 毫秒的跨大陆延迟，在高频交易中也可能很重要。如果你在世界的另一端无法搬迁，请使用 AWS 多播 （在东京或伦敦地区）可能是实现公平竞争环境的次佳选择。
通过使用上述指南，您可以构建一个既快速又强大的市场数据收集系统：
-
选择正确的饲料 — 使用 WebSockets 或 FIX 获取实时数据（它们具有相似的性能），如果您需要超低延迟，可以探索 Deribit 的多播源或 AWS 多播。否则，默认源就足够了，也更易于使用。
-
原始与聚合 — 仅在您真正需要每笔报价时才订阅原始账簿/交易提要。否则，选择 100 毫秒或聚合更新以减少噪音。Deribit 的系统将感谢您尽可能使用聚合渠道
-
最大限度地减少数据量 — 仅根据需要筛选您的订阅。避免使用通配符向您转储不必要的数据。使用多个有针对性的渠道，而不是一个巨大的消防水带
-
巧妙地订阅 — 在一个请求（最多 500 个频道）中批量订阅以提高效率。利用 仪器状态 Feed 可捕捉新房源和到期时间，这样您就可以实时调整订阅内容。
-
隔离连接 — 对于市场数据和订单执行，始终使用单独的连接。这种隔离可以防止数据激增延迟您的交易。如果在 FIX 上使用多个连接，请考虑 9010 标签以避免重复报告
通过遵循这些最佳实践，您将确保以可靠的方式从Deribit获得尽可能快的市场更新，从而使您能够在保持系统稳定的同时在市场上快速做出反应。祝交易愉快！