Update Cache Design Pattern

Cache aside Pattern
Read through Pattern
Write through Pattern
Write Back/ Write Behind Pattern

Cache Aside Pattern / Lazy-load

Refer to https://swsmile.info/post/cache-aside/

Read Through Pattern

Refer to https://swsmile.info/post/cache-read-through/

Writing Pattern

When a system writes data to cache, it must at some point write that data to the backing store as well. The timing of this write is controlled by what is known as the write policy. There are two basic writing approaches:

Write-through: write is done synchronously both to the cache and to the backing store.
Write-back (also called write-behind): initially, writing is done only to the cache. The write to the backing store is postponed until the modified content is about to be replaced by another cache block.

Write Through Pattern

Refer to https://swsmile.info/post/cache-write-through/

Write Back / Write Behind Pattern

Refer to https://swsmile.info/post/cache-write-behind/

Cache Invalidation

When a write operation is observed to a location that a cache has a copy of, the cache controller invalidates its own copy of the snooped memory location, which forces a read from main data source (e.g., DB) of the new value on its next access.

Refresh Ahead Caching / Cronjob Fresh

In the Refresh-Ahead scenario, Coherence allows a developer to configure a cache to automatically and asynchronously reload (refresh) any recently accessed cache entry from the cache loader before its expiration.

The result is that after a frequently accessed entry has entered the cache, the application will not feel the impact of a read against a potentially slow cache store when the entry is reloaded due to expiration. The asynchronous refresh is only triggered when an object that is sufficiently close to its expiration time is accessed—if the object is accessed after its expiration time, Coherence will perform a synchronous read from the cache store to refresh its value.

The refresh-ahead time could be expressed as a percentage of the entry’s expiration time. For example, assume that the expiration time for entries in the cache is set to 60 seconds and the refresh-ahead factor is set to 0.5. If the cached object is accessed after 60 seconds, Coherence will perform a synchronous read from the cache store to refresh its value. However, if a request is performed for an entry that is more than 30 but less than 60 seconds old, the current value in the cache is returned and Coherence schedules an asynchronous reload from the cache store.

Refresh-ahead is especially useful if objects are being accessed by a large number of users. Values remain fresh in the cache and the latency that could result from excessive reloads from the cache store is avoided.

Advantages:

It’s useful when large number of users are using the same cache keys. Since the data is refreshed periodically & frequently, staleness of data is not a permanent problem.
Reduced latency than other technique like Read Through cache.

Disadvantages:

Probably a little hard to implement since cache service takes extra pressure to refresh all the keys as and when they are accessed. But in a read heavy environment, it’s worth it.

Pre-warm

The data is loaded into cache in advance at the time point that the no traffic comes to read the cache and about to come. So that when the read traffic comes to cache, cache is alwasy hit and thus low latency.

Misc

Time to live (TTL)

Lazy loading allows for stale data but doesn’t fail with empty nodes. Write-through ensures that data is always fresh, but can fail with empty nodes and can populate the cache with superfluous data. By adding a time to live (TTL) value to each write, you can have the advantages of each strategy. At the same time, you can and largely avoid cluttering up the cache with extra data.

Time to live (TTL) is an integer value that specifies the number of seconds until the key expires. Memcached specifies this value in seconds. When an application attempts to read an expired key, it is treated as though the key is not found. The database is queried for the key and the cache is updated. This approach doesn’t guarantee that a value isn’t stale. However, it keeps data from getting too stale and requires that values in the cache are occasionally refreshed from the database.

【Cache System】缓存更新策略