How to implement single-consumer-multi-queue model for rabbitMQ

Question

I have found this image is very similar to my bussiness model. I need to split

Answer 1

1. You can add multiple workers to a queue
2. There can be multiple queues bound to an exchange.

In RabbitMQ, the producer always sends the message to an exchange. So, in your case, I hope only one exchange is enough. If you want to load balance at the consumer side, you have the above said two options.

You can also read my article: https://techietweak.wordpress.com/2015/08/14/rabbitmq-a-cloud-based-message-oriented-middleware/

Answer 2

RabbitMQ has a very flexible model, which enables a wide variety of routing scenarios to take place.

1. I need to split message to some queue. for some heavy work. I can add more worker thread for them.

Yes, this is supported via a direct exchange. Publish a message using a routing key that is the same as the name of the queue. For convenience, let's say you use the fully-qualified object name (e.g. MyApp.Objects.DataTypeOne). All you need to do is subscribe multiple consuming processes to this queue, and RabbitMQ will load-balance using a round-robin approach.

2. But for some no much heavy work. I can let single consumer to subscribe their message.

Yes, you can do this also. Same process as in the paragraph above. Just don't attach multiple consuming processes.

I have found this image is very similar to my business model.

The diagram isn't very useful, because it lacks information about the type of messages being published. In that sense, it is only an interconnect diagram. The interesting lines are the ones connecting the queues to the exchange, as that is what you specify within RabbitMQ via Queue Bindings. You can also bind exchanges to one another, but that's a bit further than we probably need to go.

Everything else on the diagram is fully under your control as the user of the RabbitMQ/AMQP system. You can create an arbitrary number of publishers and have an arbitrary number of consuming processes each consuming from an arbitrary number of queues. There are no hard and fast limits, though there are some practical aspects you probably will want to think about to ensure your system is maintainable.