2017-02-04 1 views
2

Je crée un service (accessible via le web et l'application) où les utilisateurs appartiennent à une équipe. Chaque fois qu'un utilisateur fait quelque chose, tous les autres utilisateurs en ligne (*) de son équipe doivent être notifiés. J'évalue RabbitMQ pour cela.RabbitMQ - comment éviter de recevoir ses propres messages

(*) Notez qu'il est possible que le même utilisateur ait plusieurs sessions en même temps: il peut être connecté simultanément dans différents navigateurs, ou plus probablement dans le navigateur et l'application en même temps .

Mon approche actuelle est de créer un échange thématique pour chaque équipe:

  • Lorsqu'un utilisateur se connecte, une file d'attente automatique de suppression est créé et lié à l'échange de sa/son équipe.
  • Lorsqu'un utilisateur faisait une mise à jour, le backend envoie un message à l'échange de l'équipe correspondante.
  • Enfin, toutes les files d'attente actives, c'est-à-dire toutes les sessions actives, reçoivent le message de mise à jour.

C'est génial, car le message de mise à jour ne doit être envoyé qu'une seule fois par le backend. Cependant, le problème ici est que l'initiateur reçoit également sa propre mise à jour. Je voudrais éviter cela. Est-ce possible? Ou devrais-je avoir un autre design? Bien sûr, je peux toujours ajouter l'identificateur d'utilisateur de l'initiateur dans la charge utile du message de mise à jour et filtrer sur ce champ lors de la réception d'un message de mise à jour, mais le message est toujours reçu.

Répondre

1

C'est une question intéressante. Après avoir réfléchi à ce sujet pendant un certain temps avec ce design particulier, quand l'utilisateur veut obtenir la mise à jour et aussi faire quelques changements alors que d'autres devraient le savoir, je pense que vous devez penser à un autre design. Avec Topic comme un échange, vous recevrez toujours la notification que la file d'attente est créée lorsque vous vous êtes connecté au système. Et Topic va le diffuser.

Le sujet est plus pour un genre d'abonnement où vous ne pouvez pas spécifier facilement où vous voulez passer un abonnement ou non.

Une conception que je peux penser à ce qui est peu compliqué est la suivante:

  1. Créer un sujet d'échange par personne dans l'équipe.
  2. Lorsqu'un autre utilisateur se connecte, il s'abonne à l'échange de tous les autres membres de l'équipe.
  3. Lorsqu'un utilisateur fait une mise à jour, il est envoyé à son propre Exchange où tous les autres écoutent.
  4. De cette façon, l'utilisateur ne recevra pas sa propre mise à jour car il écoute d'autres sujets.
+0

Approche intelligente! –