Comparison between rabbitmq and redis queues

This article only compares the queue applications of rabbitmq and redis.
The specific implementation method depends on the actual requirements of the system.

Brief Introduction

 

Rabbitmq

Rabbitmq is a message-oriented middleware that implements amqp (Advanced Message Queue Protocol). It originated from the financial system and is used to store and forward messages in distributed systems, it performs well in terms of ease of use, scalability, and high availability. Message-oriented middleware is mainly used for decoupling between components. message senders do not need to know the existence of message users, and vice versa.

Redis

It is a key-value nosql database and is very active in development and maintenance. Although it is a key-value database storage system, it supports the MQ function, therefore, it can be used as a lightweight queue service.

Comparison

 

Reliable consumption

Redis: there is no corresponding mechanism to ensure message consumption. When consumer consumption fails, the message body is lost and needs to be manually processed
Rabbitmq: with message consumption confirmation, even if the consumer fails to consume the message body, the message body is automatically returned to the original queue, and the entire process can be persisted to ensure that the message body is correctly consumed.

Reliable release

Reids: not provided, which must be implemented by yourself
Rabbitmq: Provides the release confirmation function to ensure that messages are published to the server.

High Availability

Redis: Master/Slave Mode, read/write splitting, but there is no perfect official solution for failover
Rabbitmq: the cluster uses disks and Memory nodes. Any single point of failure will not affect the operations of the entire queue.

Persistence

Redis: persists the entire redis instance to the disk
Rabbitmq: queue, message, can choose whether to be persistent

Consumer Load Balancing

Redis: No. You need to implement it on your own
Rabbitmq: distributes messages in a balanced manner based on consumer conditions.

Queue monitoring

Redis: No. You need to implement it on your own
Rabbitmq: the backend can monitor all information of a queue (memory, disk, consumer, producer, rate, etc)

Traffic Control

Redis: No. You need to implement it on your own
Rabbitmq: when the server is overloaded, the producer rate is limited to ensure service reliability.

Inbound/outbound Performance

For rabbitmq and redis, 1 million operations are performed each time, and the execution time is recorded every 0.1 million operations.
The test data is divided into four data sizes: 128 bytes, 512 bytes, 1 K, and 10 K.
The experiment shows that:
When you join the team, when the data volume is relatively small, redis's performance is higher than rabbitmq, and if the data size exceeds 10 K, redis is slow and intolerable;
Redis delivers excellent performance regardless of the data size, while rabbitmq delivers far lower performance than redis.

Note: This data comes from the Internet, but it is basically consistent with the data I tested earlier.

Application Scenario Analysis

Redis: lightweight, highly concurrent, latency sensitive
Real-time data analysis, seckilling counters, cache, etc.

Rabbitmq: heavyweight, highly concurrent, asynchronous
Asynchronous batch data processing, serialization of parallel tasks, and load balancing of High-load tasks

References:

1. redis application scenarios

2. rabbitmq work queue for Load Distribution of high-performance tasks

3. redis persistence

4. MQ comparison of various types