RabbitMQ – part I – AMQP


Posted on August 5th, by Arnon Rotem-Gal-Oz in Blog. 2 comments

I haven’t blogged in a few months and I guess it is about time I get back to writing. A lot has happened including me leaving CloudValue (I still think it can be interesting business-wise, but it wasn’t very challenging technically) and moving to a new company (where I’ll probably won’t get rich but I get to work on challenging projects :) ). Anyway, I working with quite a few interesting technologies these days (Hadoop,  Greenplum, BigInsight and whatnot )and I thought it might be a good idea  to write about some of them. The first technology I am going to talk about is RabbitMQ.

RabbitMQ is a message bus built in Erlang. It implements the AMQP protocol, which, unlike JMS, is also a wire protocol and not just an API. (meaning you can use an AMQP client with any compliant AMQP server) AMQP has a few concepts which are different from “regular” messaging infrastructures (like MSMQ or MQSeries). The illustration below shows the main concepts of AMQP

 

 

 

 

 

 

 

 

 

 

 

 

Virtual Host – Virtual host is administrative container which  provides access control boundaries. Each virtual host has its own set of exchanges. A connection can only be associated with a single virtual host

Exchange – An exchange is a message routing agent. Exchanges can be temporary, auto-deleted or durable. Messages are published to exchanges and then routed to queues that are bound to the exchange (if no queues are bound the message will be lost).Exchanges support one of the following routing schemes

  • Direct – based on a routing key. Any queue (or exchange) binding to the key will get the message
  • Fan-out – no routing key , each queue or exchange bound to this type of exchange will get a copy of the message
  • Header -  Header based routing allows compound routing based on a combination of lists of identifiers (essentially key-value pairs) the routing can be done on either any or all key-values specified. The subscription then specified a set of key-values and an operator (and or any) e.g. { ‘x-match’ => ‘any’, :customer => ’23′, :agent => ’007′ }. This looked like a promising direction until we’ve found that it isn’t well supported (e.g. it isn’t even documented in the C# documentation of RabbitMQ) and doesn’t perform well
  • Topic – Topic based routing allows compound routing based on topic hierarchy. Topics is based on pattern matching (a strong core capability of Erlang, RabbitMQ’s implementation language) and allows versatile subscription based on wildcards: * a single segment placeholder or # zero or more segments  (e.g. foo.*.bar will match foo.baz.bar, foo.bag.bar but not foo.baz.bag.bar, foo.#.bar will match all of them)

Both queues and exchanges can bind to an exchange. The default exchange uses the queue name as routing key (i.e. sends a message directly to a queue)

Queue – A queue is a FIFO buffer. It is important to note that the FIFO order is only guaranteed when a single consumer is used. Queues, like exchanges cab be temporary, auto-deleted or durable. Getting messages from exchanges to queues is done by binding the queue to an exchange.

So that’s a short into to AMQP itself. In the next installments I’ll expand a little about RabbitMQ itself, show some coding samples and finish it up with some pros/cons


illustration by beautyredefined

Tweet about this on Twitter2Share on LinkedIn0Share on Facebook0Share on Google+0Buffer this pageShare on Reddit0Share on StumbleUpon0Email this to someone