RabbitMQ vs Redis

Difference Between RabbitMQ and Redis

RabbitMQ is one of the most widely used open-source message brokers. It originally implemented the Advanced Message Queuing Protocol (AMQP) but has been extended to support Streaming Text Oriented Messaging Protocol (STOMP), Message Queuing Telemetry Transport (MQTT), and other protocols. It is written in Erlang. Redis is an open-source in-memory data source which can function as a message-broker, database, and a cache. It supports various data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes with radius queries and streams. It is quite fast and light-weight. Here we will discuss the top 9 difference between RabbitMQ vs Redis which are explained in detail.

Head to Head Comparison Between RabbitMQ and Redis (Infographics)

Below are the top 9 differences between RabbitMQ vs Redis:

Key Differences Between RabbitMQ and Redis

Let us look at the key differences between RabbitMQ vs Redis as below:

1. Redis is a database that can be used as a message-broker. On the other hand, RabbitMQ has been designed as a dedicated message-broker. RabbitMQ outperforms Redis as a message-broker in most scenarios. RabbitMQ guarantees message delivery. This is achieved by:

• Message Durability: Messages are not lost once stored in RabbitMQ.
• Message Acknowledgements: Consumers send acknowledgments to producers after successfully consuming a message.

2. Redis doesn’t guarantee message delivery while using its pub/sub mechanism. If a subscriber isn’t active, it won’t receive the messages it subscribed to. RabbitMQ supports persistent messages in addition to transition ones. The RabbitMQ persistence layer is meant for providing reasonably high throughput in most of the situations without configuration.

• The persistence layer consists of two components the queue index and the message store. The queue index is responsible for maintaining knowledge about where a given message is in a queue, along with whether it has been delivered and acknowledged. There is, therefore, one queue index per queue.
• The message store is a key-value store for messages, shared among all queues in the server. Messages (the body, and any metadata fields: properties and/or headers) can either be stored directly in the queue index, or written to the message store. There are technically two message stores (one for transient and one for persistent messages) but they are usually considered together as “the message store”.

Redis doesn’t support persistent messages as it is an in-memory data-store.

3. RabbitMQ allows you to use an additional layer of security by using SSL certificates to encrypt your data. Secure Sockets Layer (SSL) is one of the most popular security technology for establishing an encrypted connection between a server and a client. Redis, on the other hand, does not support SSL natively and in order to enable SSL, you have to opt for a paid service.

Redis recommends using Spiped for encrypting messages. Spiped is a tool for creating symmetrically encrypted and authenticated pipes between socket addresses, which would enable us to connect to one address (e.g., a UNIX socket on localhost) and transparently have a connection established to another address (e.g., a UNIX socket on a different system).

4. It differs in the way the message flows through the broker.

RabbitMQ:

• Producers publish a message to an exchange. The type must be specified while creating an exchange.
• The exchange receives the message and is now responsible for routing it. The exchange takes various message attributes into account, as the routing key, and that depends on the exchange type.
• Now, bindings must be created from exchange to the queues. The exchange will route the messages into the queues depending on the message attributes.
• The messages will stay in the queues until consumed by the consumers.
• The Consumers process the messages successfully and then these messages are removed from the queues.

Redis:

• Producers publish a message to a Redis Channel. There are two kinds of channels supported by Redis: Literal Channel and Pattern-Match Channel.
• The subscribers express interest in one or more channels.
• Messages are sent from a channel to all the subscribers that subscribed to that channel and there is no concept of routing based on message attribute here.

Comparison Table of RabbitMQ vs Redis

The table below summarizes the comparisons between RabbitMQ vs Redis:

RabbitMQ	Redis
It is a dedicated message-broker. It is widely used in implementations of highly centralized and distributed systems.	It can function both as a message-broker, database, and cache. It is very fast and light-weight and hence grabs the attention of developers around the globe.
It can be scaled up to send around 50K messages per second.	It can be scaled up to send around a million messages per second.
It supports powerful message routing. It is useful when we need to run the same job on a specific server, group of servers or all servers. The application sends one message and the exchange will route is based on the routing key.	It supports the basic operations of a message-broker. For powerful message routing, people won’t go for Redis.
It can be easily configured to use SSL, thus providing an additional layer of security.	You have to opt for SSL separately which is a paid service.
It supports both persistent and transient messages. Developers would prefer RabbitMQ if they need to store messages for re-process in case of failures.	It supports only transient messages. Developers would prefer Redis over RabbitMQ for real-time Applications.
It inherently supported clustering and outperforms Redis in this aspect.	Clustering was introduced in Redis 3.0.
It supports both point to point and pub-sub messaging techniques.	It supports only the pub-sub mechanism.
RabbitMQ handles large messages way better than Redis.	It is better suited for smaller messages. The latency is very high for larger messages (>1 MB)
It guarantees delivery of messages and thus preferable when you can’t afford messages loss.	It doesn’t guarantee the delivery of each message.

Conclusion

It is very important to choose a message broker depending on your use case. As Redis provides extremely fast service and in-memory capabilities, you should prefer it for short retention of messages where persistence is not so important. On the other hand, you would prefer RabbitMQ when there is a requirement for complex routing.

Recommended Articles

This is a guide to RabbitMQ vs Redis. Here we discuss the RabbitMQ vs Redis introduction, key differences with infographics and comparison table. You can also go through our other suggested articles to learn more –

1. Primary Key vs Foreign Key
2. Go vs Ruby Comparison Table
3. RabbitMQ vs SQS | Top Differences
4. Top Differences of Hazelcast vs Redis