Celery: Proposition de dépréciation de Redis en tant que support de courtier. [Rejeté]

De nos jours, des alternatives au céleri existent, par exemple huey et rq qui se concentrent explicitement sur la prise en charge de redis en tant que courtier. Quand le céleri est sorti, il n'y avait rien.

@demandez -vous que pensez-vous également de l'abandon de la prise en charge du courtier SQL ? Je doute qu'il y ait beaucoup de gens qui utilisent une base de données SQL en production. Même s'ils le font, ils ne devraient pas le faire.
Nous avons également docker, ce qui signifie que le déploiement de rabbitmq est littéralement à une commande. Ce n'est plus _que_ difficile.

Je viens de supprimer la prise en charge de SQL en tant que courtier, y compris tous les autres courtiers autres que RabbitMQ / Redis / SQS / Qpid :)

(dupliquer)

Je ne suis pas si lié à la communauté du céleri; quel que soit mon 0,02 $ :

• Redis est vraiment populaire - à peu près aussi populaire que tous les autres courtiers pris en charge _combinés_ , si vous pensez que Google Trends est représentatif
• Il est capable d'être un très bon courtier _et_ backend (RabbitMQ aussi)
• Il est uniquement proposé par les grands fournisseurs de cloud en tant que service entièrement géré
• Nous utilisons beaucoup Redis !

Je peux comprendre vos sentiments concernant les problèmes de maintenance, et ce type d'action est un pas vers la durabilité. Mais y a-t-il d'autres « amputations » que vous pourriez faire ?

Du côté « approvisionnement » de l'équation, avez-vous une idée de la raison pour laquelle il n'y a pas plus de contribution au céleri de la part de la communauté ?
Un examen rapide des commits et des PR suggère que le céleri est principalement le travail d'une personne, par rapport à quelques bibliothèques open source auxquelles je contribue

@MaximilianR Parlant uniquement pour moi-même :

1. Il s'agit d'une base de code importante dans laquelle entrer
2. Surtout si vous n'êtes pas un expert en kombu et ayncio
3. Et vous n'avez pas d'intuitions sur la profondeur des problèmes signalés

Cela dit, j'utilise du céleri, donc s'il y a un moyen de me rendre utile, je serais heureux de vous aider.

@MaximilianR , Il y a eu de nombreux contributeurs, mais j'ai certainement fait beaucoup de travail. Le projet a grandi trop vite, et à un moment donné, j'ai eu le choix entre corriger des bogues ou soutenir les utilisateurs sur IRC/email/StackOverflow etc. encadrer les gens. Nous étions à ce moment-là presque de la taille de RabbitMQ en téléchargements, mais là où ils avaient 8 personnes travaillant à temps plein, j'étais le seul.

Il y a probablement d'autres choses à amputer, mais je ne pense pas que quoi que ce soit prenne autant de temps que Redis.

Le travail de portage d'amqp/kombu vers l'asyncio complet a également été une perte de temps importante, mais nécessaire pour résoudre un certain nombre de problèmes. Il n'a jamais terminé cependant.

@ask Votre message ci-dessus signifie-t-il que vous êtes toujours intéressé à faire des efforts dans SQS ? J'ai remarqué qu'il n'y a qu'un seul ticket SQS ouvert ici, mais je vois toujours l'avertissement "Expérimental" dans la documentation. Pouvez-vous nous renseigner sur l'état actuel et les besoins futurs de la SQS ?

Nous utiliserions Celery + SQS en production, donc je pourrais peut-être y contribuer, mais je ne veux pas vraiment entrer dans cette situation si SQS ne fait pas partie de votre plan à long terme pour le projet.

@ask merci d'avoir partagé cela ci-dessus. Je peux comprendre d'où vous venez. J'espère qu'à travers cette / d'autres approches, le céleri pourra être plus facile à entretenir et continuer son succès...

Faites certainement ce qui est le mieux pour votre projet, mais je vais certainement pousser à me débarrasser de Celery, en interne, si le support Redis est abandonné. Je développerai en privé si vous voulez vraiment savoir pourquoi nous n'utiliserons pas RabbitMQ, mais je ne veux pas vraiment critiquer d'autres projets en public.

Connexe : suggérer qu'il s'agit d'une commande parce que c'est ainsi que vous développez, sur Docker, peut fonctionner pour vous, mais ce n'est pas nécessairement ainsi que le reste d'entre nous se déploie.

