ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

MOM: All content tagged as MOM in NoSQL databases and polyglot persistence

Reliable Delivery Message Queues With Redis

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.wordpress.com/2013/01/03/reliable-delivery-message-queues-with-redis/


Redis-Based MOM: Redis for Processing Payments

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/