You wouldn't. Redis doesn't support implementing an LRU cache. Redis does function well as a cache, and is far better than memcached for any data you don't want randomly disappearing, but it just doesn't do an LRU cache.

Redis will only evict data when it's explicitly removed or expired, and it will store as much data as you put into it.

memcached will evict the least-recently used data based upon memory pressure, and will only use as much memory as you configure it to.

They overlap in functionality, but I find they work better in complement to each other than having one replace the other. Redis for data you want to persist, possibly with a timeout -- user sessions, for example. memcached for data you want to cache, as long you have the free memory for it.

You can configure a redis DB using the maxmemory flag instead of setting expiries, so yes it can be used as an LRU cache.

Probably not as fast as memcached, but one situation where it would be appropriate is if you're already using redis in your stack for something else (fast writes). Rather than adding another piece of complexity to your stack you can instead get double use out of redis as a cache as well.

See: http://antirez.com/post/redis-as-LRU-cache.html

My mistake, I was not aware of those configuration options. Thanks for the correction.

Well in your defence, I don't think they're in the current stable release, but rather the 2.2 branch (RC).

Except that algorithm isn't lru

It is in 2.2. Check out:

maxmemory-policy allkeys-lru

How do I know? We ( http://bu.mp ) push 100s of GB though redis every day in LRU mode.

Why wouldn't you? As I understand it, Redis is a superset of memcached (since you can turn disk writes off) and comparable in speed. I, at least, use it as a memcached replacement for storing sessions with the added benefit of not having them all expire if I need to restart the server at some point.

Basically, I exactly agree with the GP's use cases. ACID for things I want to keep, redis for small things that need to be fast (sessions, stats counters, etc).

If it is a simple KV store then there is no reason to use Redis. If you want the ability to search keys then Redis will most likely suit you better.

Agreed on that. Plus, i noticed a mistake made by a lot of people, Redis is NOT memcached. That's just as easy as that. You can use Redis the same way as you would use memcached, but that would be a waste. The power of Redis resides in its data structures and the usage you make of it. You can make some pretty powerful stuff, easily and with performance. Nested Comment system (https://gist.github.com/803251), autocomplete (http://pastebin.com/E5h1TLWz), all of that with high performance over large dataset, and much more, stuff that is not doable with Memcached. Also, the role of Redis is not to replace SQL databases, i personally view it, and use it, as a complement to it, and it works just perfectly. (I am fully aware that the examples given are possible with SQL solution, but experience in production/development as shown me that Redis is easier and faster when it comes to not too complex operations like these ones)