[rabbitmq-discuss] Architecture Question: 2 Brokers, or Not 2 Brokers ?
developer at dnsplus.net
Mon Jan 23 22:57:44 GMT 2012
> Hi dns, I'll try to bring my own experience on the subject. When you
> federate exchanges between brokers you are in the loose sense having the
> downstream exchange acting as a consumer for the upstream exchange. I may
> have misunderstood you but I think that having 8000 brokers rather 8000
> remote consumers on the central broker doesn't solve the consistency
> problem you are describing.
> Let's make an example with federated brokers on the happy path:
> 1. One message is published on the upstream exchange and reaches the
> downstream exchange, and in turn the queue and then the consumer on the
> downstream broker
> 2. The downstream broker confirms the message to the upstream broker so
> the upstream broker can forget about it
> 3. The connection between the brokers goes down
> 4. The consumer on the downstream broker processes the message,
> acknowledges it and everyone's happy
> Here's the sad path with federated brokers:
> 1. same as above
> 2. The connection between the brokers is lost before the downstream can
> confirm the message to the upstream (unlikely, but can definitely
> 3. The consumer on the downstream broker processes the message and
> acknowledges it to its local broker
> 4. The connection between the two brokers is restored, and thus the
> upstream will resend the unconfirmed messages once again
> 5. The consumer on the downstream will receive the same message it has
> already consumed, therefore it will need a way to deduplicate it
> Now the safe path with just the central broker:
> 1. One message is published on the central broker and reaches a remote
> 2. The consumer processes the message but the connection to the central
> broker will go down before it can ack the message
> 3. Once the connection is restored the consumer will receive the
> message again, so also in this case it will need to deduplicate it
> Some observations:
> - in any case your consumer will need to be somewhat aware of the fact
> that it is quite distant from the original broker and cope with what
> implies in some way (message duplication, for one)
> - with the central broker the remote consumers will have to handle
> connection failures themselves, something which is less likely to
> with a local broker, although not impossible of course. This is handled
> the federation plugin in case of federated brokers instead
> - Having 8000 brokers rather than 8000 consumers is going to require
> quite some maintenance, and I'm not sure how well the federation plugin
> RabbitMQ can handle that, I am under the impression that it was not
> designed for this many federated exchanges, but I may be wrong
> - You mention synchronicity between the central location and the remote
> consumers. Consider that even if you federate brokers and you see all
> messages delivered and acked on the federation queues, it doesn't tell
> anything about whether the remote consumers have processed the messages
Thank you for all this. If I were inclined to use central and remote
exchanges/brokers, then SHOVEL is the missing piece I have been looking for.
However ... oh, the overhead with maintaining it all !
I suppose I am inclined to go with a Central Broker and have remote
consumers, and was wondering if someone might convince me otherwise.
However, this has not yet happened.
Seeing as how my application is more of a "task distribution and management
system" where all sites are processing the same tasks (with RabbitMQ making
sure that the tasks are received), it has occurred to me that I might want a
database component at the central data center as well. I am working on a
conceptual workflow to flush this idea out.
I keep coming back around to keeping as much intelligence as possible at
Central, and keeping the consumer side as lean as I can.
View this message in context: http://old.nabble.com/Architecture-Question%3A-2-Brokers%2C-or-Not-2-Brokers---tp33189279p33191832.html
Sent from the RabbitMQ mailing list archive at Nabble.com.
More information about the rabbitmq-discuss