Exemple de didacticiel d'installation de RabbitMQ (windows)

Arrière-plan de gestion

rabbitmq est livré avec son propre arrière-plan de gestion, qui doit être configuré et activé après l'installation
Entrez le répertoire sbin dans le répertoire d'installation de Rabbitmq et exécutez
rabbitmq -plugins activer Rabbitmq_management
Redémarrer Rabbitmq Le service prend effet
Ouvrez http://localhost:15672/ et vous pouvez voir l'arrière-plan de gestion
Le nom d'utilisateur et le mot de passe sont invités

Instructions de configuration

Utilisez la ligne de commande pour afficher la liste de files d'attente

sbin>rabbitmqctl list_queues  
sbin>rabbitmqctl list_queues name messages_ready messages_unacknowledged

Utilisez la ligne de commande pour afficher la liste d'échange

sbin>rabbitmqctl list_exchanges

Définir la file d'attente

RabbitMQ ne permet pas de la redéfinir avec différents paramètres. Une file d'attente existante.

RabbitMQ ne vous permet pas de redéfinir une file d'attente existante avec des paramètres différents et renverra une erreur à tout programme qui tente de le faire

Fiabilité

Pour garantir que les messages ne sont pas perdus, la persistance des messages doit être définie et la file d'attente doit également être durable.
Mais ce n'est toujours pas fiable à 100 %, car si RabbitMQ plante après avoir reçu le message mais avant d'avoir terminé la persistance, le message sera perdu.

Traitement répété

Considérez le scénario suivant (prémisse : les files d'attente et les messages sont durables) :

1. Le consommateur reçoit un message msgA, à moitié traité, non terminé, aucune confirmation d'accusé de réception n'a été lancée

2. À ce moment-là, RabbitMQ s'est écrasé

3. Le consommateur a terminé le traitement du message msgA ;

4. Lorsque RabbitMQ redémarre, il s'avère que msgA n'a pas été traité, donc msgA est à nouveau envoyé au consommateur.

Dans ce scénario, le message msgA sera traité deux fois, le côté consommateur doit donc disposer d'un mécanisme pour empêcher un traitement répété.

ACK

La confirmation ACK indique uniquement à RabbitMQ que le consommateur a terminé le traitement du message, et non que le traitement logique est réussi. Même si le traitement commercial échoue, la confirmation ACK est requise. Car d’une manière générale, si une panne survient pour des raisons professionnelles, réessayer ne résoudra pas le problème. Seules les pannes causées par des interruptions du réseau, des pannes de courant de la machine, etc. nécessitent une nouvelle tentative.

Empêcher la charge commerciale d'être concentrée sur un certain consommateur

channel.basicQos(prefetchCount);

Paramètres
prefetchCount=1
indique à RabbitMQ d'attribuer un seul message à un consommateur à la fois jusqu'à ce que le last Un message attribué à ce consommateur est accusé de réception pour traitement. De cette manière, les messages seront attribués à chaque fois aux consommateurs inactifs en fonction des conditions de traitement réelles.

À propos de l'Exchange par défaut

L'Exchange par défaut est implicitement lié à chaque file d'attente et la clé de routage est le nom de la file d'attente. Il ne peut pas être explicitement lié ou dissocié. Et il ne peut pas être supprimé.

L'échange par défaut est implicitement lié à chaque file d'attente, avec une clé de routage égale au nom de la file d'attente. Il n'est pas possible de se lier explicitement à l'échange par défaut ou de s'en dissocier. .

Le processus de base de la messagerie

L'éditeur publie un message
--> Exchange est utilisé), et selon le type d'échange et certaines règles de routage, le message est acheminé vers chaque file d'attente qui répond aux règles de routage (s'il n'y a pas de file d'attente correspondante, le message est rejeté)
-->La file d'attente envoie le message à l'abonné Un certain consommateur de la file d'attente (s'il n'y a pas de consommateur, le message reste dans la file d'attente jusqu'à ce qu'un consommateur consomme le message)

Le caractère générique de Topic Exchange

L'astérisque correspond à un mot (remarque, pas une lettre)

* (étoile) peut remplacer exactement un mot.
Le signe dièse correspond à n'importe quel nombre de mots
# (hachage) peut remplacer zéro ou plusieurs mots.

Le rôle des drapeaux obligatoires et immédiats dans le protocole AMQP

obligatoire et immédiat sont les deux drapeaux du basic.pulish méthode dans le protocole AMQP. Ils sont utilisés lorsque les messages sont livrés. La fonction de renvoyer des messages au producteur lorsque la destination ne peut pas être atteinte pendant le processus. Les différences spécifiques sont :

1. Indicateur obligatoire

Lorsque l'indicateur obligatoire est défini sur true, si l'échange ne parvient pas à trouver une file d'attente qualifiée en fonction de son propre type et de sa propre clé de route, basic sera La méthode .return renvoie le message au producteur ; lorsque la valeur obligatoire est définie sur false, le courtier supprimera directement le message dans la situation ci-dessus.

2. indicateur immédiat

Lorsque l'indicateur immédiat est défini sur true, si l'échange constate qu'il n'y a aucun consommateur dans la file d'attente correspondante lors du routage du message vers la ou les files d'attente, alors ceci le message n'est pas mis dans la file d'attente. Lorsque toutes les files d'attente (une ou plusieurs) associées au message routeKey n'ont aucun consommateur, le message sera renvoyé au producteur via la méthode basic.return.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!