[FEATURE REQUEST]maxmemory-policy

[GoogleCodeExporter]

I mainly use Redis as a cache server, but also store some session datas with a 
expiration time. The problem is, session keys might be discarded if max-memory 
reached.

One solution is using a single Redis instance to store session datas without 
maxmomory set, but that makes the architecutre more complex and much annoying 
to deploy.

I'd expect a mechanism to prevent a key with expiration time being removed by 
maxmemory-policy.

e.g.: add a single bit to each key, which indicates whether the key can be 
removed by maxmeory-policy.

Original issue reported on code.google.com by timium.z...@gmail.com on 9 Sep 2011 at 1:45

[GoogleCodeExporter]

So.. you want to have a TTL for keys, but you don't want anything to be evicted 
before the TTL? There is already a configuration option that does exactly that:
maxmemory-policy noeviction

It is documented in the configuration file:
https://github.com/antirez/redis/blob/unstable/redis.conf

Original comment by josiah.c...@gmail.com on 9 Sep 2011 at 4:42

[GoogleCodeExporter]

The redis instance contains both session datas & cached datas, all have TTL. I 
want cache datas to be evicted, but expect sessions datas never been evcited.

Original comment by timium.z...@gmail.com on 9 Sep 2011 at 7:29

[GoogleCodeExporter]

This gets a -1 vote from me; Redis is built to make it easy to spin up multiple 
instances on the same machine. Adding a "special" kind of TTL for some keys 
just smells like a bad idea.

Original comment by josiah.c...@gmail.com on 9 Sep 2011 at 10:35

[GoogleCodeExporter]

Hello Timium,

I understand the need, but design-wise I think it is better to avoid 
introducing such a feature.

The suggested way is to either don't expire sessions with the built-in 
mechanism but using a sorted set for expiring, or just using two different 
Redis servers. I would pick the latter.

Salvatore

Original comment by anti...@gmail.com on 12 Sep 2011 at 11:36

• Changed state: WontFix