Cache-Aside模式一種常用的緩存方式，通常是把數據從主存儲加載到KV緩存中，加速后續的訪問。在存在重復度的場景，Cache-Aside可以提升服務性能，降低底層存儲的壓力，缺點是緩存和底層存儲會存在不一致。

業務場景和面臨問題

在開發應用時，使用緩存被多次訪問的數據是常見的操作。但是，緩存和底層存儲的數據完全一致是一種不切實際的想法。我們需要一種策略，來保證緩存里的數據盡量及時更新，同時也要能夠檢測并應對緩存數據過期的情況。

解決方案

很多商業化的緩存訪問提供了 read-throgh 和write-through/write-behind 的操作。這種模式下，讀寫都要先經過緩存，操作流程是這樣的：

• 讀取數據：如果緩存miss，應用層就從底層存儲讀取數據，然后寫入緩存。
• 更新數據：涉及數據修改時，直接修改緩存里的數據即可，緩存服務會自動將修改同步到底層存儲。

如果緩存不提供數據同步能力，應用層就要負責數據在緩存和底層存儲的同步。

使用cache-aside策略，應用層能夠模擬read-through緩存的能力。這種策略會要求應用層按需把數據加載進緩存，下圖給出了存儲數據的過程：

如果應用層更新了數據，就可以采用write-through策略。做法也比較簡單：1）修改底層存儲的數據；2）將緩存里的這條數據置為失效（刪除/過期）。

下一次這條數據被請求時，使用cache-aside策略：1）應用層從底層存儲獲取更新后的數據；2）寫入緩存。

存在問題和注意事項

在此用這個模式時，需要考慮以下幾點：

緩存數據的生命周期。很多緩存實現方案會設置過期時間，如果數據在一段時間內沒有被訪問，緩存中置為失效并逐出這條數據。為了保證cache-aside模式有效，需要保證緩存失效機制與數據的訪問模式是一致的。如果緩存失效時間太短，可能會導致應用層反復從底層存儲獲取數據寫入緩存。如果緩存過期時間太長，緩存的數據很可能是過期的，與底層存儲不一致。對于半靜態的數據（更新頻次低）或讀取頻繁的數據進行緩存，能達到最好的效果。

逐出數據。相對于底層存儲，緩存的容量一般是有限的，必須要是需要逐出數據。很多緩存采用LRU機制，當然我們也可以自己定制逐出機制。通常為了保證緩存的性價比，所有數據都會被配置一個全局的緩存過期屬性。有個別例外的情況，比如從底層存儲中獲取一份數據項效率非常低（讀取頻率一般），另一份數據項從底層存儲獲取效率高（讀取頻率也高），那么緩存獲取效率低的數據收益可能更大。

服務啟動時填充緩存。一些場景下，服務啟動時，會把存量數據加載到緩存里。這種情況下如果有數據過期或被逐出的情況，同樣可以采用cache-aside模式。

數據一致性。cache-aside模式并不能保證緩存和底層存儲的數據一致性。存儲里的數據任何時候都可能被更改，如果是外部服務，緩存可能感知不到數據更新。如果一個系統中，多個存儲都存了數據的備份，頻繁發生數據同步的情況下，數據不一致的情況會更嚴重。

本地緩存，也叫內存緩存。數據緩存在服務實例的內存中，是有該實例能訪問。如果服務實例頻繁訪問同樣的數據，也可以使用Cache-Aside模式。但是本地緩存是允許本服務實例訪問，不同的服務實例都在本地內存存儲了一份數據。不同實例的緩存很快變得不一致，這就需要更頻繁地刷新緩存中的數據。在這類場景中，可以考慮使用分片或分布式緩存方案。

應用場景

適用場景：

• 緩存并不提供原生的 read-through 或 write-through 的能力。
• 資源需求無法預估的場景。cache-aside模式允許應用按需加載數據到緩存，不需要提前對數據的需求量進行評估。

不適用場景：

• 緩存數據是靜態的。如果緩存空間能容納這些數據，可以在服務啟動時填充緩存，并采用一些策略避免其過期。
• Web農場托管的大量Web應用，如果Web應用支持親和性調度（client傾向于找上次服務過的server），client/server之間盡量不要引入額外依賴，比如session信息緩存。