RabbitMQ - Message de commande de la livraison

J'ai besoin de choisir une nouvelle File d'attente de courtier pour mon nouveau projet.

Cette fois, j'ai besoin d'une solution évolutive de la file d'attente qui prend en charge la pub/sub, et de garder le message de commande est un must.

J'ai lu Alexis commentaire: Il écrit:

"En effet, nous pensons RabbitMQ assure une commande que Kafka"

J'ai lu le message de commande de la section de rabbitmq docs:

"Messages peuvent être retournés à la file d'attente à l'aide de AMQP méthodes que la fonction
un requeue
paramètre (de base.récupérer, de base.rejeter et de base.nack), ou en raison d'un canal
fermeture tout en maintenant des messages non reconnus...Avec la version 2.7.0 et plus tard
il est encore possible pour les consommateurs d'observer les messages de
commande si la file d'attente a plusieurs abonnés. Cela est dû à l'action de l'
d'autres abonnés qui peut requeue messages. Du point de vue de la file d'attente
les messages sont toujours détenus dans la publication de l'ordre."

Si j'ai besoin de gérer les messages selon leur ordre, je ne peux utiliser rabbitMQ avec une exclusivité de la file d'attente à chaque consommateur?

RabbitMQ est toujours considéré comme une bonne solution pour commandé message queuing?