@nicksloan SQS est maintenant répertorié comme un transport pris en charge dans les documents principaux : http://docs.celeryproject.org/en/master/getting-started/brokers/index.html

Le travail de réécriture du transport SQS en utilisant les E/S async a été financé pour un peu plus de 1000 $.

@scoates Le transport Redis est dans une situation pire car il est vraiment piraté pour utiliser les E/S asynchrones pour la lecture des messages, mais la publication est toujours synchrone. La bibliothèque Python redis est synchrone, il existe donc encore de nombreux défis, même pour la lecture des messages, et beaucoup d'incertitudes sur son fonctionnement. Des bugs peuvent facilement s'y cacher, et toute modification apportée à la bibliothèque redis-py pourrait avoir des effets drastiques lorsque nous l'utilisons de manière non-orthodoxe.

Je veux soutenir Redis, vraiment. Je me battais pour cela quand je travaillais chez RabbitMQ/Pivotal car je sentais que nous avions besoin d'une solution commune en Python pour les modèles que Celery implémente. Mais si la communauté et les entreprises qui l'utilisent ne s'investissent pas pour le faire fonctionner, alors je me retrouverai à lutter contre les incendies et au pire comme maintenant incapable de résoudre de graves problèmes de transport qui amènent les gens à critiquer le projet. Cela rend ma vie plus misérable et diminue le moral.

C'est peut-être trop radical compte tenu de l'histoire du céleri, mais avez-vous pensé à ne garder que Redis sur RabbitMQ ?

@MaximilianR J'y ai pensé, mais ma passion est la transmission de messages et la construction de systèmes distribués corrects. Redis doit encore nous fournir une implémentation de BRPOPLPUSH qui fonctionne pour implémenter des accusés de réception de message, et avec la révélation de l'incapacité d'accepter qu'il est impossible de se fier à l'heure de l'horloge murale dans les systèmes distribués, un fait fondamental, je suis plus méfiant. RabbitMQ attaque au moins sérieusement l'espace à problèmes, et il y a d'autres joueurs comme Kafka et NSQ. Beaucoup de bibliothèques traitent les files d'attente de tâches comme une simple opération de liste, mais je refuse que Celery en fasse partie :)

@scoates : Je ne parlais pas de la façon dont je développe ou quelque chose du

Merci @ask d' avoir vérifié avec nous. Le céleri est un excellent produit et étant donné les ressources limitées dont vous (et la communauté) disposez, je pense que se concentrer sur le produit de base est la meilleure décision. Je peux imaginer à quel point il doit être difficile d'essayer d'offrir les mêmes fonctionnalités exceptionnelles en utilisant de nombreux systèmes incompatibles différents. Du point de vue du consommateur, je pense que cela ajoute à la complexité du produit d'avoir autant d'options. Je suis sûr que cela va probablement bouleverser certains de vos utilisateurs, mais je pense que s'en tenir à moins de courtiers est la bonne chose à faire pour le produit. J'aimerais voir l'accent mis sur AMQP car c'est un protocole standard bien accepté et je pense que rabbitmq en est une très bonne implémentation.

C'est triste qu'il n'y ait pas vraiment beaucoup de travail à faire, mais lorsque vous additionnez tout cela à travers tous les transports et fonctionnalités, ce n'est pas durable avec seulement quelques heures par semaine.

Étant donné que le protocole Redis est si simple, la réécriture du transport pour qu'il soit entièrement async n'a pas à être si difficile. J'ai créé une couche qui permet à Celery de prendre en charge n'importe quelle bibliothèque Tornado, la même chose pourrait être faite pour asyncio et Twisted, nous pouvons donc même avoir des clients que nous pouvons réutiliser.

Python change radicalement avec asyncio dans stdlib. Nous avons besoin de nouveaux frameworks Web, de nouvelles bibliothèques de réseaux et à peu près tout l'écosystème doit s'adapter. Cela rend notre travail un peu plus facile puisque nous n'avons plus à maintenir notre propre boucle d'événements, mais la transition nécessitera un peu de travail.

Je souhaite également écrire un nouveau travailleur en Go ou similaire maintenant que nous avons un nouveau protocole de message avec prise en charge de plusieurs langues. Redis n'est pas la meilleure solution pour l'interopérabilité de la messagerie, car il n'implémente pas les en-têtes de message, les propriétés, etc. Le protocole AMQP a définitivement le dessus car c'était l'un des cas d'utilisation d'origine.

