【Cache System】缓存更新策略 - Read Through

Posted by 西维蜀黍 on 2021-08-05, Last Modified on 2022-12-10

Read Through Pattern

在上面的Cache Aside套路中,我们的应用代码需要维护两个数据存储,一个是缓存(Cache),一个是数据库(Repository)。

Read Through 套路就是在查询操作中更新缓存,也就是说,当缓存失效的时候(过期或LRU换出),Cache Aside是由调用方负责把数据加载入缓存,而Read Through则用缓存服务(composite 存储)自己来加载,从而对应用方是透明的。

When there is a cache miss, it loads missing data from database, populates the cache and returns it to the application.

![read-through](assets/post 2021-08-05 15-47-21.png)

可以理解为,应用认为后端就是一个单一的 composite 存储,而 composite 存储自己维护自己的Cache,因此这个缓存机制对调用方来说是透明的。

![Downloads 2021-08-05 14-00-18](assets/Downloads 2021-08-05 14-00-18.png)

Read-through VS Cache-aside

While read-through and cache-aside are very similar, there are at least two key differences:

  1. In cache-aside, the application is responsible for fetching data from the database and populating the cache. In read-through, this logic is usually supported by the library or stand-alone cache provider (which means that the internal storage components are transparent to the clients/callers and what they can perceive is one single storage).
  2. Unlike cache-aside, the data model in read-through cache cannot be different than that of the database.


Read-through caches work best for read-heavy workloads when the same data is requested many times.


Cache Miss Penalty

The disadvantage is that when the data is requested the first time, it always results in cache miss and incurs the extra penalty of loading data to the cache.

Developers deal with this by warming (pre-heating) the cache or Refresh Ahead Caching.

Stale Data

Just like cache-aside, it is also possible for data to become inconsistent between cache and the database, and solution lies in the write strategy

To address this issue, you can use cache update mechanisms (e.g., Write-through), update invalidation mechanisms, or Adding TTL.