英文:
Does GroupCache support explicit cache eviction like memcached delete? Why?
问题
GroupCache（https://github.com/golang/groupcache）是一个缓存和填充缓存的库，旨在在许多情况下替代memcached。是否有人对其源代码进行了研究，并对其原理或实现有很好的理解？GroupCache是否支持像memcached delete那样的显式缓存驱逐？为什么？
英文:
GroupCache (https://github.com/golang/groupcache ) is a caching and cache-filling library, intended as a replacement for memcached in many cases. Does somebody have done some research on the source code and have a good understanding its principles or implementation? Does GroupCache support explicit cache eviction like memcached delete? Why?
答案1
得分: 2
从README中：
> 不支持版本化的值。如果键“foo”的值为“bar”，则键“foo”必须始终为“bar”。既没有缓存过期时间，也没有显式的缓存驱逐。因此，也没有CAS，也没有增量/减量。
Groupcache的布局是为了性能，并且具有_超级热点项_的概念，这些项在对等组中进行了镜像。
如果支持显式缓存驱逐，那么必须从所有实例中删除_超级热点项_，这是不切实际的，因为它会对整个系统产生非常严重的性能影响，因为它必须锁定系统中每个对等体的主缓存行。
有关Groupcache设计决策的详细信息，您可以在golang-nuts中发布问题，并直接向Brad Fitzpatrick（作者）提问。
英文:
From the README:
> does not support versioned values. If key "foo" is value "bar", key "foo" must always be "bar". There are neither cache expiration times, nor explicit cache evictions. Thus there is also no CAS, nor Increment/Decrement.
Groupcache is laid out for performance and has the concept of super hot items, which are mirrored throughout a peer group.
If explicit cache eviction was supported, super hot items would have to be deleted from all instances which is unpractical because it would have a very bad performance impact on the overall system because it would have to lock the primary cache line of each and every peer in the system.
For specifics on the design decisions behind Groupcache you could post in golang-nuts and ask Brad Fitzpatrick (author) directly.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论