@ask Mon approche était d'essayer de faire en sorte que les entreprises maintiennent leurs courtiers. Essayons donc de parler avec quelqu'un des laboratoires Redis et voyons si nous obtenons une traction.
La même chose pour MongoDB et d'autres services.
Quant aux courtiers SQL, je pense qu'ils ne sont pas une très bonne idée et nous ne devrions pas les soutenir.
Nous pouvons extraire le code au lieu de le supprimer, et chercher quelqu'un pour le maintenir. S'il n'y a pas assez d'intérêt, alors il n'y a pas besoin d'eux.
La seule base de données SQL qui peut en quelque sorte être un courtier est Postgres car elle a des capacités Pub/Sub mais qui n'est pas actuellement implémentée de toute façon.

Je pense que nous pouvons simplement le déprécier et voir ce qui se passe. Peut-être que quelqu'un se mobilise, en prenant en charge la maintenance ou en parrainant. Sinon, nous avons un produit dont les gens ont besoin, mais personne ne veut le soutenir, ce qui est probablement avec 18 votes au total à ce stade. Je ne pense pas que cela influencera seul Redis Labs :)

Mais si la communauté et les entreprises qui l'utilisent ne s'investissent pas pour le faire fonctionner, alors je me retrouverai à lutter contre les incendies et au pire comme maintenant incapable de résoudre de graves problèmes de transport qui amènent les gens à critiquer le projet. Cela rend ma vie plus misérable et diminue le moral.

Nous utilisons du céleri avec le courtier redis sur plusieurs projets et en dépendons, mais je suis tout à fait d'accord avec ce sentiment. Si vous ne pouvez pas le maintenir à un niveau de qualité élevé, cela ne fera que donner une mauvaise réputation au céleri et rendre tout le monde malheureux - vous _et_ les utilisateurs.

Salut. Je travaille pour Redis Labs et jusqu'à récemment j'étais un utilisateur de céleri. @thedrow a attiré mon attention sur ce point, et nous en avons discuté en interne. Nous sommes prêts à vous aider, nous pensons qu'il est important de garder le redis dans le cadre du céleri. Je ne sais pas encore si je le ferai personnellement ou par quelqu'un d'autre, mais laissons passer la discussion sur ce qui doit être fait.

Comme @dvirsky, mon travail sur Redis est entièrement sponsorisé par Redis Labs, et si nous pouvons aider avec ce backend (j'espère que oui), je serai impliqué pour aider à trouver les meilleures solutions du côté de Redis, et potentiellement même étendre le support de la messagerie Redis afin de faciliter certaines choses dans la mise en œuvre. Nous pourrions également souligner la capacité du backend à utiliser Sentinel / Redis Cluster à un moment donné afin d'avoir une expérience prête pour la haute disponibilité. J'espère que nous aurons de bonnes nouvelles dès que possible, en évaluant actuellement les efforts nécessaires.

C'est une très bonne nouvelle! Je comprends parfaitement que vous vouliez connaître le travail impliqué avant de vous y engager :)

Il est 3 heures du matin et je n'ai pas rassemblé de liste de problèmes, mais voici quelques brèves notes :

Celery ne définit pas un ensemble de fonctionnalités qui sont implémentées avec une interface vers Redis, à la place
il utilise l'API AMQP pour utiliser la messagerie de manière générique. Messagerie nom vers file d'attente, routage pub/sub et rubrique. Le routage des sujets n'est pas une exigence stricte, mais le reste est essentiel aux principales fonctionnalités de Celery, à savoir 1) gérer les messages de tâche, 2) envoyer/recevoir des événements de surveillance et 3) diffuser des messages aux travailleurs pour les gérer (par exemple, arrêt/augmentation de la simultanéité/etc. ).

1) Doit être asynchrone pour ne bloquer le travailleur pour aucune opération

La version actuelle utilise la bibliothèque redis-py, qui est synchrone. J'ai piraté ceci pour faire
il consomme les messages de manière asynchrone, mais je soupçonne qu'il y a encore des bogues car nous ne savons pas exactement ce qui se passe dans le client. Il se peut qu'il y ait déjà des clients redis asynchrones disponibles pour
Tornade/asyncio que nous pourrions utiliser, ou dans le pire des cas puisque nous n'avons pas besoin de beaucoup de choses à faire cru peut ne pas
être si délicat.

2) Gestion des connexions

