A very detailed article about creating a message queue (nb: not Pub/Sub) using Redis:

One particular combination has recently allowed us to implement a moderately (read: good enough) reliable message delivery mechanism for multiple consumers consuming messages at their own pace.

Redis allowed for all of the implementation characteristics we were looking for, namely:

• Concurrency: Because all operations in Redis are atomic, supporting concurrency without too much of a hassle is straightforward.
• Persistence: Configured properly, we can ensure persistence of our queues to disk using one of the supported Redis persistence strategies.
• Lightweight: Using Redis from any language/platform is extremely simple and provisioning it / maintaining it on a production server is dead easy.

I’m always saying to use the right tool for the job, but maintaining the simplicity of a system architecture is an art too.

Original title and link: Reliable Delivery Message Queues With Redis (NoSQL database©myNoSQL)

via: http://davidmarquis.posterous.com/reliable-delivery-message-queues-with-redis

Santosh Kumar:

As you work more with Redis you soon start finding yourself building out workflows, i.e. small pieces of code that talk to each other via Redis. For someone familiar with a Service Oriented approach to building systems this should feel like deja-vu. Except, instead of using a protocol (HTTP, TCP, UDP, AMQP, ZeroMQ) we are going back to CS101 using a good old queue datastructure.

I think instead of workflows and Service Oriented, the right term is message services or MOM. Indeed, Redis’ blocking queues, the corresponding commands, and PUB/SUB support provides one with the basic building blocks of message services. But these are useful only if you don’t need specialized solutions (RabbitMQ, ActiveMQ, etc.) which will provide solutions for more complicated scenarios.

Later in the post, Kumar mentions implementing transactions for the scenario he picked, payment processing, using Redis’ multi-exec. If things haven’t changed radically lately, I’d underline the fact that Redis MULTI/EXEC/DISCARD is just a batched serialized executor and not ACID transactions.

Original title and link: Redis-Based MOM: Redis for Processing Payments (NoSQL database©myNoSQL)

via: http://santosh-log.heroku.com/2011/08/19/redis-for-processing-payments/