[rabbitmq-discuss] Topic routing
0x6e6562 at gmail.com
Wed Oct 22 01:54:44 BST 2008
On Wed, Oct 22, 2008 at 1:35 AM, Brian Sullivan <bsullivan at lindenlab.com> wrote:
> Just to clarify what you mean by "not affect the run time complexity of
> routing"... Are you saying that each node in a cluster has to manage the
> total load of ALL messages that hit the cluster, regardless of whether the
> producer is sending to that node or not? I was under the impression that
> the shared routing table that is synchronized across the cluster would be
> leveraged by each node to know where it might need to forward messages (only
> to those nodes managing queues that have relevant subscriptions).
No, a single node only has to route the messages sent directly to it.
The queues to which that node has to route messages to may or may not
exist on the same node.
> For example, if I had a cluster with nodes A, B, C -
> When I have [only] a client A1 publishing a busy topic stream to node A and
> a client B1 subscribing to that topic on node B... Does C see any load at
Only if C has a queue that matches a routing key for a message sent to
A or B, but even if that is the case, a queue process on C receives a
already-routed message in it's inbox - and this is optimized across
nodes so that only one intra-node TX is made per message, even if
there are multiple matches on the remote node.
>> Clustering will not affect the run time complexity of routing, since
>> the routing table has to be coherent across the cluster.
>> In a clustered scenario, the queues may reside on different nodes,
>> whereas exchanges will *exist* on every node.
What I meant to say that the parallelism does not change the
fundamental complexity of the routing algorithm - sure it will
distribute load, but O(n) is still O(n) even in a clustered context.
So when you up the ante to the nth degree, you will find that this
methodology *may* not cut it (although you are actually scaling
The question remains - do you think that you will realistically take
it to the nth degree.
More information about the rabbitmq-discuss