Achieving JMS/AMQP messaging patterns using Redis

Question

This question arises as I came across some mentions (such as this), about using a Messaging software such as ZeroMQ alongwith Redis, but I keep hearing about Redis itself used a messaging-system. So, if Redis is used along with other messaging systems, does it mean Redis has some serious deficiencies when used as a messaging system by itself ?

While the use of Redis for caching and pub/sub is clear to me, it is not clear if Redis can be used in place of a full-fledged messaging system such as JMS, AMQP or ZeroMQ.
Leaving alone the standards-compliance aspect and only concentrating on the functionality/features, does Redis provide support for all the messaging patterns/models required of a messaging system ?

The messaging patterns I am talking about are :

1. RPC/Request-reply (an example using ActiveMQ/JMS and another using RabbitMQ/AMQP)
2. Pipeline/Work queues (once and atmost once consumption of each message)
3. Broadcast (everyone subscribed to the channel)
4. Multicast (filtering of messages at server based on consumers' selectors)
5. Any other messaging pattern ?

If yes, then Redis seems to solve two (possibly more) aspects at once: Caching and Messaging.

I am looking at this in the context of a web-application backed by a Java/Java EE server. And I am looking at this not from a proof-of-concept point-of-view but from a large-scale software development angle.

Edit1:
user:791406 asked a valid question:

"Who cares if redis supports those patterns; will redis meet your SLA and QoS needs?"

I thought it is better to give this detail as part of the question instead of in the comments section.

My current needs are less to do with SLA and QOS and more to do with choosing a tool for my job (messaging) that I can use even when my requirements grow (reasonably) in future. I am starting with simplistic requirements at first and we all know requirements tend to grow. And NO, I am not looking for a one tool that does it all. I just want to know if Redis fulfills the usual requirements expected out of a messaging system, like ActiveMQ/RabbitMQ does. Ofcourse, if my SLA/QOS needs are extreme/eccentric, I would need to get a special tool for satisfying that. For ex: In some cases ZeroMQ could be chosen over RabbitMQ due to specific SLA requirements. I am not talking about such special requirements. I am focusing on average enterprise requirements.

I was afraid (based on my little understanding) that eventhough redis could be used as a basic tool for my messaging needs of today, it might be the wrong tool for a real messaging job in future. I have experiences with messaging systems like ActiveMQ/RabbitMQ and know that they could be used for simple to (reasonably) complex messaging needs.

Edit2:

1. The redis website mentions "Redis is often used as a messaging server" but how to achieve the messaging patterns is not clear.

2. Salvatore sanfilippo mentions Redis users tend to use it as a database, as a messaging bus, or as a cache. To what extent can it serve as a "messaging bus" is not clear.

3. When I was trying to find out what messaging requirements of JMS that redis doesnt support, I came across something that Redis supports but JMS doesnt: Pattern-matching subscriptions i.e Clients may subscribe to glob-style patterns in order to receive all the messages sent to channel names matching a given pattern.

Conclusion:

I have decided to use JMS for my messaging needs and use Redis for Caching.

Answer 1

What are you needs?

I think the question you should be asking yourself is "what quality of messaging do I need to support my application?" before deciding on a messaging platform. Who cares if redis supports those patterns; will redis meet your SLA and QoS needs? Focus on that first, then make your technology decision based on that assessment.

Having said that, I'll offer my input on how you can make that decision...

Highly-Reliable/Persistent/Durable Messaging
Let's take an extreme case: say you're building a trading or financial application. Such applications demand strict SLA's where message persistence, reliability, exactly-once delivery and durability are paramount. Using redis as the messaging backbone for this case is probably a bad choice, lots of reasons why...

• message redelivery (when the sh*t hits the fan)
• message store replication when redis goes down
• message transactions (redis can't do XA)
• producer/subscriber fault tolerance and disconnection resilience
• message order sequencing
• sending messages when broker is down (store-and-forward)
• single-threaded redis may become bottleneck

If your system has strict SLA's, some or all of these issues will most definitely arise, so how will you handle these limitations? You can implement custom code around redis to address some issues, but why bother when mature messaging platforms like ActiveMq, WebsphereMQ, and WebLogic JMS offer persistence, reliability, and fault tolerance? You said you're on a Java/Java EE stack, so you're in a position to use some of the most robust messaging frameworks available, either open source or commercial. If you're doing financial transactions, then you need to consider these options.

High Performance/Large Distributed Systems Messaging
If you're building a social network or gaming platform where you want performance over reliability, ZeroMq is probably a good fit. It's a socket communication library wrapped in a messaging-like API. It's decentralized (no broker), very fast, and highly resilient and fault tolerant. If you need to do things like N-to-N pub/sub with broker intermediaries, flow control, message persistence, or point-to-point synchronization, ZeroMq offers the necessary facilities and code samples to do it all with minimal code while avoiding building solutions from the ground up. It's written in C but has client libraries for nearly every popular language.

Hope that helps...