3

I'm using RabbitMQ in my application for communication between the Clients and the Server.

Most of the time, clients sends information to the server. But sometimes the clients need to know about some updates in the server.

Currently I'm using polling in a 1 min interval to ask the server if there are some updates.

My question is, will it be better to use Publish/Subscribe mechanism to "push" updates to the clients?

I have large numbers of clients (around 10000). So will it be OK to open 10000 queues, one for each client?

Keet Sugathadasa
  • 11,595
  • 6
  • 65
  • 80
Amir Rossert
  • 1,003
  • 2
  • 13
  • 33

2 Answers2

6

'Better' is a relative term so what works better for you is difficult to say. However, queues are designed to handle this kind of event driven system efficiently and at scale. The RabbitMQ documentation talks about using a fanout exchange to handle your case.

Using events over queues has the benefit of removing unnecessary work (e.g. polling when there is no payload), and reducing latency (your current system introduces a delay of up to a minute). Latency can be particularly problematic in systems with layers of polling which can inflate the delay of data well beyond what the programmer originally intended.

Alex Taylor
  • 8,343
  • 4
  • 25
  • 40
  • So the RabbitMQ can handle such large scale of queues? I have forgotten to mention that I use a 4 server cluster in the Rabbit. – Amir Rossert Sep 27 '15 at 05:06
  • I believe RabbitMQ will be able to handle the kind of workload you're talking about. Properly configured queues can handle 10,000 messages per _second_ without breaking a sweat. I can't speak for your particular set-up though... – Alex Taylor Sep 27 '15 at 07:02
1

From RabbitMQ documentation:

Consumers Storing messages in queues is useless unless applications can consume them. In the AMQP 0-9-1 Model, there are two ways for applications to do this:

Subscribe to have messages delivered to them ("push API"): this is the recommended option Polling ("pull API"): this way is highly inefficient and should be avoided in most cases With the "push API", applications have to indicate interest in consuming messages from a particular queue. When they do so, we say that they register a consumer or, simply put, subscribe to a queue. It is possible to have more than one consumer per queue or to register an exclusive consumer (excludes all other consumers from the queue while it is consuming).

Each consumer (subscription) has an identifier called a consumer tag. It can be used to unsubscribe from messages. Consumer tags are just strings.

Andrija Novakovic
  • 113
  • 5