New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
how to emulate Expiration time #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. |
Yes, what tux21b said. (intentionally left out, at least for now). |
Thanks @tux21b for the suggestion regarding revisions! |
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.)
The text was updated successfully, but these errors were encountered: