Redis Pub/Sub vs Rabbit MQ

My team wants to move to microservices architecture. Currently we are using Redis Pub/Sub as message broker for some legacy parts of our system. My colleagues think that it is naturally to continue use redis as service bus as they don't want spend their time on studying new product. But in my opinion RabbitMQ (especially with MassTransit) is a better approach for microservices. Could you please compare Redis Pub/Sub with Rabbit MQ and give me some arguments for Rabbit?

Upvotes: 26

Views: 25741

Answers (4)

Hunor Portik
Hunor Portik

Reputation: 78

I have recently tried out Redis streaming feature, so I'm not the most knowledgeable in it.

What I can tell is, that for business critical systems where one has to have several partitions or topics (in Kafka terms -- take a look here if u're already familiar with kafka) to better spread the load, it might be robust enough up to a certain level, depending on the business needs.

TBH, for smaller projects it's one of the easiest to use if u're familiar with Redis. If it's a bigger-sized project, but needs to be with high SLA and low latency, it's costlier than other solutions (constantly in-memory data), but does its job well.

My choice for this Redis streaming was obvious, since I rely on GCP which offers convenient way to deploy & use it, but again, depending on several factors it might or might not be a good choice, thus running a simple MQTT/RMQ might be waaay cheaper and still manageable performance.

The old comment was valuable in its time, but since then, Redis has really evolved and become a really well-versed tooling, with good observability dashboards/metrics out of the box, as well.

Upvotes: 0

anydasa
anydasa

Reputation: 2623

I guess it depends on needs. I use mostly rabbitmq, but I have a task...

I have a list of users to connect by socket and listen to data all of them. It is managed by a single script with an infinite loop. I want to connect to all of them on startup. I want to make a new connection on inserting new items and disconnecting if the item was removed.

If the script fails, I want to restart it with reconnecting all users

So... if I use just a rabbitmq, I have to store a list of users somewhere separately

Upvotes: 0

Alexey Zimarev
Alexey Zimarev

Reputation: 19600

Redis is a fast in-memory key-value store with optional persistence. The pub/sub feature of Redis is a marginal case for Redis as a product.

RabbitMQ is the message broker that does nothing else. It is optimized for reliable delivery of messages, both in command style (send to an endpoint exchange/queue) and publish-subscribe. RabbitMQ also includes the management plugin that delivers a helpful API to monitor the broker status, check the queues and so on.

Dealing with Redis pub/sub on a low level of Redis client can be a very painful experience. You could use a library like ServiceStack that has a higher level abstraction to make it more manageable.

However, MassTransit adds a lot of value compared to raw messaging over RMQ. As soon as you start doing stuff for real, no matter what transport you decide to use, you will hit typical issues that are associated with messaging like handling replies, scheduling, long-running processes, re-delivery, dead-letter queues, and poison queues. MassTransit does it all for you. Neither Redis or RMQ client would deliver any of those. If your team wants to spend time dealing with those concerns in their own code - that's more like reinventing the wheel. Using the argument of "not willing to learn a new product" in this context sounds a bit weird, since, instead of delivering value for the product, developers want to spend their time dealing with infrastructure concerns.

Upvotes: 48

BlackBrain
BlackBrain

Reputation: 1019

RabbitMQ is far more stable and robust than Redis for passing messages.

RabbitMQ is able to hold and store a message if there is no consumer for it (e.g. your listener crashed , etc).

RabbitMQ has different methods for communication: Pub/Sub , Queue. That you can use for load balancing , etc

Redis is convenient for simple cases. If you can afford losing a message and you don't need queues then I think Redis is also a good option. If you however can not afford losing a message then Redis is not a good option.

Upvotes: 27

Related Questions