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