Monday, January 3, 2011

RabbitMQ

Was going through some details of the RabbitMQ. Here are my notes based on the understanding I have got. Feel free to add your comments.

  • RabbitMQ is good in terms of Performance based on the reading that has been done from different blogs etc.
  • In general it has following main components
    • Broker : The RabbitMQ instance Running under ErLang node is called Broker. It contains all the Exchanges, Queues and Bindings.
    • Queue : Queue is the Endpoint where Consumer of the Message connects to the Broker. Broker fills the Queue based on the Exchange to which Queue is connected and Routing Rules (Bindings) defined.
    • Exchange : Its the one whom Publishers connects to while sending the Message out. Exchanges are attached with Queue using Bindings. Exchanges decouples the Queues and Producers so that single message can be routed to multiple places based on the Binding/Routing rules. There are muliplr types of Exchanges available :
      • Fanout : Message sent to Exchange will be sent to all the queues connected to the Exchange. Its kind of Broadcasting. Its like havong no routing key or "#" as routing key.
      • Direct : Message sent to Exchange will go to only that queue which has Exact Routing Key as Biding Key.
      • Topic : Message sent to Exchange will go to only those Queue which matches Routing Key and Binding key in a Regular expression form.
    • Binding Key : It defines which message will be put in which queue when it arrives to Exchange. Its defined at the Server end.
    • Routing Key : It defines the message destination queue routing which is patten matched or compared as it is based on the Exchange type.
  • It supports In-memory and Persistent Message Queues. 
    • Non-Durable : Its default behavior. Upon Broker crash/restart nothing will be recovered. All Exchange. Queues, Bindings info will be lost.
    • Durable : Exchange, Queues, Bindings meta-data is stored so that post crash/restart, it will be recreated. But data will be lost.
    • Persistent : If Broker node crashes, all Exchange, Queues, Bindings and data in the queue are recovered upon the Broker restart.
  • RabbitMQ supports Clustering.
  • But clustering concept is not allowing Data federation. It just does he federation/replication of Meta-Data of Exchanges, Queues and Bindings. Queue data is always Local to the Node only. i.e. Data will never get replicated across the Cluster nodes to have High Availability. Strangely, but, in-short we can say RabbitMQ focuses on on the Scalability rather than Availability. Following are some links which highlights this points:
                    http://www.rabbitmq.com/faq.html#does-clustering-replicate-messages-to-both-servers
                    http://www.rabbitmq.com/faq.html#replication-scope
                    http://dev.rabbitmq.com/irclog/index.php?date=2008-08-27 : Read it around "[16:39] can someone explain the current limitations of the high avaliabilty and performance clustering using erlang's OTP? I have read a powerpoint that says what is above?"
                   http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-July/004234.html

    1 comment:

    Derek Pappas said...

    Great research. We are thinking about using a front end persistent transaction queue for RabbitMQ. The transaction queue can be backed up on another machine and replayed to regenerate the RabbitMQ state after a crash.