redis, rabitmq contrast

　　　　　　redis, rabitmq contrast

Original Address

 

brief introduction

 

RabbitMQ

 

RabbitMQ is a messaging middleware implement AMQP (Advanced Message Queuing Protocol), and originated in the financial system to store and forward messages in a distributed system, in terms of ease of use, scalability, high availability, and so doing well . Message middleware mainly for decoupling between the components, sender of the message without knowing the user's presence information, and vice versa.

 

Redis

 

Key-Value of a NoSQL database development and maintenance is very active, although it is a Key-Value database storage system, but it does support the MQ function, it can use as a lightweight queue service to use.

 

---

 

Specific Contrast

 

Reliable consumer

 

Redis: there is no mechanism to ensure that the consumer message, when consumer spending failed, the message body is lost, you need to manually deal with
RabbitMQ: news consumer has confirmed, even if consumer spending fails, the message body will automatically return to the original queue, at the same time be persistent throughout, to ensure that the message body is correct consumption

 

Reliable release

 

Reids: not available, the need to achieve self-
RabbitMQ: has confirmed release function, to ensure that messages are posted to the server

 

High Availability

 

Redis: using separate master-slave mode, read and write, but not very well failover official solution
RabbitMQ: the use of cluster disk, memory nodes, any single point of failure will not affect the overall operation of the queue

 

Endurance of

 

Redis: Redis instance the entire persisted to disk
RabbitMQ: queue, the message, you can choose whether or not to persist

 

Consumer Load Balancing

 

Redis: not available, the need to achieve self-
RabbitMQ: according to consumer case, the message of a balanced distribution

 

Queue monitoring

 

Redis: not available, the need to achieve self-
RabbitMQ: background can monitor all of the information a queue (memory, disk, consumers, producers, rate, etc.)

 

flow control

 

Redis: not available, the need to achieve self-
RabbitMQ: the server is overloaded, the rate will be limited to producers, ensure service reliability

 

Access to team performance

 

For the team and the operations team RabbitMQ and Redis, and implementing a million times, once every 100,000 recorded execution time.
Test data is divided into data 128Bytes, 512Bytes, 1K 10K and four different sizes.

Note: This data comes from the Internet, part of the data is wrong, corrected

 

---

 

Application Scenes

 

Redis: Lightweight, high concurrency, delay-sensitive
real-time data analysis, spike counter, cache, etc.

 

RabbitMQ: Heavyweight, high concurrency, asynchronous
bulk data asynchronous processing, parallel tasks serialized, high-load task load balancing