RabbitMQ - Topic Exchange - Same topics two or more consumers

5
votes

I'm nmew to AMQP and trying to work out a notification architecture for a RabbitMQ system.

I want a Topic exchange (NotificationsExchange, let's say), specifically because I want to flexibility with routing keys and queues that comes with the topic exchange as well as more options for future expansion on the topic. I might be wrong though, because...

I also want to have each notification consumed by two or more consumers. As a baseline, I want each notification published to wind up in a database. Additionally, I want each notification to be eligible for consumption by a client application (e.g., web app to consume and further push through sockets for immediate user notification without db polling).

This really sounds like a fanout exhange situation, except I didn't want to do that because I'd need a whole lot more queues to handle the various notifications (I think - still new to AMQP and trying to wrap my head around it).

Is it possible to have two consumers get notified (consistently) from the same queue?

For example:

  • Push Notif.NotifGroup.User.ThisUser through the NotificationExchange
  • Have dbListener bind to Notif.#
  • Have mvcClientListener also bind to Notif.# (and further determine if the user is online and push downstream via socket)

I'm not sure if I'm on the right track here. I'm reading that "multiple consumers to the same queue are load balanced in a round robin fashion", and quite frankly, I don't know what that means.

Is it possible to have a Topic Exchange where two consumers can consistently read the same messages from the same queue (e.g., same routing key), or must I go with a Fanout Exchange for this?

Thanks.

1
rabbitmq

1 Answers

9
votes

Is it possible to have two consumers get notified (consistently) from the same queue?

yes, but this is not what you want.

when you have multiple consumers on one queue, the consumers are round-robin load balanced. if consumer 1 receives message a, consumer 2 cannot receive it

instead, what you want to do is add additional route handlers for each consumer, and have each consumer create it's own queue.

for example NotificationEx may have a binding for Notif.# which pushes to dbQueue. The same exchange would have a binding for Notif.# which pushes messages to mvcQueue.

Your database consumer would consume from dbQueue and your web app would consume from mvcQueue.

This makes it very easy to add new consumers, each with their own queue and binding to the exchange.

FWIW, there is not "right" or "wrong" exchange type for any given situation. You can make any exchange type work for any situation. However, some exchange types make it easier to deal with certain situations.

You might want to check out my ebooks on RabbitMQ for more information about exchange types, their generally accepted "best use cases", and how they can be applied in rather interesting scenarios: https://leanpub.com/b/rmq-layout-and-patterns