我們都知道，提高系統(tǒng)性能的最簡單也最流行的方法之一其實就是使用緩存。我們引入緩存，相當于對數(shù)據(jù)進行了復制。每當系統(tǒng)數(shù)據(jù)更新時，保持緩存和數(shù)據(jù)源（如 MySQL 數(shù)據(jù)庫）同步至關重要，當然，這也取決于系統(tǒng)本身的要求，看系統(tǒng)是否允許一定的數(shù)據(jù)延遲。

最常見的幾種緩存策略、它們的優(yōu)缺點以及使用場景，分別是：

• Cache-Aside
• Read-Through
• Write-Through
• Write-Behind

Cache-Aside 策略

Cache-Aside可能是最常用的緩存策略。在這種策略下，應用程序(Application)會與緩存(Cache)和數(shù)據(jù)源(Data Source)進行通信，應用程序會在命中數(shù)據(jù)源之前先檢查緩存。如下圖所示：

我們來看一次請求數(shù)據(jù)的過程：

• 首先，應用程序先確定數(shù)據(jù)是否保留在緩存中；
• 如果數(shù)據(jù)在緩存中，也即 Cache hit ，稱作“緩存命中”。數(shù)據(jù)直接從緩存中讀取并返回給客戶端應用程序；
• 如果數(shù)據(jù)不在緩存中，也即 Cache miss，稱作“緩存未命中”。應用程序會從數(shù)據(jù)存儲的地方，如 MySQL 數(shù)據(jù)源中讀取該數(shù)據(jù)，并將數(shù)據(jù)存儲在緩存中，然后將其返回給客戶端。

Cache-Aside策略特別適合“讀多”的應用場景。使用Cache Aside策略的系統(tǒng)可以在一定程度上抵抗緩存故障。如果緩存服務發(fā)生故障，系統(tǒng)仍然可以通過直接訪問數(shù)據(jù)庫進行操作。

然而，這種策略并不能保證數(shù)據(jù)存儲和緩存之間的一致性，需要配合使用其它策略來更新或使緩存無效。另外，首次請求數(shù)據(jù)時，總是會導致緩存未命中，這種情況下需要額外的時間來將數(shù)據(jù)加載到緩存中。為了解決這個問題，開發(fā)人員可以通過手動觸發(fā)查詢操作來對數(shù)據(jù)進行“預熱”。

Read-Through 策略

在上面的Cache-Aside策略中，應用程序需要與緩存和數(shù)據(jù)源“打交道”，而在Read-Through策略下，應用程序無需管理數(shù)據(jù)源和緩存，只需要將數(shù)據(jù)源的同步委托給緩存提供程序Cache Provider即可。所有數(shù)據(jù)交互都是通過抽象緩存層完成的。

在進行大量讀取時，Read-Through可以減少數(shù)據(jù)源上的負載，也對緩存服務的故障具備一定的彈性。如果緩存服務掛了，則緩存提供程序仍然可以通過直接轉到數(shù)據(jù)源來進行操作。

然而，首次請求數(shù)據(jù)時，總是會導致緩存未命中，并需要額外的時間來將數(shù)據(jù)加載到緩存中，相信大家都知道怎么處理了吧，還是“緩存預熱”的老套路。

Read-Through適用于多次請求相同數(shù)據(jù)的場景。這與Cache-Aside策略非常相似，但是二者還是存在一些差別，這里再次強調一下：

• 在Cache-Aside中，應用程序負責從數(shù)據(jù)源中獲取數(shù)據(jù)并更新到緩存。
• 而在Read-Through中，此邏輯通常是由獨立的緩存提供程序支持。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論