InformationsquelleAutor Bick | 2014-01-26
  1. 112

    Eh bien, nous allons regarder de plus près le scénario que vous décrivez ci-dessus. Je pense qu'il est important de coller la documentation immédiatement avant l'extrait de code dans votre question, pour fournir le contexte:

    L'article 4.7 de l'AMQP 0-9-1 de base spécification de explique le
    conditions de commande est garanti: les messages publiés dans
    un canal, en passant par un échange et une file d'attente et un
    canal de sortie seront reçus dans le même ordre qu'ils ont été
    envoyés. RabbitMQ offre plus de garanties depuis la version 2.7.0.

    Messages peuvent être retournés à la file d'attente à l'aide de AMQP méthodes que la fonction
    un requeue paramètre (de base.récupérer, de base.rejeter et de base.nack), ou
    en raison d'une fermeture d'un canal tout en maintenant des messages non reconnus. Tout d'
    ces scénarios causé des messages requeued à l'arrière de la
    file d'attente pour RabbitMQ des versions antérieures à 2.7.0. De RabbitMQ libération
    2.7.0, les messages sont toujours détenus dans la file d'attente de la publication de l'ordre, , même en présence de requeueing ou canal de fermeture. (emphase ajoutée)

    Alors, il est clair que RabbitMQ, de 2.7.0-là, fait une plutôt drastiques amélioration par rapport à l'original AMQP spécification concernant le message de la commande.

    Avec de multiples (parallèle) des consommateurs, de l'ordre de traitement ne peut pas être garanti.

    Le troisième alinéa (a collé dans la question) va donner un avertissement, que je paraphrase: "si vous avez plusieurs processeurs dans la file d'attente, il n'est plus une garantie que les messages seront traitées dans l'ordre." Ils sont tous en train de dire est que RabbitMQ ne peut pas défier les lois de la mathématique.

    Envisager une ligne de clients d'une banque. Cette banque, qui s'enorgueillit d'aider les clients dans l'ordre, ils sont entrés dans la banque. Les clients dans une file d'attente, et sont servis par la prochaine de 3 disponible scrutateurs.

    Ce matin, il arriva donc que tous les trois scrutateurs est disponible dans le même temps, et les 3 prochains clients approché. Soudain, le premier des trois scrutateurs est devenu brutalement malade, et ne pouvait pas fini de servir le premier client de la ligne. Par le temps, ce qui s'est passé, caissier 2 en avait fini avec le client 2 et 3 guichets avait déjà commencé à servir la clientèle 3.

    Maintenant, de deux choses peuvent se produire. (1) Le premier client en ligne permet de revenir à la tête de la ligne ou (2) le premier client de devancer le troisième client, à l'origine de ce comptoir d'arrêter de travailler sur le troisième client et de commencer à travailler sur le premier. Ce type de préemption de la logique n'est pas pris en charge par RabbitMQ, ni aucun autre message broker que je suis au courant. Dans les deux cas, le premier client ne prend pas vraiment en fin de compte contribué à la première de la deuxième client ne, être assez chanceux pour obtenir un bon, rapide guichets au large de la chauve-souris. La seule façon de garantir à ses clients sont aidés dans le but est d'avoir un guichet d'aider les clients un à un, ce qui va entraîner d'importants problèmes de service client pour la banque.

    J'espère que cela aide à illustrer le problème que vous posez sur. Il n'est pas possible de s'assurer que les messages sont traités dans l'ordre dans tous les cas de figure, étant donné que vous disposez de plusieurs consommateurs. Il n'a pas d'importance si vous disposez de plusieurs files d'attente, plusieurs exclusive des consommateurs, des différents courtiers, etc. - il n'existe aucun moyen de garantir a priori que les messages sont traitées dans l'ordre avec plusieurs consommateurs. Mais RabbitMQ sera un best-effort.

    • Est-il un moyen de configurer le lapin à requeue les messages à la fin de la file d'attente au lieu de l'avant?
    • Probablement, mais ce que vous essayez d'atteindre et quelle est l'importance de cette?
    • Très explication claire
    • Merci pour souligner les différences entre RabbitMQ < 2.7.0 et >= 2.7.0, qui a sauvé ma journée 🙂
    • un plaisir de vous aider 🙂 et merci pour le modifier.
    • Non, vous ne le peut pas. Mais il y a une solution: vous pouvez cloner le message et publier dans la même file d'attente, comme un complètement nouveau message, puis il ira à la fin de la file d'attente. Dans ce cas, l'attribut redelivered du message sera false au lieu de true comme un normal requeue.
    • Kafka permet la parallélisation d'une application définie au niveau de l'ordre partiel par la voie de partitions, ce qui est très pratique pour les tâches réelles. RabbitMQ semble offrir ordre mondial sans parallélisation, ou pas de commander à tous. Dont les garanties sont les meilleures? )
    • Je ne suis pas sûr de ce que l'on entend par "application définie au niveau de l'ordre partiel." Cela semble être un certain type de partition inférieur au niveau de la file d'attente, ce qui ne serait pas vraiment le sens de faire en Lapin depuis une file d'attente peut être défini pour tenir quelle que soit la combinaison de messages de sens. Sauf si je suis de l'incompréhension de ce que vous entendez par là.
    • Désolé pour revenir à un 4 ans répondre. Alors que l'ordre des messages à travers un canal, un échange, une file d'attente et un canal peut être préservé, les choses peuvent mal se passer sur le client. Par exemple, le C# de la bibliothèque du client engendre un thread par le message reçu. Avec mon méchant esprit, je le dis, alors, comment fait-OS de planification puis interférer avec l'ordre de traitement des messages reçus? Sûrement, il ya en effet une condition de concurrence entre les deux threads de traitement de deux étroitement chronométré messages? Le client lib n'auront pas à attendre pour le premier thread terminer avant le frai de l'autre. Fait de débogage dur. Des indices?
    • Poser une nouvelle question et je vais vous donner un coup de couteau à elle 🙂
    • merci pour l'offre! En fait, j'ai éteint et lire le manuel un peu plus, et se rendit compte que tous les exemples de code que j'ai vu mettre en œuvre IBasicConsumer (les rappels qui sont en effet appelé en même temps, d'où le fils; je n'arrive pas à croire le manuel à propos de l'ordre de traitement; les tâches peuvent se lance dans l'ordre, mais ensuite il est descendu à l'OS scheduler). Ressemble à du "pull" API channel.BasicGet() est mieux comme ça. Maintenant tout que j'ai besoin de trouver l'équivalent de select()...
    • Il est possible qu'ils ré-écrit le client de la mise en œuvre. Celui que j'ai utilisé il y a des années a été horrible, et j'ai programmé moi-même (pas d'assez bonne qualité pour les remettre). Il ne me surprendrait pas si c'est ce qu'ils ont fait parce que j'ai fait la même chose moi-même. La messagerie n'est pas conçu pour la série de traitement, clair et simple - il ne faut pas compter sur elle lors de la conception de votre application.
    • l'autre chose que vous pourriez faire est de mettre en auto-ack pour de faux, ou de pré-extraction à 1. Qui va s'assurer de série de la livraison, mais encore une fois, ce n'est pas une bonne idée de conception de la série d'exigences à l'aide d'une plate-forme parallèle de la structure.
    • Il dépend; certaines des utilisations j'ai vu d'autres devs utilisation RabbitMQ sont tout simplement comme un socket tcp remplacement n'y a aucune indication du parallèle de messagerie architectures. Les autres fonctionnalités qui RabbitMQ offre (telles que la durabilité, etc) sont intéressants par eux-mêmes! Utilisé comme ça (donc pas d'exercer les modèles de messagerie, ce qui est presque une parodie), il est utile d'avoir l'ordre des messages conservés.
    • et merci pour les conseils sur l'auto-ack et de pré-extraction.
    • Je suis d'accord avec cela. Au moins vous avez une solide justification.

    InformationsquelleAutor theMayer
  2. 7

    Message de commande est conservé dans Kafka, mais seulement à l'intérieur de partitions plutôt que globalement. Si vos données ont besoin à la fois global de la commande et de partitions, cela rend les choses difficiles. Toutefois, si vous avez juste besoin de s'assurer que tous les événements pour le même utilisateur, etc... se retrouvent dans la même partition, de sorte qu'ils sont bien ordonné, vous pouvez le faire. Le producteur est responsable de la partition qu'ils écrivent, donc si vous êtes en mesure d'logiquement partition de vos données c'est peut-être préférable.

    InformationsquelleAutor tyler neely
  3. 3

    Je pense qu'il y a deux choses dans cette question, qui ne sont pas similaires, la consommation de l'ordre et de l'ordre de traitement.

    Files d'attente de messages peut, dans une certaine mesure de vous donner une garantie que les messages vont être consommés dans l'ordre, ils ne peuvent pas, cependant, de vous donner aucune garantie sur l'ordre de leur traitement.

    La principale différence ici est qu'il y a certains aspects du traitement des messages qui ne peuvent être déterminés au moment de la consommation du temps, par exemple:

    • Comme mentionné, le consommateur peut échouer lors de la transformation, ici le message de la consommation de l'ordre est correct, cependant, le consommateur n'a pas pu traiter correctement, ce qui va la faire revenir à la file d'attente, et jusqu'à présent, la consommation de commande est toujours intacte, mais nous ne savons pas comment l'ordre de traitement est maintenant

    • Si par "traitement", on entend que le message est maintenant jeté et fini complètement le traitement, puis de considérer le cas où votre temps de traitement n'est pas linéaire, en d'autres termes de traitement d'un message est plus longue que l'autre, donc si le message 3 prend plus de temps dans le traitement que prévu, les messages de 4 et 5 peut être utilisée et la fin du traitement avant de message 3 ne

    Donc, même si vous avez réussi à obtenir le message d'arrière vers l'avant de la file d'attente (qui, par la manière viole la consommation de commande) vous toujours ne peut pas garantir que tous les messages avant le prochain message avez terminé le traitement.

    Si vous voulez vous assurer que l'ordre de traitement alors:

    1. Ont seulement 1 consommateur instance à tout moment
    2. Ou n'utilisez pas de file d'attente de messagerie et de faire le traitement en mode synchrone bloquant méthode, qui peut sembler mauvais, mais dans de nombreux cas, et les exigences de l'entreprise est tout à fait valable, et parfois même critique
    • C'est l'information exacte, mais il n'y a pas de signification pratique de la consommation de "l'ordre". Message traitement est ce que les résultats dans un changement d'état dans le système. Comme les messages peuvent être re-file d'attente après la "consommation", mais ostensiblement avant de "traitement", tout cela est temporaire, l'état du processeur avant c'est fait -, qui nous l'espérons vous ne se soucient pas.
    • Je voudrais également ajouter que si vous allez à l'option de l'un et de vous à recevoir des événements de MRQ en mode passif et que vous utilisez une boucle comme dans NodeJS vous avez besoin d'utiliser un seul canal avec une récupération de 1 parce que sinon vous pouvez vous retrouver avec de multiples messages en parallèle qui peuvent être traitées à des vitesses différentes.
    InformationsquelleAutor engma
  4. 1

    Il y a des manières appropriées de guarantuee l'ordre des messages au sein de RabbitMQ abonnements.

    Si vous utilisez plusieurs consommateurs, ils vont traiter le message à l'aide d'un partagées ExecutorService. Voir aussi ConnectionFactory.setSharedExecutor(...). Vous pouvez définir un Executors.newSingleThreadExecutor().

    Si vous utilisez un Consumer avec une seule file d'attente, vous pouvez lier cette file d'attente à l'aide de plusieurs bindingKeys (ils peuvent avoir des jokers). Les messages sont placés dans la file d'attente dans le même ordre qu'ils ont été reçus par le courtier de message.

    Par exemple, vous avez un seul éditeur qui publie les messages où l'ordre est important:

    try (Connection connection2 = factory.newConnection();
        Channel channel2 = connection.createChannel()) {
    //publish messages alternating to two different topics
    for (int i = 0; i < messageCount; i++) {
        final String routingKey = i % 2 == 0 ? routingEven : routingOdd;
        channel2.basicPublish(exchange, routingKey, null, ("Hello" + i).getBytes(UTF_8));
    }
}

    Maintenant, vous pourriez recevoir des messages à partir de deux sujets dans un file d'attente dans le même ordre qu'ils ont été publiés:

    //declare a queue for the consumer
final String queueName = channel.queueDeclare().getQueue();

//we bind to queue with the two different routingKeys
final String routingEven = "even";
final String routingOdd = "odd";
channel.queueBind(queueName, exchange, routingEven);
channel.queueBind(queueName, exchange, routingOdd);
channel.basicConsume(queueName, true, new DefaultConsumer(channel) { ... });

    La Consumer va maintenant recevoir les messages dans l'ordre qu'ils ont été publiés, indépendamment du fait que vous avez utilisé différents sujets.

    Il y a quelques bons à 5 Minutes de Tutoriels dans le RabbitMQ documents qui pourraient vous être utiles:
    https://www.rabbitmq.com/tutorials/tutorial-five-java.html

    InformationsquelleAutor benez