I'm working in designing a solution for messaging where there are at least two servers consuming messages from the same queue, but it should work for N servers.
The workflow for the simplest solution I've been working is the following:
Server A: Process message -> Publish to exchange
Server B: Consume message -> Process message -> Publish response to return exchange
Server A: Consume message -> Process message and finish
But what I'm trying to do is doing the same but with two "servers A". Problem is, I need to make this to work in synchronous mode, so that the servers doesn't keep listening forever, but on demand.
It would be something like this:
Server A's Load balancer: "I'll send this message to server A1 or A2"
Server A1: Read request -> Process message -> Publish to exchange
Server A2: It's not doing anything because there are no requests.
Server B: Consume message -> Process message -> Publish response to return exchange
Server A1: Consume message -> Process message and finish
Server A2: Hasn't done anything because there were no requests.
If a message goes from Server A1, it must return to that server, but i'm having trouble because RabbitMQ doesn't know where to send the response because of the consumer's non-exclusive mode. Also, I think I saw that keeping the connection alive makes the RabbitMQ server balance between the opened connections, so if I had 5 servers A, it would only success in a 20% chance, the other 80% would be lost messages.
I found a solution which is: publish to single queue, consume from different queues (A1->Q1, A2->Q2...) but I'm not sure if that's the right way to do it.
Maybe there is an alternative option that I'm not aware, but I must use RabbitMQ.
This sounds like a sort of RPC work. Each server "A" can create a temporary-private queue and specify it as the "reply-to" property of the message. When server "B" reply, it will reply directly publishing the message in the "reply-to" queue, private of the "A" server that originally delivered the request.
This is well depicted here.