Nous avons une connexion qui consomme des tâches et une connexion qui fait du pubsub, puis un pool
de connexions pour effectuer des opérations hors bande, comme l'accusé de réception de messages ou la restauration de messages non acquittés. Il existe une certaine confusion autour de la gestion des erreurs ici, et nous ne fermons peut-être pas toutes les connexions après utilisation.

3) Accusé de réception du message

Les messages ne sont supprimés du serveur qu'après leur acquittement et nous avons un délai de visibilité où tous les consommateurs de messages essaient de restaurer les messages. Eh bien c'est le bordel,
Je pourrai décrire cela plus en détail plus tard.

Merci @ask , à propos du point "1", il peut être judicieux d'implémenter directement le support Redis asynchrone minimal dont nous avons besoin pour les quelques commandes que nous envoyons directement à l'intérieur du courtier au lieu de dépendre d'une bibliothèque externe.

Notez que seulement 2, et peut-être d'autres petits problèmes nécessitent une solution rapidement. Cela fonctionne en grande partie, mais il existe des cas où des messages peuvent être perdus en raison de l'accusé de réception du message, mais c'est un élément de la liste de souhaits car la situation était bien pire avant l'émulation de l'accusé de réception. Le nœud de calcul peut être bloqué par le client Redis synchrone, ce qui entraîne de mauvaises performances et, dans de rares cas, des nœuds de calcul suspendus.

1) Doit être asynchrone pour ne bloquer le travailleur pour aucune opération

La dernière fois que j'ai vérifié, les clients redis asynchrones n'étaient pas parfaits (il y en a quelques-uns pour la tornade). Ce que j'ai souvent fait dans ces situations, c'était d'utiliser un exécuteur de pool de threads et des futures pour que redis-py se comporte comme un client asynchrone. tant que vous n'avez pas trop de tâches simultanées et que quelques threads suffisent, cela fonctionne mieux que les clients asynchrones.

EDIT : je n'ai pas encore travaillé directement avec l'asyncio de python, mais d'après ce que j'ai vu, c'est assez similaire à la tornade, donc ce modèle sera probablement facile à faire.

@dvirsky Nous ne sommes pas autorisés à utiliser des threads, car nous utilisons également fork . Python ne prend pas en charge ce cas, et même si un correctif était produit pour cpython, nous devrons soigneusement corriger les bibliothèques python existantes, au moins les extensions C, pour être en sécurité de cette manière. Cela a été réalisé sur le suivi des bogues Python il y a quelque temps, et c'est pourquoi nous avons effectué la migration vers les E/S asynchrones. Nous devons également nous déplacer là-bas en général, car c'est dans le futur de Python maintenant avec la prise en charge des E/S asynchrones de base.

@antirez re:

à propos du point "1", il peut être judicieux d'implémenter directement la prise en charge asynchrone minimale de Redis dont nous avons besoin pour les quelques commandes que nous envoyons directement à l'intérieur du courtier au lieu de dépendre d'une bibliothèque externe.

Je ne ferais pas ça. la plupart du code de redis-py tourne autour de la gestion des réseaux et des connexions, pas autour de l'implémentation de commandes...

@dvirsky Nous avons des génériques de gestion de connexion qui fonctionneraient parfaitement pour cela, donc cela ne devrait pas couler de temps. Nous n'avons pas beaucoup de réseaux, mais je pense que l'essentiel consiste à analyser le protocole et nous le faisons déjà presque manuellement ou en nous connectant aux classes redis existantes.

@ask oui, il y a embauché qui est une extension C dédiée pour l'analyse du protocole redis, IIRC peut également fonctionner avec un client asynchrone. quelle stratégie avez-vous choisie jusqu'à présent pour rendre redis async ?

Quoi qu'il en soit, je dois jeter un œil à ce qui s'est passé avec les clients asynchrones récemment, je n'ai pas beaucoup travaillé sur python au cours de la dernière année et demie. Je vois que https://github.com/leporo/tornado-redis n'a pas été très actif.

Il n'y a pas beaucoup de stratégie, nous ajoutons la socket à la boucle d'événement et envoyons par exemple BRPOP de manière synchrone, puis nous attendons que la socket soit lisible et nous lisons la réponse de manière synchrone ;)

Étant donné que nous n'avons aucun moyen de redémarrer au milieu de l'analyse de la réponse

