Access patterns
Last updated
Was this helpful?
Last updated
Was this helpful?
Doing nothing special when using cache. Treat the database and cache as independent data sources.
First write DB, then cache; read from cache, then DB.
Most widely used pattern in distributed applications. Popular cache frameworks such as Redis / Memcached opt this approach by default.
Data inconsistency could happen in multiple cases:
Two parallel write
One read and one write
Possible solution: Add one delayed delete after the immediate delete
Since the second delete is scheduled a bit long after the first one, setting cache operation should already be eliminated.
In read path, cache will act on behalf of client; on write path, it is the same as cache aside.
Since it shares the same write path as cache aside, it has the same data inconsistency issue with cache aside.
For the step to update cache, put it in an asynchronous job. This step will only improve the perf a lot when the cached item is large.
In the read path, it is the same as cache aside; in the write path, cache will act on behalf of client.
It has similar problem.
For the step to update cache, put it in an asynchronous job. This step will only improve the perf a lot when the cached item is large.
Suitable for high read & write throughput system. Used more often in operating system's write to cache
Linux page cache algorithm
Asynchronously write message to disk in message queue
When updating data, only update cache. When cache keys expire, these entries will be persisted to DB.
This pattern could greatly reduce the inconsistency problem if handled properly.
When there is no data in DB, then cache is source of truth
When there is data in DB, as long as SETNX is used, the "write back" operation on read path will not result in cache & DB inconsistency.
SETNX: Set if not exist
Update cache if there is no entry
Skip is there is already an entry
Since the application writes only to the caching service, it does not need to wait till data is written to the underlying data source. Read and write both happens at the caching side. Thus it improves performance.
If cache suddenly crashes, then the data cached inside will all be lost.
This pattern is actually similar to write back. But it writes to DB instead of cache, and it will watch DB binlog for updating cache.
Please refer to the SETNX solution in "Write back" approach.
Please refer to the explanation in "Write back" approach.
Requires an additional components for watch binlogs
