MongoDB en tant que service de file d'attente?
J'aimerais en savoir plus sur l'expérience réelle des applications avec MongoDB en tant que service de file d'attente. Si vous utilisiez MongoDB à cette fin, pourriez-vous donner votre point de vue, ainsi que l'environnement dans lequel il a été utilisé?
J'utilise mongodb en tant que service de file d'attente pour l'envoi de courriers électroniques. Bientôt cela fonctionnera de la manière suivante:
- Quand un nouveau message arrive je le stocke dans le mongodb.
- Un travail en arrière-plan charge ensuite le message de mongodb via l'opération atomique findAndModify et définit l'indicateur
Processingsur true afin qu'il ne traite pas le même message deux fois (car mon travail en arrière-plan exécute plusieurs threads en parallèle). - Une fois l'e-mail envoyé, je supprime le document de mongodb.
- Vous pouvez également garder le nombre d'échecs pour chaque message et le supprimer après 3 tentatives infructueuses.
En général, j'utilise mongodb en tant que service de file d'attente uniquement pour une raison: parce que je dois envoyer des courriers électroniques selon un calendrier spécifié (chaque message contient des informations sur l'heure à laquelle il doit être envoyé).
Si vous n'avez pas de calendrier et que vous devez traiter le message immédiatement, je vous suggère de consulter les services files d'attente existants, car ils traitent probablement tous les cas que vous ne pouvez pas voir sans une compréhension plus approfondie des files d'attente de messages.
Mettre à jour
Lorsque le travail en arrière-plan se bloque pendant le traitement du message, vous pouvez procéder comme suit:
Déplacez ce message vers un autre, la collecte des erreurs de file d'attente des messages ou ..
Augmenter le nombre de tentatives de traitement dans un message et attribuer à nouveau le statut "Nouveau" pour essayer de le traiter à nouveau. Assurez-vous simplement que le travail en arrière-plan est idempotent (peut traiter le même message plusieurs fois et non des données corrompues) et transactionnel (lorsque le travail échoue, vous devez annuler les modifications apportées.). Lorsque le travail échoue après 5 tentatives (valeur de configuration), effectuez la tâche n ° 1.
Une fois que le bogue lié au traitement des messages a été corrigé, vous pouvez le traiter à nouveau en attribuant le statut "Nouveau" et en passant à la file d'attente des messages, ou simplement en supprimant ce message. Cela dépend des processus opérationnels.
Je sais que cette question est de retour de 2012, mais lors de mes propres recherches, j'ai trouvé cet article et je veux simplement informer tout autre utilisateur que les développeurs de serverdensity ont remplacé rabbitmq au profit d'un système de file d'attente simple avec mongodb.
Un article détaillé est donné ici:
https://blog.serverdensity.com/replacing-rabbitmq-with-mongodb/
Voici un excellent article expliquant comment une personne a utilisé le journal des opérations de réplication de mongoDB en tant que file d'attente.
Vous pouvez faire la même chose avec une collection différente. Le conseil principal semble être d’utiliser une collection capped - les pilotes mongo disposent d’un moyen efficace d’attendre une collection plafonnée afin que le client ne soit pas constamment interrogé.
Voici ma implémentation Python de PubSub/queue Elle fonctionne soit en faisant glisser un curseur sur une collection limitée, soit en interrogeant une collection normale. résultats. Bien sûr, comme quelqu'un l'a déjà mentionné jusqu'à ce que vous atteigniez les limites de la recherche atomique Et modifie, mais cela peut être pris en charge par diverses techniques
J'ai beaucoup cherché et trouvé la version JavaScript https://github.com/chilts/mongodb-queue . Mais je veux une version go, donc Une implémentation simple dans Go, incluant un gestionnaire pour interroger les messages a été faite: https://github.com/justmao945/mongomq
Voici une simple file de messages implementation .
C'est une partie de article qui évalue les performances de divers systèmes de file d'attente de messages.
Une configuration à un seul thread et à un seul nœud génère 7 900 msgs/s envoyés et 1 900 msgs/s reçus.