@dvirsky Si nous utilisons hiringis pour autre chose que l'analyse de protocole, nous aurons des problèmes de compatibilité avec gevent/eventlet (lorsqu'il est utilisé au lieu du multitraitement) et cela rendra également embauché obligatoire les problèmes de portabilité si Celery est exécuté sur PyPy.

@dvirsky De plus, py-hiredis n'expose aucune fonctionnalité autre que l'analyse de protocole pour le moment.

Python aura besoin d'un client redis asynchrone décent à un moment donné, je crois, donc commencer quelque chose de approprié ne serait pas une mauvaise idée. Par exemple, refactoriser une partie du code d'analyse du protocole dans redis-py.

vous utilisez gevent en ce moment ?

@dvirsky Nous prenons en charge gevent, eventlet et le multitraitement (prefork) avec des E/S asynchrones. Mais si vous en soutenez un, vous avez généralement les autres.

Oui, il y a des moments où gevent est plus approprié pour les tâches. par exemple, lorsque les tâches écrivent simplement dans la base de données ou effectuent une requête HTTP.
Il est assez facile d'exposer et d'enregistrer les FD dans gevent, mais cela nécessite un travail supplémentaire dans py-hiredis.

@dvirsky Voici un exemple de la façon dont c'est fait avec PyCurl. https://gist.github.com/GuoJing/5875326
Vous devez exposer le FD afin de collaborer avec gevent.

J'ai récemment été initié au problème de la prise en charge du céleri pour Redis et bien que je n'aie pas terminé une analyse approfondie, je peux dire que l'écriture / la mise à niveau d'un client python redis avec asyncio semble être une bonne idée, mais d'après des références récentes, ce serait mieux implémenté sur asyncio+libuv pour obtenir autant de performances que possible.

Pour les références voir

• https://github.com/MagicStack/uvloop
• https://github.com/saghul/pyuv
• http://magic.io/blog/uvloop-blazing-fast-python-networking/

Contre cette position - ou pour compliquer les choses, je voudrais noter que d'après ma propre expérience avec les clients Redis, en tant que développeur et utilisateur, s'appuyer entièrement sur libuv empêchera en fait le client d'atteindre des performances maximales, et pour cela embauché est un must. Il y a une tonne de choses qui se passent sous le capot dans libuv qui ralentissent io dans certains cas, ioredis le fait via Node et ce n'est pas vraiment performant.

Donc, la solution que j'envisagerais a une implémentation mixte embauché-async. (En d'autres termes, un tas d'alternatives doivent être essayées avec des tonnes de sélection et d'analyse comparative)

@merl-dev Le problème est toujours PyPy où hiringis+cffi est plus lent à analyser le protocole redis que l'implémentation de l'analyseur de protocole python pur.
Au moins, ma version a également quelques échecs de test avec redis-py. Voir https://github.com/redis/hiredis-py/pull/46

Il est tout à fait possible d'écrire un client hiringis en tant qu'extension CPython. Je ne suis toujours pas sûr à 100% de CFFI.

allons s'en approprier

@thedrow cela me rappelle - avez-vous regardé la nouvelle fonctionnalité de flux redis ? Il peut être utilisé comme un courtier de messages beaucoup plus robuste que les éléments actuels. Ce sera bientôt l'AG.

Nous n'avons pas. Nous n'avons pas la capacité de refactoriser le courtier redis pour le moment.
Nous espérions que vous aviez des mains libres pour le faire.

@thedrow, nous pourrions juste… ne rien promettre, mais nous pourrions consacrer des ressources supplémentaires à la prise en charge proactive de l'écosystème redis.

@dvirsky tu veux dire cette proposition , non ? Vous pouvez donc utiliser TAPPEND pour mettre en file d'attente, TREAD + TACK pour retirer, traiter et accuser réception.

@georgepsarakis ce n'est plus une proposition, ça marche, et le préfixe est X, c'est-à-dire XADD. voir https://www.youtube.com/watch?v=ELDzy9lCFHQ

Alors, quel est le dernier appel à prendre en charge le courtier redis ? Est-ce que va bientôt être obsolète ?

Pas pour le moment.

Je ne saurais dire dans quelle direction la communauté penche, mais nous commençons un nouveau projet et j'hésite à utiliser Redis en tant que courtier en raison de l'idée de le déprécier. Les pensées?

Il est prudent de supposer que le courtier redis restera dans un avenir prévisible. Trop de gens s'en souviennent.

Pendant tout ce temps, les #301 / 601 deviennent périmés.

@ermik essaie d'aider à résoudre un problème connexe.