5. En asynchrone
• monitorer la dispo de vos ressources CPU (=workers);
• lancer une tâche quand un worker se libère;
• surveiller si la tâche se termine (et si elle se termine
bien…);
• en cas de problème, réessayer ou alerter.
D’où le besoin pour un gestionnaire de file d'attentes =
Message Queue dans la langue de Shakespeare.
6. En Python
• Celery : la plus connue
• rq : alternative light
• bindings Python à ØMQ : construisez votre
propre gestionnaire !
• pleins d'autres projets (Mozilla en a mis
plusieurs en OSS)
7. Celery 1/3
• A commencé comme une app django
• Désormais autonome (mais toujours une intégration
avec django=dj-celery)
• Gros projet, énormément de fonctionnalités out-of-
box : c'est un framework à lui tout seul
• Nombreux backends (RabbitMQ, redis, Mongo,
MySQL…)
8. Celery 2/3
• Le gros pb : toutes les fonctionnalités ne sont pas dispo avec tous
les backends !!
• Choisir un backend, c'est éventuellement se couper de plein de
fonctionnalités…
• Le backend (RMQ) recommandé est loin d'être le plus efficace :
– Impossible de réessayer une tâche qui a plantée;
– Pas de gestion des priorités;
• Le code évolue beaucoup et vite : c'est bien mais ça peut vous
amener à réécrire pas mal de code juste pour suivre les
changements de Celery
9. Celery 3/3
Un framework:
• Comme tous les frameworks, requiert du temps
pour bien le maîtriser
• Bien lire la doc, notamment le tableau qui liste
les options dispo en fonction des backends
• Peut être arrivé un peu tôt.
10. rq
• Plus simple
• Doc minimaliste (mais il y a moins à dire)
• Redis est le broker
• Unix only
• Taillé pour Heroku et les services similaires
