This is really interesting. On the one hand, it seems like this should be the client's concern. It feels "wrong" to have the server keep track of what's effectively client-side state and need to...
This is really interesting. On the one hand, it seems like this should be the client's concern. It feels "wrong" to have the server keep track of what's effectively client-side state and need to do work to keep the clients updated whenever anything happens that they might care about.
But on the other hand, it also massively simplifies cache invalidation, which is a really difficult problem (one of the only two, as a famous saying goes). There's simply no way to do cache invalidation as reliably and elegantly without having the server involved like this.
I'm not totally sure what I think about it yet, but I think it's a fascinating idea and I'm glad to see someone trying it.
From what I've gathered from antirez's posts on HN, this sort of client-side caching is something almost everyone with very large (100GB+ range) Redis instances ends up building for themselves. At...
From what I've gathered from antirez's posts on HN, this sort of client-side caching is something almost everyone with very large (100GB+ range) Redis instances ends up building for themselves. At that sort of scale it seems like an obvious win to let each client have 1GB or whatever of local cache that it can consult without a network roundtrip.
That means they're dealing with not just cache invalidation but the same sort of cache consistency protocols that CPUs have to handle for their cache hierarchy. Possibly the only thing harder than cache invalidation is multi-tier cache invalidation across a distributed system, so this seems like a good thing to try to bake into the core of Redis as one "right way to do it" instead of having each user try to duct-tape on their own bespoke cache invalidation logic using pubsub or whatever.
This is really interesting. On the one hand, it seems like this should be the client's concern. It feels "wrong" to have the server keep track of what's effectively client-side state and need to do work to keep the clients updated whenever anything happens that they might care about.
But on the other hand, it also massively simplifies cache invalidation, which is a really difficult problem (one of the only two, as a famous saying goes). There's simply no way to do cache invalidation as reliably and elegantly without having the server involved like this.
I'm not totally sure what I think about it yet, but I think it's a fascinating idea and I'm glad to see someone trying it.
From what I've gathered from antirez's posts on HN, this sort of client-side caching is something almost everyone with very large (100GB+ range) Redis instances ends up building for themselves. At that sort of scale it seems like an obvious win to let each client have 1GB or whatever of local cache that it can consult without a network roundtrip.
That means they're dealing with not just cache invalidation but the same sort of cache consistency protocols that CPUs have to handle for their cache hierarchy. Possibly the only thing harder than cache invalidation is multi-tier cache invalidation across a distributed system, so this seems like a good thing to try to bake into the core of Redis as one "right way to do it" instead of having each user try to duct-tape on their own bespoke cache invalidation logic using pubsub or whatever.