[borlak]

I really wouldn't call this an alternative. If you are running memcached, it's very unlikely you can switch to Groupcache.

Parts of your application may rely on the expiration feature. But the biggest change is the inability to overwrite a current cache key. Every application I've used does this constantly (object updates).

Groupcache in its current form is useful for a very narrow set of applications.

[grey-area]

In Rails 4 with russian doll caching, when data or the view changes, the key changes, so rather than expiring keys, you just don't use them again. So you have no real need for expiry or overwrites, as when data changes, the key changes with it (I think they use the object modified date + hash of view template). As far as I can see groupcache would be compatible with that caching scheme, or others like it.

The only bit which could be tricky is if you want to clear the cache, I don't see a way of doing that from a quick look at the API. But to clear the cache you could have a special version key hashed into each key whose sole purpose is to empty the cache, which you bump whenever you want to remove all keys at once for whatever reason (in a perfect world, this shouldn't be necessary of course).

[steveklabnik]

The intention with Russian doll caching is that the cache uses LRU, so you don't need to worry about clearing the cache. No poison pill needed. Memcache operates this way.

Given that there's an 'lru' folder with a package that says 'implements a LRU cache' as the first comment, I assume this works that way as well.

[arscan]

I would think that the real limiting factor right now is that it is only available for Go applications (its a Go library, not a standalone server). There are comparably very few Go applications in the wild that could use this... where a memcached server can interface with just about anything. Or am I missing something?

[drbawb]

Groupcache being a library is what made me so excited about it in the first place.

I'm writing a torrent tracker in Go that could make great use of a distributed cache. This would enable you to put an arbitrary number of "tracker nodes" behind a load-balancer.

One of the goals of my project is that its easy to configure: everything except the RDBMS is hosted inside a single binary and configured with a single file. In the simplest case: that binary is responsible for two web-servers, a process-local cache, and a DB connection pool. (In more complex cases, each binary simply acts as another node behind a load-balancer; and they attempt to cooperate together.)

It's useful to avoid hitting the disk by having the tracker cache torrents that are active. When you start adding more tracker nodes, this is where having a distributed cache would be nice.

Without groupcache, that means I've just forced my users to install and configure memcached. With groupcache, the configuration and server are simply part of my application. (As an added bonus, since Go is statically linked, I haven't even added any external dependencies on shared libraries.)

---

I agree that the use-cases for groupcache are far more limited in scope, but I was still glad to hear that this was a library, and not a standalone server. I think we need _more_ distributed caches implemented as libraries, not less.

There are many use-cases where it may not be preferable to have a separate caching server. In my career: getting approval to install memcached on a customer's server could add _weeks_ to our deploy time simply because of red-tape; in my personal programming endeavors: setting up memcached is just an added layer of complexity that could easily be avoided by using libraries instead of servers.

I'd argue that we should leave memcached [more specifically: standalone distributed caches] for the more complicated scenarios where a dedicated solution is called for. Bring on the distributed-cache libraries where a much simpler, ad-hoc solution would be more beneficial to end-users.

[gohrt]

I suppose you could write a small Go app to use the groupcache library, and call that Go app from your non-Go app co-located on the same machine.

[JulianMorrison]

So your key is key + transaction ID, where the transaction ID is simply a value that changes when the data changes. You search the cache with the current value of the ID, and if the data changed the cache entry will be regenerated.

An example of a good transaction ID would be SHA1(data).

[happyhappy]

Values that must expire could perhaps use a truncated time value as part of the key? It's not as flexible as regular expiration, because the entries would only expire when you cross the point in time where the truncated time value changes, which could be a problem in a lot of applications (sudden surges of requests every x seconds)