1. Deribit Soporte
  2. Soporte
  3. Información técnica

Recopilación de datos de mercado: mejores prácticas

  • Actualización

El consumo eficiente de datos de mercado es fundamental para la negociación algorítmica en Deribit. Este artículo describe cómo obtener los datos de mercado más oportunos y fiables a partir de la API de Deribit y, al mismo tiempo, minimizar la latencia y la carga del sistema. Abordamos la arquitectura de datos de mercado de Deribit, seleccionando la interfaz adecuada (WebSocket, FIX o Multicast), los flujos de datos sin procesar frente a los agregados, los patrones de suscripción óptimos y la gestión de conexiones. Seguir estas mejores prácticas le ayudará a garantizar que reciba las actualizaciones de precios y libros de pedidos lo antes posible sin sobrecargar sus

Arquitectura de datos de mercado y latencia

La plataforma de negociación de Deribit distribuye los datos del mercado a través de un sistema paralelo multinodo. Cada instrumento (cartera de pedidos) produce su propio flujo de eventos (pedidos, operaciones, etc.) de forma independiente, que luego se distribuyen en varios nodos de procesamiento para formatearlos y enviarlos a los clientes. Esto significa que la carga se comparte y los datos de mercado se generan en paralelo, por ejemplo, los productos BTC y ETH se gestionan en subprocesos o núcleos separados. Como usuario, normalmente no verás esta complejidad (y no hay ningún indicador de qué nodo ha enviado una actualización determinada), pero es la base de la capacidad de Deribit para

