“Redis is a fantastic data structure server, typically deployed as a shared heap. It provides fast access to strings, lists, sets, maps, and other structures with a simple text protocol. Since it runs on a single server, and that server is single-threaded, it offers linearizable consistency by default: all operations happen in a single, well-defined order. There’s also support for basic transactions, which are atomic and isolated from one another.

Because of this easy-to-understand consistency model, many users treat Redis as a message queue, lock service, session store, or even their primary database. Redis running on a single server is a CP system, so it is consistent for these purposes…”

http://aphyr.com/posts/283-call-me-maybe-redis

http://antirez.com/news/55

“Redis is a key-value in memory data store typically used for caches and other such mechanisms to speed up web applications. We however store all our data in Redis as our primary database.

The web is abound with warnings and cautionary tales about going this route. There are horror stories about lost data, hitting memory limits, or people unable to effectively manage the data within Redis, so you might be wondering “What on earth were you thinking?!” So here is our story, why we decided to use Redis anyway, and how we overcame those issues.

First of all, I want to stress that most applications shouldn’t even worry about the engineering hurdles involved with going this route. It was important for our use case, but we may very well be an edge case…”

http://moot.it/blog/technology/redis-as-primary-datastore-wtf.html

“Redis is an in-memory key-value data store that provides a small number of primitives suitable to the task of building monitoring systems. As a lot of us are hacking in this space I thought I’d write a blog post summarizing where I’ve been using it in a little Sensu like monitoring system I have been working on on and off.

There’s some monitoring related events coming up like MonitoringLove in Antwerp and Monitorama in Boston – I will be attending both and I hope a few members in the community will create similar background posts on various interesting areas before these events…”

http://www.devco.net/archives/2013/01/06/solving-monitoring-state-storage-problems-using-redis.php

“There’s always something interesting to work on at CopperEgg. Even the simplest things can get pretty interesting. Take billing for example. Seems like an easy thing to do at first, but once you realize the complexity of how we bill, you will see why it isn’t as simple as it seems.

We bill monthly, however we track usage hourly, a lot like Amazon Web Services pay-per-use model. In order to do that, you need to know when a service was used for any given hour so you can bill for that hour. We also want to know which hours we monitored a given system or website on a per customer basis. So we need to know the total hours of each service used over the month, we need to know which hours in the month a particular system/probe was being monitored, and how many hours per system/probe we monitored for that month. We also want to be able to show our customers throughout the month their usage to date.

Up until recently we had a process that would run and query for data (metrics) to see if a service was used during that time. That’s a bit nasty, since it puts constant load on our datastore just to find out if something sent us data in a particular timeframe. It also depended on other processes that we run, and makes billing depend on things that have nothing to do with billing. We wanted to split that out…”

http://copperegg.com/redis-bit-operations-use-case-at-copperegg/