Design a Distributed Cache (Memcache), stage 1 of 9: model
How a look-aside cache behaves
Reads: get from the cache; on a miss, query MySQL and set the result. Writes: update MySQL, then do something about the cached copy.
System so far· 5 parts
Select a component to see what it is responsible for and which state it owns.
- 1Users → Web servers: Page request
- 2Web servers → mcrouter: get / multiget, delete
- 3mcrouter → memcached pool: Keys by consistent hash
- 4Web servers → MySQL: Query on miss; writes
What you need to know
A look-aside (or cache-aside) cache sits next to the database, not in front of it. The application does the work:
- Read: ask the cache. On a hit, done. On a miss, query the database and put the result in the cache.
- Write: update the database, then deal with the cached copy.
The cache never talks to the database itself. It's a disposable copy the application manages. See Caching.
Work it out
The cache serves 1,000,000 reads a second with a 99% hit rate. How many reads a second reach the database?Check
The hit rate drops from 99% to 98%. What happens to database load?On write, there are two options for the cached copy: set the new value, or delete the key and let the next read refill it.
Deletes are idempotent (doing it twice is the same as once) and order-insensitive (two deletes in either order leave the same result). Two sets racing can arrive in the wrong order and leave the older value cached.