RABBITMQ vs. Redis queues

RABBITMQ vs. Redis queues

This article compares only when RABBITMQ and Redis do queue applications.
How to implement it depends on the actual needs of the system.

Brief Introduction

RabbitMQ

RABBITMQ is one of the messaging middleware implementations of the AMQP (Advanced Message Queuing Protocol) that originated in the financial system and is used to store and forward messages in distributed systems, with good performance in terms of ease of use, scalability, and high availability. Message middleware is mainly used for decoupling between components, the sender of the message does not need to know the existence of the message consumer, and vice versa.

Redis

is a key-value NoSQL database, development and maintenance is very active, although it is a Key-value database storage system, but it natively supports MQ function, so it can be used as a lightweight queue service.

Specific comparison

Reliable Consumption

Redis: There is no corresponding mechanism to guarantee the consumption of messages, when consumer consumption fails, the message body is lost and needs to be handled manually
RabbitMQ: With message consumption confirmation, even if consumer consumption fails, it will automatically return the message body to the original queue, while the whole process can be persisted to ensure the correct consumption of the message body

Reliable Publishing

Reids: Not available, you need to implement it yourself
RabbitMQ: Has a release confirmation feature to ensure that messages are published to the server

Highly Available

Redis: Master-slave mode, read-write separation, but fail-over is not a very well-established official solution
RabbitMQ: Cluster uses disk, memory node, any single point of failure will not affect the operation of the entire queue

Persistence of

Redis: Persisting an entire Redis instance to disk
RabbitMQ: Queue, message, can choose whether to persist

Consumer Load Balancing

Redis: Not available, you need to implement it yourself
RabbitMQ: Balanced distribution of messages based on consumer conditions

Queue Monitoring

Redis: Not available, you need to implement it yourself
RabbitMQ: Background can monitor all the information of a queue (memory, disk, consumer, producer, rate, etc.)

Flow Control

Redis: Not available, you need to implement it yourself
RabbitMQ: Server overload situation, the producer rate will be limited to ensure service reliability

Access Team performance

For RABBITMQ and Redis on-board and out-of-team operations, each execution 1 million times, every 100,000 times the execution time is recorded.
The test data is divided into 128Bytes, 512Bytes, 1K and 10K four different sizes of data.
Experiments show that:
In the queue, the performance of Redis is higher than RABBITMQ when the data is compared, and if the data size exceeds 10k,redis, it is too slow to endure;
At the time of the team, Redis showed very good performance regardless of the size of the data, while the RABBITMQ performance was much lower than Redis.

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

Application Scenario Analysis

Redis: Lightweight, high concurrency, latency sensitive
Instant data analysis, seconds kill counter, cache, etc.

RabbitMQ: Heavyweight, high-concurrency, asynchronous
Batch data asynchronous processing, parallel task serialization, load balancing of high load tasks, etc.

RABBITMQ vs. Redis queues