[rabbitmq-discuss] about the clustering of rabbitmq

Jason J. W. Williams jasonjwwilliams at gmail.com
Thu Aug 6 20:10:43 BST 2009


Hi Femto,

That is correct...if using load balancers. As noted in my last e-mail,
one of our goals in implementing messaging queueing is to reduce or
eliminate our SLB count.

-J

On Wed, Aug 5, 2009 at 7:21 PM, femto Zheng<femtowin at gmail.com> wrote:
> No,if using load balancers, the client just needs to know
> the load-balancer server, the load-balancer server will know new
> server if new server adds into the cluster.
>
> On Thu, Aug 6, 2009 at 1:25 AM, Jason J. W.
> Williams<jasonjwwilliams at gmail.com> wrote:
>>> It's also worth pointing out here that connection.redirect is a bit of a
>>> crude, blunt weapon, and in fact has been *removed* for AMQP 0-9-1. When
>>> we transition to 0-9-1, it will no longer be available: it will be up to
>>> clients to know how to connect to the broker. This seems like a
>>> limitation, but I personally view it as an improvement: it means that
>>> AMQP concentrates on *messaging*, and leaves load balancing up to load
>>> balancers -- as it should :-)
>>
>>
>> From my point of view that's definitely less than desirable. The
>> clustered broker has the best point-of-view as to how many clients it
>> has connected and how much work it's doing. We're still
>> re-architecting our processing facilities around RMQ for the explicit
>> purpose of getting rid of the mess of load balancers we currently use.
>> What we've written so far is architected around the idea that a
>> primary and backup server are hard-coded into the config for the
>> client for initial connect and then the broker handles redirecting the
>> client to the least loaded node, which may not in the config file.
>> Otherwise, every time you add a Rabbit node you've got to populate
>> that info amongst your client config files, which means more moving
>> parts. Just my two cents.
>>
>> -J
>>
>




More information about the rabbitmq-discuss mailing list