Hello everyone, today I will talk about message brokers. In now days is really hard to choose a message broker because there are too many solutions, but every broker has you own porpoise.
For me ActiveMQ and RabbitMQ are the most popular message brokers today, they have different concepts but in practice they work in really similar way.
When you choose a message broker you have to ask yourself:
For all this questions the answer for these two is yes, but every broker has your own issues in that points
Using ActiveMQ, the Message Broker manipulation is not so customizable
When you talk about microservices and continuous delivery then you probably want that your application code can manage all external frameworks that it connects to, otherwise you will depend of that framework to do a delivery with some especific configuration for your application, for example: a new queue, a new consumer quantity, change the max retries to send a message to DLQ, etc.
In ActiveMQ somethings only can be configured in broker side, for example, by default ActiveMQ configure all queues DLQ as ActiveMQ.DLQ, then all messages that has failed to be consumed will be sent to that DLQ, you only can change that by configuring a DLQ name for you queue name at activemq.xml, that's not something cool, in RabbitMQ I didn't have this problem, the DLQ name is configurable at the application side.
I found a workaround to ActiveMQ by creating a consumer to the default ActiveMQ.DLQ recovering the original queue name from the message HEADER and posting this message again to a new queue called $originalQueueName.DLQ, that way every queue can have your own DLQ and I had not to configure something at the broker side, if you're courious about that you can see an example at my github
Grant order and avoid concurrency is not possible with RabbitMQ
Sometimes you may want to have some kind of order in your messages even when you have multiple consumers, for example:
In a stock market system many people want to buy a specific stock, let's say we have stockBuy queue with 2 consumers and you use relational database to control the buys/sells, If two messages are trying to buy same stock you database will get concurrency, then it will need to lock the stock row and the consumers will get slow while all others messages of others symbols are waiting to be processed, that's a unwanted behavior, we don't want two consumers with same stock symbol because they can't be parallelized because the lock, instead, we want two consumers always with different symbols, that way you can parallelize the buys/sells
ActiveMQ has a feature called JMSGroupId, it's a JMS v2 API specification, it allow to grant order between messages of the same group even using multiple consumers because it grant that a message with specific JMSGroupId will ever be processed by the same consumer and only by one consumer, not two, not three, using the above example you will put the stock symbol at the JMSGroupId property, then all messages of this group will be sent to the same consumer granting the order and avoiding concurrency, increasing the consumer performance, RabbitMQ haven't a feature like that and probably won't soon.
Distribution across regions is not a RabbitMQ quality
ActiveMQ officially suport distribution across regions you can configure a network of brokers with failover and have distributed topics and queues, you also may have just a master/slave network of brokers when a region will assume when the another regions get down.
Actually RabbitMQ don't have a strong support, in my actual company with some milions of messages per day, they tried to do that and got a lot of messages lost, and unavailability as result.
It depends
RabbitMQ was written focused on High troughput when you don't cares about consistency, if you configure RabbitMQ to have consitency it will have a very similar performance to ActiveMQ.
So it will depend what are your requirements, I work on a financial company so we never can lost a message, lost a message means someone that will not be paid or charged, so we had to configure RabbitMQ to ensure consistency (and it require a lot of work, configuring the cluster, Spring AMQP, etc.) then it's performance decreased and was comparable to ActiveMQ.
Of course ActiveMQ performance is awesome, is more than we need, we are using Oracle as persistence storage, you can use kahab or zookeeper and have a much higher performance, of course you also can create more ActiveMQ clusters, so broker performance probably will not be a problem for you, maybe if you are Netflix and want to process videos using the message broker, then you can consider use Kafka
I have not benchmarks results for that, just saying about my 3 years experience using the two brokers processing millions of messages per day.
Message consistency is not RabbitMQ focus
RabbitMQ can garantee that you will not lost messages, but what you must have in mind that by default RabbitMQ is configured for throughput not consistency. For example:
For all these cases, is possible to configure RabbitMQ to grant consitency, just have in mind that by default, RabbitMQ don't cares about consitency, ActiveMQ do
I showed you some points of my experience with these two broker solutions, considering my experience I prefer to use ActiveMQ or any JMS solution first because it is more mature, have more features, this way it tend to have more solutions for the business problems.
RabbitMQ is also very mature and solve most of problems that I had, so if you like RabbitMQ just consider search that the problems you want to solve can be covered by RabbitMQ.