Redis緩存常用4種策略原理詳解

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

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

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

Cache-Aside 策略

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

我們來(lái)看一次請(qǐng)求數(shù)據(jù)的過(guò)程：

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

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

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

Read-Through 策略

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

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

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

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

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

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。