Hacer llamadas a la API con apio

8

Estoy diseñando un sistema para un cliente donde los requisitos son:

  • suben un archivo JSON (un objeto / línea)
  • realice una llamada a una API con el objeto JSON como carga útil
  • registrar el estado (éxito / fracaso) de cada llamada a la API en una base de datos
  • haz un reintento si hay un error.

Decidí desarrollarlo utilizando apio y una base de datos sqlite como backend. El número de líneas JSON no es grande, quizás un par de millones como máximo, lo que encajará en la memoria. Tengo todos los componentes individuales funcionando bien (puede cargar archivos, leer archivos, llamar API, escribir en db, etc.), pero no estoy seguro de la arquitectura general de las tareas de despacho que utilizan apio.

Suponiendo que hay N líneas en el archivo, debería:

Opción A:

  1. Cree N objetos en la base de datos con una columna result (inicialmente nula).
  2. Cree N tareas de apio y pase la identificación del objeto como el parámetro y la carga útil
  3. Haga que la subtarea llame a la API y actualice el campo de resultados del objeto para que tenga éxito / falla.
  4. Deje que la función de reintento de apio intente volver a llamar a la API en caso de error.

Opción B:

  1. Cree N objetos en la base de datos con una columna result (inicialmente nula).
  2. Cree 1 tarea de apio y pase la lista completa de N identificadores de objeto y N cargas útiles
  3. Recorra todos los objetos N y actualice la base de datos con el resultado en cada paso.
  4. Cuando finaliza la tarea anterior, se ejecuta otra tarea de apio de una sola vez que lee la base de datos de todos los objetos con resultados fallidos y los reintenta.

Estoy a favor de la opción A debido a su simplicidad, pero no sé cuáles son los límites en el número de tareas de apio que se pueden programar y si el intermediario (RabbitMQ) lo manejará. Con la opción B, el gran riesgo es que si la tarea de apio se terminara por algún motivo en alguna línea M, entonces nunca se intentarán todos los siguientes objetos.

¿Alguna idea sobre estos dos o si hay una tercera alternativa mejor?

    
pregunta user154706 26.04.2015 - 02:49

1 respuesta

0

La opción A suena como el camino a seguir, ya que puede configurar a los trabajadores la API de forma independiente en lugar de tareas enormes que solo un trabajador puede gestionar.

Tengo un escenario muy similar usando kombu y Celery:

  • Recibimos un mensaje publicado en RMQ por alguna integración a una cola RMQ
  • Tenemos un evento de consumo de kombu que drena
  • Cuando se recibe el evento, ejecutamos la devolución de llamada (publicación en la cola de python local)
  • apio recibe el mensaje enviado a través de la cola de python y lo procesa
  • Una vez finalizado, devuelve los resultados y transmitimos el mensaje a un productor de kombu
  • El productor publica en RMQ

Como puede ver, utilizamos básicamente el mismo enfoque que usted. Tenemos esto en producción manejando alrededor de 2000 mensajes por hora sin ningún problema.

    
respondido por el ZeroSoul13 20.05.2015 - 08:27

Lea otras preguntas en las etiquetas