Ordenación de eventos: Deribit garantiza que, dentro del feed de cada instrumento, los eventos se entreguen en el orden exacto en que ocurrieron. Números de secuencia change_id para actualizaciones de la cartera de pedidos) permiten a tu cliente verificar la continuidad. Por lo tanto, puede confiar en que las actualizaciones de precios de un instrumento determinado no llegarán fuera de lugar. (La sincronización entre instrumentos es intrínsecamente asincrónica, por ejemplo, las actualizaciones de BTC pueden intercalarse con las de ETH, pero se conserva la cronología de cada instrumento

Importante

Si desea obtener más información sobre la gestión de pedidos, consulte Gestión de pedidos: mejores prácticas.

Latencia de WebSocket frente a FIX: Para recibir datos en tiempo real, Las conexiones WebSocket y FIX son igual de rápidas en la práctica. Ambas interfaces aprovechan los mismos flujos de eventos y ofrecen actualizaciones tan pronto como se procesan. En otras palabras, el uso de FIX en lugar de WebSocket para los datos de mercado no supone ninguna ventaja de latencia inherente, ya que ambos proporcionan actualizaciones en tiempo real a nivel de milisegundos. Usa la que mejor se adapte a tu infraestructura (el JSON de WebSocket es práctico y está repleto de funciones, mientras que FIX usa feeds binarios que cumplen con las normas del sector financiero)

Multicast de Deribit: Para el la latencia más baja posible, Deribit ofrece una fuente de datos de mercado de multidifusión para clientes que se encuentran muy cerca de la red. Está disponible para los clientes que comparten ubicación (y mediante acuerdos especiales de AWS) en forma de flujo UDP mediante SBE ( La transmisión de multidifusión de Deribit proporciona una transmisión de alto rendimiento de datos del mercado público con una sobrecarga y una latencia mínimas. La migración de los consumidores de gran cantidad de datos a la multidifusión puede reducir significativamente la latencia (sin análisis de JSON ni retrasos en la entrega por conexión) y también aliviar la carga de los nodos de API de Deribit. Esta es la forma más rápida de recibir datos de Deribit, pero requiere una integración más compleja (decodificación de mensajes binarios) y una configuración de red (unirse a grupos de multidifusión,

Multicast de AWS: Deribit permite el acceso a su fuente de multidifusión para los clientes alojados en AWS. Esta solución empaqueta los datos de multidifusión en flujos TCP y aprovecha la capacidad de AWS Los clientes de AWS (Londres eu-west-2 o Tokio ap-northeast-1) pueden suscribirse al feed de baja latencia de Deribit y recibir los mismos datos de mercado simultáneamente que los usuarios de colocación, con una latencia muy similar a la de una conexión LD4 directa. En otras palabras, todos los suscriptores de AWS Relay reciben las actualizaciones en paralelo, lo que elimina cualquier ventaja que pudiera tener una conexión «más rápida» y hace que los usuarios de la nube estén casi a la altura de la ubicación conjunta física en términos de velocidad de negociación

Importante

Si quieres saber más detalles sobre Multicast y Configuración de AWS consulte estos artículos:

Sugerencia

Si la latencia ultrabaja es no fundamental en tu estrategia, Deribit en realidad alienta a utilizar los feeds agregados de nivel superior. Su uso reduce la carga de los sistemas principales, lo que redunda en beneficio del rendimiento general de Exchange. En resumen: usa los feeds más rápidos y simples solo si realmente los necesitas; de lo contrario, un feed un poco limitado o el nodo de eventos compartido son «suficientes» y más fáciles de usar tanto para el cliente como para el servidor.

Flujos de datos sin procesar o agregados

Deribit ofrece canales de datos de mercado en dos versiones: piensos «sin procesar» frente a piensos agregados (por lotes).

  • 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. 

    Nota

    Las fuentes públicas sin procesar requieren una conexión autenticada como protección contra el abuso.

  • Canales agregados entregue las actualizaciones en lotes o en un intervalo fijo. Por ejemplo, puede suscribirse a book.BTC-PERPETUAL.100ms (actualizaciones agrupadas por 100ms) o agg2 tipo de agregación. Estas fuentes consolidan varias actualizaciones en un solo mensaje o instantánea con una frecuencia determinada. El resultado es una menor frecuencia de mensajes, lo que facilita el procesamiento de los clientes, a costa de unos pocos milisegundos de retraso. Si no necesitas detalles paso a paso, te recomendamos los feeds agregados para reducir la carga.

Nota

El agg2 los grupos de canales de agregación se actualizan en intervalos de aproximadamente 1 segundo.

En general, tanto los canales sin procesar como los agregados se procesan con la misma prioridad del lado de Deribit. Suscribirse a un feed agregado no significa que Deribit vaya a enviarlo más despacio: la canalización de datos es la misma, solo que con el procesamiento por lotes. ¿Dónde estás lo haré observará que hay una diferencia en el rendimiento: una fuente sin procesar puede enviar docenas de mensajes en un segundo volátil, mientras que una fuente de 100 ms puede enviar de 1 a 2 mensajes en ese mismo segundo (cada uno de los cuales puede contener varios cambios). Un menor número de mensajes significa menos análisis de JSON por parte del cliente y menos posibilidades de que la cola de entrada se realice una copia de seguridad

Aviso

Coalescencia de piensos crudos: Deribit se esfuerza por no agregar nunca el feed sin procesar... pero hay casos excepcionales en los que, durante una carga extrema, incluso las suscripciones «sin procesar» pueden llegar ligeramente agregadas. Esto se debe a que hay varios procesos internos que gestionan las notificaciones; si algunos nodos o núcleos de CPU están sometidos a una gran presión, es posible que algunos eventos se combinen antes de que te lleguen. Esta situación es poco probable en condiciones normales de funcionamiento, pero hay que tener en cuenta que durante los picos de máxima volatilidad (por ejemplo, picos de volatilidad enormes es posible que de vez en cuando veas un cambio sin procesar en la cartera de pedidos que, en realidad, represente dos o tres cambios a la vez. La lógica de tu cliente debería gestionar esto correctamente (por ejemplo, aplicando los cambios por lotes en orden); en efecto, se obtiene el mismo resultado, pero no se produce una actualización por mensaje en ese momento

Estrategias y filtros de suscripción

API de Deribit permite una suscripción flexible a muchos canales. Estas son algunas prácticas para optimizar los contenidos a los que te suscribes y cómo

  • Suscríbase solo a lo que necesite (suscripciones estrechas o amplias): Puedes suscribirte en diferentes ámbitos. Por ejemplo, trades.BTC-PERPETUAL.raw solo ofrece operaciones con ese instrumento, mientras que trades.future.BTC.raw entregaría todo Los futuros de BTC se negocian cada vez que vence. Si bien, en última instancia, ambos ofrecerán la misma información si la agregas, la amplia suscripción (trades.future.BTC.raw) te inundará de mucho de datos si solo te importan unos pocos futuros específicos. En general, la especificidad es mejor para el rendimiento — suscribirse a un canal más reducido significa que se enviarán menos datos a través de tu conexión, tendrás que analizar menos JSON y tendrás que filtrar menos por parte del cliente. Las suscripciones amplias (que utilizan patrones de canales amplios, como todas las opciones o todos los instrumentos de una moneda) son prácticas, pero incluyen muchos eventos que quizás no te interesen y que pueden abrumar a tu cliente o a tu red. Si sabes que solo necesitas ciertos instrumentos, suscríbete a ellos de forma individual.

    • El único inconveniente de las suscripciones limitadas es que debes realizar un seguimiento de los instrumentos de forma dinámica. Por ejemplo, si quieres hacer un seguimiento todos para BTC, suscribirse a cada una de ellas de forma individual es eficiente, pero tendrás que saber cuándo aparecen nuevas opciones y suscribirte también a ellas (Deribit publica nuevas caducidades o huelgas con regularidad). Esto se puede gestionar mediante las notificaciones del instrumento (que se describen a continuación), pero requiere un poco más de lógica. Por el contrario, trades.option.BTC.raw cubrirá automáticamente las nuevas opciones a medida que aparezcan, a costa de una gran cantidad de ruido no deseado. Decida en función de su caso de uso: si es importante perder un instrumento nuevo durante unos segundos, puede utilizar una suscripción amplia; de lo contrario, normalmente vale la pena mantenerla por poco

    • Para gestionar un conjunto dinámico de suscripciones (a medida que llegan nuevos instrumentos y caducan los antiguos), aproveche las feed del ciclo de vida del instrumento. Deribit proporciona un canal instrumento.estado. {tipo}. {moneda} que notifica cuando se crea un nuevo instrumento, cuando comienza a cotizar con él y cuando se cierra o termina al expirar. Por ejemplo, puedes suscribirte instrument.state.option.BTC para ver los eventos cada vez que una opción de BTC aparezca en la lista o caduque. Muchos usuarios institucionales se suscriben a instrument.state.any.any (todos los instrumentos) para impulsar su lógica de gestión de suscripciones. Esto es mucho mejor que las encuestas /public/get_instruments repetidamente. De hecho, Deribit solicita explícitamente a los clientes que utilicen este canal en lugar de realizar consultas frecuentes sobre los instrumentos, lo que supone una carga innecesaria para el sistema. Al gestionar estas notificaciones, puede suscribirse automáticamente a los nuevos instrumentos que le interesen tan pronto como aparezcan y cancelar las suscripciones a los instrumentos que finalicen

      Sugerencia

      También puedes usar el public/get_expirations método para recuperar la lista actual de vencimientos válidos para una moneda y un tipo de instrumento determinados, lo que resulta útil para inicializar las suscripciones o verificar las fechas de caducidad cuando aparecen nuevos instrumentos.

  • Evite un sondeo REST excesivo: En relación con esto, prefiera los canales de suscripción en tiempo real a cualquier tipo de sondeo constante a través de REST. Por ejemplo, si desea operaciones o cotizaciones en vivo, no llame /public/get_last_trades o /public/get_order_book en un bucle: usa el feed WebSocket (trades.* y book.* canales) para enviarle actualizaciones. Las encuestas no solo introducen latencia (siempre estás retrasado en cuanto al intervalo de sondeo), sino que también consumen tus límites de frecuencia y añaden carga a los servidores de la API. Reserva REST para consultas poco frecuentes (instantáneas, datos históricos o sincronizaciones de estado ocasionales). La API de streaming está diseñada para proporcionarte datos puntuales. Utilízala para

  • Agrupa tus solicitudes de suscripción: Deribit te permite suscribirte a varios canales en una sola llamada a la API, lo que es mucho más eficiente que suscribirte uno por uno. Cuando tu conexión a WebSocket esté abierta, prepara una sola público/suscríbase llame con una variedad de todos los canales que desee. El sistema puede gestionar hasta 500 canales en un mensaje de suscripción, lo que debería ser más que suficiente en la práctica. La suscripción masiva reduce la sobrecarga (latencia y carga) de enviar muchas solicitudes pequeñas y garantiza que comiences a recibir todos los datos a la vez. Por ejemplo, en lugar de hacer 100 llamadas públicas o de suscripción distintas para 100 instrumentos, haz una llamada con una lista de «canales» de esos 100. En el siguiente fragmento se muestra una única solicitud para suscribir cuatro canales a la vez

{
 «jsonrpc»: «2.0",
 «identificación»: 42,
 «método»: «publicar/suscribirse»,
 «parámetros»: {
 «canales»: [
 «ticker.btc-perpetual.raw»,
 «Ticker.eth-perpetual.raw»,
 «Book.BTC-Perpetual.raw»,
 «Libro.eth-perpetual.raw»
 ]
 }

La respuesta confirmará que todos los canales están suscritos. El uso de un solo mensaje significa un retraso mínimo de ida y vuelta y un inicio sincronizado de tus feeds. (Si tienes muchísimos canales, puedes dividirlos en lotes (por ejemplo, 2 mensajes de 500 cada uno), pero evita enviar cientos de llamadas de suscripción a la API como spam

Gestión y rendimiento de conexiones

Utilice conexiones independientes para los datos de negociación y los datos de mercado. Quizás la práctica más importante para el rendimiento sea aísla el tráfico de tus pedidos de tu feed de datos. Deribit permite múltiples conexiones WebSocket (o FIX), y deberías aprovecharlas. Ejecute una conexión dedicada a suscripciones de datos de mercado, y otro (o varios) dedicado a entrada de pedidos y otras acciones privadas. La razón es que, si los combinas, una avalancha de datos entrantes puede congestionar la conexión y retrasar los comandos de pedido salientes o sus confirmaciones. Aunque la infraestructura de Deribit procesa los mensajes públicos (datos) y privados (pedidos) en subprocesos distintos, siguen compartiendo la misma canalización TCP en un socket. Una gran cantidad de comillas en JSON podría llenar el búfer de recepción de TCP o el ciclo de procesamiento de tu cliente, lo que significa que la próxima cancelación de un pedido podría quedarse detrás de una pila de mensajes entrantes. Al dividir los datos y las operaciones en distintos sockets, se asegura de que la oleada de acontecimientos del mercado no bloquee sus mensajes críticos sobre las operaciones

Sugerencia

Para obtener más información sobre la configuración de la conexión, consulte la Administración de conexiones: prácticas recomendadas artículo.

Sugerencia

La API FIX de Deribit ofrece un indicador ConnectionOnlyExecutionReports (etiqueta 9010 en Inicio de sesión) que pueden aislar aún más las actualizaciones de los pedidos si utilizas varias conexiones FIX para una sola cuenta. Si se establece en «Y» en una sesión FIX, esa sesión solo recibirá informes de ejecución de las órdenes que haya realizado, no de las órdenes de las demás sesiones. Esto puede resultar útil si tiene dos o más algoritmos de negociación activos que utilizan conexiones FIX independientes.

Supervise el estado y la latencia de su conexión: los flujos de datos de alto rendimiento, es importante estar atento a cualquier signo de retraso. Deribit incluyechange_id y prev_change_id en las actualizaciones del libro de pedidos, incrementales trade_id o timestamps para operaciones, etc.): utilízalos para detectar si te has perdido un mensaje (por ejemplo, un espacio en la secuencia). Si sospecha que ha perdido datos (quizás debido a un problema momentáneo con la red), puede llamar a los puntos finales REST del siguiente modo /public/get_order_book para resincronizar. Es poco frecuente, pero mantener un mecanismo de resiliencia es una buena práctica para cualquier feed

Por último, optimice la ubicación de su red. Los servidores principales de Deribit están en Londres (Equinix LD4). Si la baja latencia es crucial, aloja a tu cliente lo más cerca posible de Londres o incluso plantéalo servicios de ubicación conjunta. La latencia y el enrutamiento de Internet pueden variar: muchos operadores serios utilizan conexiones cruzadas. Incluso el hecho de que un balanceador de carga añada aproximadamente 1 ms o el retraso intercontinental de 50 ms pueden ser importantes en las operaciones de alta frecuencia. Si estás en la otra punta del mundo y no puedes mudarte, usa el AWS Multicast (en las regiones de Tokio o Londres) podría ser la segunda mejor opción para lograr la igualdad de condiciones.

Resumen

Al utilizar las directrices anteriores, puede crear un sistema de recopilación de datos de mercado que sea rápido y sólido:

  • Elige el feed correcto — Utilice WebSockets o FIX para obtener datos en tiempo real (tienen un rendimiento similar) y, si necesita una latencia ultrabaja, explore el feed de multidifusión de Deribit o el multicast de AWS. De lo contrario, los feeds predeterminados son suficientes

  • Sin procesar frente a agregado — Suscríbase a los feeds de libros y operaciones sin procesar solo si realmente necesita todos los puntos. De lo contrario, opta por actualizaciones de 100 ms o agregadas para reducir el ruido. El sistema de Deribit te agradecerá que utilices canales agregados siempre

  • Minimizar el volumen de datos — Filtre sus suscripciones solo para ver lo que necesita. Evite los comodines que arrojan datos innecesarios sobre usted. Usa varios canales específicos en lugar de una enorme

  • Suscríbase de forma inteligente — Agrupa las suscripciones en una sola solicitud (hasta 500 canales) para mayor eficiencia. Utilice el instrumento.estado feed para ver los nuevos anuncios y las fechas de caducidad para que puedas adaptar tus suscripciones en tiempo real.

  • Aislar las conexiones — Utilice siempre conexiones independientes para los datos del mercado y para la ejecución de las órdenes. Este aislamiento evita que los aumentos repentinos de datos retrasen sus operaciones. Si utiliza varias conexiones en FIX, tenga en cuenta la etiqueta 9010 para evitar

Si sigue estas mejores prácticas, se asegurará de recibir las actualizaciones de mercado más rápidas posibles de Deribit y de manera fiable, lo que le permitirá reaccionar rápidamente en el mercado y, al mismo tiempo, mantener un sistema estable. ¡Felices operaciones!