Introduction to Message Brokers (Part 2): ActiveMQ vs. Redis Pub/Sub

In our previous overview of the most popular messaging systems, we were talking about Apache Kafka vs. RabbitMQ. Now, let's take a look at the less powerful, but still very helpful, message brokers. We will consider the pros and cons of ActiveMQ and Redis Pub/Sub. Although these solutions aren't very suitable for processing big data, they provide a strong basis for creating small business analytics tools.

Apache ActiveMQ

Pricing: free 

Official website: http://activemq.apache.org 

Useful resources: AmazonMQ

Pros:

• Dynamic queue creation.
• Web UI for queue management.
• The broker is configurable through XML.
• The product is actively maintained.

Cons:

• Messages must be sent to either queues or topics.

ActiveMQ is an Apache product written in Java. Developers who don't need to deal with huge amounts of data usually prefer this simple and reliable open source solution. The message broker has become popular due to its speed and compatibility with many protocols and advanced technologies.

The Story of ActiveMQ Development

At the beginning of ActiveMQ development, there were two reasons to start out the project:

1. The high price of the most popular messaging tools of those times.
2. The necessity of working on a totally J2EE compliant system (compatibility with Apache's licensing).

Unlike its competitors (EMS/TIBCO, SonicMQ, WebSphereMQ), the messaging system combined accessibility with useful and effective features. LogicBlaze developed the free message broker in 2004. It was hosted by the CodeHaus. In 2007, the system was donated to the ASF. Its founders continued developing the product. ActiveMQ is actively maintained today.

ActiveMQ Capabilities

The message-oriented middleware provides excellent opportunities for Java developers. The system is based on the JMS standards specification and supports async communication. So, it allows the programmer to organize fast and stable messaging processing within enterprise projects. I can define three key advantages of the messaging system.

1. Compatibility 

You can combine ActiveMQ with other mainstream messaging tools, namely Amazon Simple Queue Service, Apache Kafka, and RabbitMQ. In addition, there is an opportunity to use Amazon MQ. It's an implementation of ActiveMQ, integrated with AWS cloud solutions.

2. Convenience

The message broker is based on the JMS API. As a result, the processes of creating, transmitting, and receiving messages are determined by a unified standard. ActiveMQ clients can also be written in programming languages other than Java, such as Python, Node.js-based JavaScript, and Ruby. 

3. Flexibility 

The messaging system works fast and helps to use Enterprise Integration Patterns and other modern solutions. At the same time, it's quite easy to access and get used to. Simple configuration of the message broker is an important advantage for the implementation of enterprise projects. Moreover, ActiveMQ supports many protocols (WebSockets, AMQP, REST, OpenWire, STOMP, MQTT, etc).

ActiveMQ Working Principle

Just like other messaging systems, the program transmits data from one application (producer) to another (consumer). So, its architecture includes:

• the broker.
• the destination app.
• the client app.

The message broker routes each message through one of two types of destinations:

1. The first is a queue. It's a part of the point-to-point messaging system, where there is only one consumer.
2. The second is a topic, which is included in "pub/sub" messaging and implies the involvement of several consumers.

The ability to use two types of messaging is also a great benefit. Using a single message broker for both queues and topics gives the programmer additional flexibility. In the case of point-to-point messaging, ActiveMQ works as a load balancer. It routes each message from the queue to one of the available consumers. Meanwhile, if you prefer the "pub/sub" messaging, the system delivers each message to every consumer subscribed to the topic.

ActiveMQ Peculiarities

Thanks to the asynchronous process of message delivery, the consumer app doesn't need to receive it immediately. ActiveMQ separates the two tasks into: 

1. the producer's task of creating and sending a message.
2. the consumer's task of fetching it.

So, the applications are independent of each other. The producer's task is completed as soon as it sends a message to a broker. It's no matter whether or when a consumer app fetches the message. This type of messaging is called loose coupling and provides some benefits to the developer.

Loose Coupling Benefits

Productivity 

The producers don't need to wait for a signal from the consumer or broker. So, the process of sending messages is very fast. The system is capable of achieving a huge throughput. 

Adaptability 

Even if the client app is temporarily unavailable (suddenly added to the system, or changed), the messaging process isn't interrupted or stopped. 

Heterogeneity 

Independent clients can be written in any appropriate language because they don't interact with each other.

All in all, I recommend Apache ActiveMQ as a hybrid and flexible message broker. It's especially suitable for enterprise projects. ActiveMQ is relatively easy to set up in complex structures, shows good reliability and high throughput.

Redis PUB/SUB

Pricing: free 

Official website: https://redis.io

Useful resources: tutorial

Pros:

• Flexibility (re-routing messages, tracking of detailed in-server metrics, etc.).
• Simple installation, configuration, maintenance.
• High-speed access for a database.
• A great choice for fast, set-based operations.

Cons:

• Challenging configuration of clustering, especially with multiple write nodes.
• Persistence can impact performance.
• Lack of advanced security options and access control.

The advanced database is written in C. First of all, Redis performs functions of storing data, but it also provides an opportunity for messaging. It helps to create fast, scalable applications. Released under a BSD 3-clause license, Redis is quite popular for the development of tech solutions for small and medium business.

The Story of Redis Pub/Sub Development

Created in 2009, the REmote DIctionary Server still remains an open source project. Its founder worked on his own European startup. It was a real-time web log analyzer, which required increasing of scalability. Facing some challenges with workloads while using traditional databases, the programmer started development of the first version of Redis. He made the project open source and received support from the Ruby community. Instagram and GitHub were among the first great projects adopting the new database. The last program's release included a new data structure for storing multiple fields and string values with an automatic, time-based sequence.

Redis Pub/Sub Working Principle

Implementing the messaging system for queue applications, Redis Pub/Sub works with three main terms:

1. Publisher (sends messages).
2. Subscriber (receives messages).
3. Channel (links the publisher and subscriber).

It's also important that the number of channels isn't limited for a single subscriber. At the same time, publishers are able to send messages to any number of subscribers on a channel. Since all messages in the Publisher/Subscriber platform are fire-and-forget, they are deleted in case of no subscriber determined.

Note: You should know that "redis-cli" won't accept any commands once in subscribed mode. It can only quit the mode with Ctrl-C. 

Redis Pub/Sub Peculiarities

Just like ActiveMQ, Redis Pub/Sub publishers and subscribers are independent of each other. So, when the first of them sends a message, it doesn't know what receivers are connected to that channel. This is also true for the receivers that subscribe to channels, without knowledge of other publishers. 

One of the main advantages of this technology is the opportunity to use clients written in different languages. You can read the full list. It includes such popular solutions, as Ruby, Python, PHP, Objective-C, Node.js, Java, Clojure, C++, C#, etc.

Using Redis's Pub/Sub within your infrastructure, you will enjoy quick messaging and communication between processes. The broker's simplicity and performance make it popular for a wide range of use cases. Taking into account the famous database and the cache feature, Redis can become a handy technology for your future project. 

Here we end our journey through the self-deploy messaging systems. Let me know if you like such reviews and your opinions about all of these technologies. Do you want to get more information about cloud message brokers (AWS SQS, SNS, Amazon Kinesis, GCP Pub/Sub, Microsoft Azure, etc.)?