RabbitMQ utilise des bits immédiats et obligatoires
J'ai utilisé le serveur RabbitMQ et pour publier des messages lorsque le immédiat le champ a été défini vrai , J'ai essayé d'envoyer 50000 messages et d'utiliser rabbitmqctl list_queues, J'ai vu que le nombre de messages dans la file d'attente était zéro. Puis j'ai changé le immédiat drapeau à false et j'ai de nouveau essayé d'envoyer 50000 messages, puis d'utiliser rabbitmqctl list_queues J'ai vu que 100000 messages au total étaient dans les files d'attente (jusqu'à présent, aucun consommateur n'était présent)
Et après cela, j'ai commencé le consommateur et il a consommé tous les 100000 messages.Quelqu'un peut-il m'aider s'il vous plaît à comprendre immédiat champ de bits et ce comportement aussi. De plus, je ne pouvais pas comprendre le concept de obligatoire champ de bits.
Remercier à l'avance.
Gurpreet Singh.
Les champs immediate et mandatory font partie de la spécification AMQP, et sont également traités dans le RabbitMQ FAQ pour clarifier comment ses implémenteurs ont interprété leur signification:
Cet indicateur indique au serveur comment réagir si un message ne peut pas être acheminé vers une file d'attente. Plus précisément, si obligatoire est défini et après l'exécution des liaisons, le message a été placé sur zéro files d'attente, le message est renvoyé à l'expéditeur (avec un basic.return). Si obligatoire n'avait pas été défini dans les mêmes circonstances, le serveur abandonnerait silencieusement le message.
Ou selon mes mots, "Mettez ce message dans au moins une file d'attente. Si vous ne pouvez pas, renvoyez-le-moi."
Pour un message publié avec un ensemble immédiat, si une file d'attente correspondante a des consommateurs prêts, l'un d'eux verra le message acheminé vers lui. Si le client chanceux tombe en panne avant d'acquitter la réception, le message sera remis en file d'attente et/ou remis aux autres consommateurs de cette file d'attente (s'il n'y a pas de plantage, le message est accusé et tout est fait comme d'habitude). Si, cependant, une file d'attente correspondante n'a aucun consommateur prêt, le message ne sera pas mis en file d'attente pour une nouvelle livraison ultérieure à partir de cette file d'attente. Ce n'est que si toutes les files d'attente correspondantes n'ont pas de consommateurs prêts que le message est renvoyé à l'expéditeur (via basic.return).
Ou selon mes mots, "S'il y a au moins un consommateur connecté à ma file d'attente qui peut prendre livraison d'un message dès maintenant, remettez-lui ce message immédiatement. S'il n'y a aucun consommateur connecté alors ça ne sert à rien d'avoir mon message consommé plus tard et ils ne le verront jamais. Ils répètent, ils perdent. "
http://www.rabbitmq.com/blog/2012/11/19/breaking-things-with-rabbitmq-3-0/
Suppression du drapeau "immédiat"
Qu'est-ce qui a changé? Nous avons supprimé le support de l'indicateur "immédiat" rarement utilisé sur le fichier basic.publish d'AMQP.
Pourquoi diable avez-vous fait cela? La prise en charge de "immédiat" a rendu de nombreuses parties de la base de code plus complexes, en particulier autour des files d'attente en miroir. Cela nous empêchait également de fournir des améliorations de performances substantielles dans les files d'attente en miroir.
Que dois-je faire? Si vous voulez simplement pouvoir publier des messages qui seront supprimés s'ils ne sont pas consommés immédiatement, vous pouvez publier sur une file d'attente avec un TTL de 0.
Si vous avez également besoin que votre éditeur puisse déterminer que cela s'est produit, vous pouvez également utiliser la fonction DLX pour acheminer ces messages vers une autre file d'attente, à partir de laquelle l'éditeur peut les consommer.
Juste copié l'annonce ici pour une référence rapide.