我們都知道，提高系統性能的最簡單也最流行的方法之一其實就是使用緩存。我們引入緩存，相當于對數據進行了復制。每當系統數據更新時，保持緩存和數據源（如 MySQL 數據庫）同步至關重要，當然，這也取決于系統本身的要求，看系統是否允許一定的數據延遲。
最常見的幾種緩存策略、它們的優缺點以及使用場景，分別是：
- Cache-Aside
- Read-Through
- Write-Through
- Write-Behind
Cache-Aside 策略
Cache-Aside可能是最常用的緩存策略。在這種策略下，應用程序(Application)會與緩存(Cache)和數據源(Data Source)進行通信，應用程序會在命中數據源之前先檢查緩存。如下圖所示：
我們來看一次請求數據的過程：
- 首先，應用程序先確定數據是否保留在緩存中；
- 如果數據在緩存中，也即 Cache hit ，稱作“緩存命中”。數據直接從緩存中讀取并返回給客戶端應用程序；
- 如果數據不在緩存中，也即 Cache miss，稱作“緩存未命中”。應用程序會從數據存儲的地方，如 MySQL 數據源中讀取該數據，并將數據存儲在緩存中，然后將其返回給客戶端。
Cache-Aside策略特別適合“讀多”的應用場景。使用Cache Aside策略的系統可以在一定程度上抵抗緩存故障。如果緩存服務發生故障，系統仍然可以通過直接訪問數據庫進行操作。
然而，這種策略并不能保證數據存儲和緩存之間的一致性，需要配合使用其它策略來更新或使緩存無效。另外，首次請求數據時，總是會導致緩存未命中，這種情況下需要額外的時間來將數據加載到緩存中。為了解決這個問題，開發人員可以通過手動觸發查詢操作來對數據進行“預熱”。
Read-Through 策略
在上面的Cache-Aside策略中，應用程序需要與緩存和數據源“打交道”，而在Read-Through策略下，應用程序無需管理數據源和緩存，只需要將數據源的同步委托給緩存提供程序Cache Provider即可。所有數據交互都是通過抽象緩存層完成的。
在進行大量讀取時，Read-Through可以減少數據源上的負載，也對緩存服務的故障具備一定的彈性。如果緩存服務掛了，則緩存提供程序仍然可以通過直接轉到數據源來進行操作。
然而，首次請求數據時，總是會導致緩存未命中，并需要額外的時間來將數據加載到緩存中，相信大家都知道怎么處理了吧，還是“緩存預熱”的老套路。
Read-Through適用于多次請求相同數據的場景。這與Cache-Aside策略非常相似，但是二者還是存在一些差別，這里再次強調一下：
- 在Cache-Aside中，應用程序負責從數據源中獲取數據并更新到緩存。
- 而在Read-Through中，此邏輯通常是由獨立的緩存提供程序支持。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：https://www.cnblogs.com/tracydzf/p/13328167.html
