we (box) do not put version information as part of key. instead we store it
as part of value:
{
cache_version : int
db_version : int
value : object
}
this allows end systems make decision with different versions in flight.
E.g. if you embed version in a key and it is possible that two different
version of service (experimental and prod) use different cache. This is
cache inconsistency. With our approach it will never happen - only one(*)
version is cached. This can cause cache trashing of course but with
additional handling even this can be handled.
again, it depens on your needs. it is still not clear what invalidate you
mean. different "schema" or stale object? My comment above is about first.
For second we use simply deletes (our ORM is responsible for the links and
we can detect what to delete). I still playing with using versioning for
second but do not want to use version as part of the key (due cache
consistency issue).
Redis has "hash" structure that allows to implement "tag" (i saw many
attempts for tagging in memcached but none robust for distributed
configuration). But after conversation with Instagram people and own
experiments not convinced to move main cache to Redis (we have 200+K ops
per second per server). Now evaluating to move sessions to it due more
convenient replication and lower load.
hope this can be interesting
On Sunday, July 13, 2014 3:03:53 PM UTC-7, John Anderson wrote:
>
> We have a bunch of microservices that manage their own cache keys and
> sometimes when they release they need to invalidate a bunch of their old
> cache keys at once. Prior to using memcached we were using redis as a
> cache and we just ran a single redis server per service so we would just
> flush all. Now that we are on a memcached cluster this is no longer
> acceptable.
>
> I'm wondering what the best practices for this is? Do you prefix cache
> keys with <service>.<version> so that when a new version comes out they
> automatically get ignored and LRU'd? Or is there a way to scan through the
> servers/slabs and find the keys we want to kick out?
>
> Thanks,
> John
>
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
