我們都知道，提高系統性能的最簡單也最流行的方法之一其實就是使用快取。我們引入快取，相當於對資料進行了複製。每當系統資料更新時，保持快取和資料來源（如 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中，此邏輯通常是由獨立的快取提供程式支援。