2011-08-10 7 views
8

Je suis à la recherche d'un cadre de type cron distribué pour Python, et a trouvé du céleri. Cependant, le docs dit: "Vous devez vous assurer qu'un seul planificateur est en cours d'exécution pour une planification à la fois, sinon vous finiriez avec des tâches en double", Celery utilise celery.beat.PersistentScheduler qui stocke la planification dans un fichier local. Donc, ma question, y a-t-il une autre implémentation que la valeur par défaut qui peut mettre la planification "dans le cluster" et coordonner l'exécution des tâches pour que chaque tâche ne soit exécutée qu'une seule fois? Mon objectif est de pouvoir exécuter celerybeat avec des horaires identiques sur tous les hôtes du cluster.Planificateur de céleri distribué

Merci

Répondre

0

Je pense qu'il pourrait y avoir un malentendu sur ce celerybeat fait. Celerybeat ne traite pas les tâches périodiques; il ne les publie que Il met les tâches périodiques dans la file d'attente à traiter par les travailleurs de celeryd. Si vous exécutez un seul processus celerybeat et plusieurs processus celeryd, l'exécution de la tâche sera distribuée dans le cluster.

+1

Je comprends que, ce que je veux est d'être en mesure d'exécuter plusieurs instances de celerybeat, donc je peux éviter le risque que si l'hôte qui exécute celerybeat tombe en panne la programmation s'arrête. C'est à dire. un planificateur en cluster. –

+1

Ok alors la réponse est non. Voir https://github.com/ask/celery/issues/251 –

+0

Ok merci. Dommage qu'il ne l'ait jamais fait à 2,3 ... –

0

Nous avons eu ce même problème où nous avions trois serveurs fonctionnant Celerybeat. Cependant, notre solution consistait à exécuter Celerybeat uniquement sur un serveur unique afin de ne pas créer de tâches en double. Pourquoi voudriez-vous que Celerybeat fonctionne sur plusieurs serveurs?

Si vous craignez que Celery ne tombe en panne, créez simplement un script pour surveiller que le processus Celerybeat est toujours en cours d'exécution.

$ ps aux | grep celerybeat 

Cela vous montrera si le processus Celerybeat est en cours d'exécution. Ensuite, créez un script où, si vous voyez que le processus est en panne, envoyez un courriel à vos administrateurs système. Here's a sample setup où nous exécutons uniquement Celerybeat sur un serveur.

+3

Pas vraiment une réponse ici. C'est plus comme une solution de contournement. Le problème se pose lors du déploiement, supposons que vous devez distribuer l'application sur plusieurs nœuds homogènes; en veillant à ce que seulement un nœud exécute le planificateur signifie avoir une procédure de déploiement pour tous les nœuds et une autre procédure de déploiement juste pour le "nœud du planificateur" – Sdra

1

tl; dr: Aucun Celerybeat ne convient pas à votre cas d'utilisation. Vous devez exécuter un seul processus de celerybeat, sinon vos tâches seront dupliquées. Je sais que c'est une très vieille question. Je vais essayer de faire un petit résumé parce que j'ai le même problème/question (en l'an 2018). En arrière-plan: Nous exécutons l'application Django (avec Celery) dans le cluster Kubernetes. Cluster (instances EC2) et Pods (~ conteneurs) sont autoscaled: simplement dit, je ne sais pas quand et combien d'instances de l'application sont en cours d'exécution.

Il est de votre responsabilité d'exécuter un seul processus du celerybeat, sinon, vos tâches seront dupliquées. [1] Il y avait cette demande de fonctionnalité dans le référentiel de Céleri: [2]

obligeant l'utilisateur à faire en sorte que seule instance de celerybeat existe à travers leur groupe crée une mise en œuvre importante charge (soit créer un point de défaillance unique ou encourager les utilisateurs à lancer leur propre mutex distribué). Celestbeat devrait soit fournir un mécanisme pour empêcher la simultanéité , ou la documentation devrait suggérer une approche de meilleure pratique .

Après un certain temps, cette demande de fonctionnalité a été rejetée par l'auteur de Céleri par manque de ressources. [3] I   recommande fortement de lire l'intégralité du fil sur le Github. Les gens là-bas recommandent ces projets/solutions:

Je n'ai pas essayé quoi que ce soit de ce qui précède (je ne veux pas une autre dépendance mon application et je n'aime pas les tâches de verrouillage/vous devez faire face à fail-over etc /). J'ai fini avec CronJob dans Kubernetes (https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/).

[1]celerybeat - multiple instances & monitoring

[2]https://github.com/celery/celery/issues/251

[3]https://github.com/celery/celery/issues/251#issuecomment-228214951