es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

Arquitectura de backend distribuido de la aplicación de Stock.

Información general

Estoy construyendo una aplicación de stock como un proyecto secundario y esta es la arquitectura actual que estoy usando:

  • Frontend de React con la biblioteca de sockets @microsoft/signalr
  • Backend de ASP.NET Core con SignalR Hub para manejar los sockets del cliente
  • API REST de Polygon.io como fuente de datos financieros
  • Redis para almacenar las cotizaciones de acciones para que varios nodos de API puedan consultar los datos

Aquí hay un ejemplo de la arquitectura preliminar que he ideado:

enter image description here

Algunos desafíos
– Las cotizaciones de las acciones deben actualizarse cada segundo/cada pocos segundos para una buena experiencia de usuario
– Varios clientes comparten suscripciones a las mismas acciones
– Solo en la NYSE hay n=11,750 acciones posibles a las que suscribirse

El mecanismo de actualización actual

Cliente 1

  • Cliente #1 se conecta a Nodo de API #1
  • Cliente #1 se suscribe a $AAPL, $TSLA
  • Nodo de API #1 inicia un temporizador, cada 2 segundos obtiene datos de Redis y busca las claves AAPL y TSLA para ver si existen valores, si faltan valores, obtiene los datos faltantes de Polygon, luego los almacena en Redis y almacena en caché las claves durante 3 segundos.
  • Se devuelve la mezcla de datos en caché/nuevos a Cliente #1

Cliente 2

  • Cliente #2 se conecta a Nodo de API #2
  • Cliente #2 se suscribe a $AAPL, $TSLA, $GOOG, $AMZN
  • Comparte las suscripciones de $AAPL y $TSLA con Cliente #1
  • Nodo de API #2 inicia un temporizador, cada 2 segundos obtiene datos de Redis y busca las claves AAPL, TSLA, GOOG, AMZN para ver si existen valores, si faltan valores, obtiene los datos faltantes de Polygon, luego los almacena en Redis y almacena en caché las claves durante 3 segundos.
  • Se devuelve la mezcla de datos en caché/nuevos a Cliente #2

El problema

Cliente #1 y Cliente #2 comparten suscripciones y a veces intentarán actualizar las mismas claves en Redis y obtener datos de Polygon para las mismas acciones. ¿Cuál sería la forma más eficiente para que los nodos de API actualicen las acciones?

Soluciones para una escalabilidad eficiente

¿Debería crear un trabajador central que consulte a Polygon.io y actualice TODAS las suscripciones agregadas de acciones en Redis, y los nodos de API solo obtengan datos de la caché de Redis?

Tags:  , , , ,

Answer

  1. Avatar for davy.ai

    Solución: Trabajador Centralizado de Actualización de Stock

    Para escalar eficientemente el proceso de actualización de stock y evitar conflictos entre los nodos de la API, se puede implementar un trabajador centralizado para consultar a Polygon.io y actualizar todas las suscripciones de stock agregadas en Redis. Este trabajador se encargaría de actualizar los datos para todos los clientes, eliminando la necesidad de que varios nodos de API consulten independientemente a Polygon.io y almacenen los datos en Redis. En cambio, los nodos de la API simplemente pueden consultar la caché de Redis para obtener la información más reciente de stock.

    Ventajas del Trabajador Centralizado de Actualización de Stock

    • Elimina los conflictos entre los nodos de la API al actualizar la misma información de stock en Redis
    • Reduce la carga en la API de Polygon.io al consolidar las solicitudes de información de stock en una única consulta
    • Simplifica la implementación del proceso de actualización de stock para los nodos de la API
    • Mejora la escalabilidad y el rendimiento general de la aplicación de stock

    Consideraciones para el Trabajador Centralizado de Actualización de Stock

    • El trabajador debe estar diseñado para manejar grandes volúmenes de información de stock de manera eficiente
    • El trabajador debe ser tolerante a fallos y manejar errores y excepciones de manera adecuada
    • La transferencia de datos entre el trabajador y Redis debe estar optimizada para garantizar un rendimiento eficiente
    • El trabajador debe estar diseñado para manejar actualizaciones para varios clientes y múltiples nodos de API

    En general, implementar un trabajador centralizado de actualización de stock sería una solución escalable y eficiente para manejar las actualizaciones de stock en un entorno de múltiples clientes.

Comments are closed.