Groupcache: how to emulate Expiration time
I noticed in the design decision Setting and expiration time as been left out. I imagine that this is because you have an idea on how to emulate this feature.
The use case I have in mind is building a cached reverse proxy in front a web app. I know that pages should be cache for X min.
Could you please elaborate a bit on how you would approach this ?
(Not sure this is the right place to ask question.)
yml
All 3 comments
As far as I have understood the design of groupcache, you can not invalidate or update cached items.This feature has been left out because it is extremely hard in a distributed system and would require expensive consensus algorithms (e.g. paxos).
You can however generate a unique cache key every X minutes by encoding the time information in the cache key itself. For example "foo-12:30" might uniquely describe the item "foo" at the time 12:30. Your application then can access this item until let's say 12:40. At this time, a new item, "foo-12:40" might be generated and the old item ("foo-12:30") will eventually expire once the clients have stopped accessing it.
If your distributed application is able to update and retrieve revision numbers in a consistent way (you can do that for example with doozerd, zookeeper or the database solution of your choice), you can also encode this revision number as part of the cache key. Alternatively, you might also be able to use the "Last-Modified" or "ETag" HTTP headers as some kind of revision number in your web proxy.
tux21b
on 29 Jul 2013
Yes, what tux21b said. (intentionally left out, at least for now).
bradfitz
on 29 Jul 2013
Thanks @tux21b for the suggestion regarding revisions!
anacrolix
on 3 Oct 2013
Related issues
abennett
·
3Comments
AlexanderChen1989
·
6Comments
orcaman
·
9Comments
cowboyrushforth
·
5Comments
qwyang
·
3Comments
Most helpful comment
As far as I have understood the design of groupcache, you can not invalidate or update cached items.This feature has been left out because it is extremely hard in a distributed system and would require expensive consensus algorithms (e.g. paxos).
You can however generate a unique cache key every X minutes by encoding the time information in the cache key itself. For example "foo-12:30" might uniquely describe the item "foo" at the time 12:30. Your application then can access this item until let's say 12:40. At this time, a new item, "foo-12:40" might be generated and the old item ("foo-12:30") will eventually expire once the clients have stopped accessing it.
If your distributed application is able to update and retrieve revision numbers in a consistent way (you can do that for example with doozerd, zookeeper or the database solution of your choice), you can also encode this revision number as part of the cache key. Alternatively, you might also be able to use the "Last-Modified" or "ETag" HTTP headers as some kind of revision number in your web proxy.