Trabaja con celerybeat como un único punto de falla

Question

Estoy buscando la solución recomendada para evitar que apio cebo sea un punto único de falla para el despliegue de apio/rabbitmq. No encontré nada que tuviera sentido hasta ahora, al buscar en la web.

En mi caso, una vez al día, el programador programado da inicio a una serie de trabajos que podrían durar medio día o más. Como solo puede haber una instancia de celerybeat, si algo le sucede o el servidor en el que se ejecuta, los trabajos críticos no se ejecutarán.

Espero que ya haya una solución de trabajo para esto, ya que no puedo ser el único que necesita un planificador confiable (en clúster o similar). No quiero recurrir a algún tipo de planificador respaldado por la base de datos, si no es necesario.

Answer 1

Hay un problema abierto en apio github repo sobre esto. No sé si están trabajando en eso.

Como solución alternativa, puede agregar un bloqueo para las tareas para que solo se ejecute una instancia de PeriodicTask específica a la vez.

Algo así como:

if not cache.add('My-unique-lock-name', True, timeout=lock_timeout): 
    return 

Averiguar tiempo de espera de bloqueo es así, difícil. Estamos utilizando 0.9 * tarea run_every segundos si diferentes apios tratarán de ejecutarlos en diferentes momentos. 0.9 solo para dejar un poco de margen (por ejemplo, cuando el apio está un poco retrasado una vez, entonces está dentro del cronograma lo que causaría que el bloqueo aún esté activo).

A continuación, puede utilizar la instancia de celerybeat en todas las máquinas. Cada tarea se pondrá en cola para cada instancia de celerybeat, pero solo una de ellas finalizará la ejecución.

Las tareas seguirán respetando run_every de esta manera; en el peor de los casos: las tareas se ejecutarán a 0.9 * run_every speed.

Un problema con este caso: si las tareas se pusieron en cola pero no se procesaron en el tiempo programado (por ejemplo porque los procesadores de cola no estaban disponibles), el bloqueo puede colocarse en el momento incorrecto y posiblemente la siguiente tarea simplemente no se ejecute. Para evitar esto, necesitarías algún tipo de mecanismo de detección, ya sea que la tarea esté más o menos a tiempo.

Aún así, esta no debería ser una situación común cuando se utiliza en producción.

Otra solución es subclasificar el programador Apio de celer y anular su método de marcación. Luego, por cada tic, agregue un candado antes de procesar las tareas. Esto asegura que solo los apios con las mismas tareas periódicas no colaran las mismas tareas varias veces. Solo un celerybeat para cada tic (uno que gane la condición de carrera) pondrá tareas en cola. En un celerybeat baja, con el siguiente tick otro ganará la carrera.

Esto, por supuesto, se puede utilizar en combinación con la primera solución.

Por supuesto, para que esto funcione, el backend de caché debe ser replicado y/o compartido para todos los servidores.

Es una vieja pregunta, pero espero que ayude a cualquiera.