快取的使用，是一個逐漸演進的過程。

問一下你自己，最直接的使用快取的原因是什麼？

無它，唯快而已！

追溯一下自己最開始使用快取的場景，一些資料庫裡儲存的不變的配置資訊，服務啟動時，直接載入到本地公共模組，方便其它功能模組共享使用。這便是最基本，最簡單的本地快取應用。

一、服務與快取

所謂的服務，簡而言之，一層應用 + 一層資料，應用從資料層獲取資料然後加工輸出。

資料層，通常我們指的是持久化介質上的持久化儲存。它有多種形式的，可以是檔案，或者資料庫。

資料儲存在持久化介質上，而應用執行與記憶體中。記憶體和持久化介質是兩個有著量級速度差別的不同介質，由此，應用和資料之間便有了“矛盾”。

有了這“矛盾”的引子，便有了對快取的迫切需求。

我們說的快取，必然要是存放於記憶體中的，這樣它便能距離應用更近，更快的給出應用所需要的資料，以獲得更快的服務響應。

當然，並不是快取完全隔絕持久層資料。快取，伴隨而生的一個詞叫做命中率。

當我們查詢的資料存在於快取中的時候，我們稱之為“命中”，此時，所需資料可以直接由快取提供。

而對於未“命中”的資料，則需要穿過快取層，進一步去持久化資料層獲取。此種情景，我們稱之為快取穿透。

資料獲取之後，在返回給應用之前，我們需要重新填充快取，以供下一次“命中”查詢。

當然，上述我們所述只是指“讀”查詢情景。

當應用發生資料操作變更，我們則需要將變更同時更新到持久層及緩衝層。此時，我們又會面臨另外一個問題，“先”與“後”的問題。

“先”與“後”的問題，我們也稱之為快取一致性問題。

如果先更新快取，則可能面臨持久層更新失敗，產生快取髒資料的問題。

然則，假如先更新持久層，我們又不得不面對從持久層更新成功之後到快取更新之前這個間期，快取對外提供舊資料的窘境。

快取一致性問題，尤其在高併發環境，需要根據特定場景進行更精妙的控制。

比如，併發修改的一致性鎖；比如，非同步重新整理的延遲重新整理等等。

二、快取與更新

上面我們提到了快取更新一致性的問題，從實際應用情景來講，可以細分為強一致性需求，弱一致性需求及最終一致性需求。

1、強一致性需求

比如，交易狀態資訊，已下單、支付中，已支付等應用，需要我們主動及時進行關聯更新並保證事務層面的一致性。

應景而生的許多包括分散式事務等理論也為我們解決實際問題提供了很好的踐行方案。

2、弱一致性需求

一些涉及不太重要的資訊更新，能夠容忍短時間（比如，幾分鐘）內持久層資料和快取資料不一致的場景。比如不外顯的描述資訊，統計性的計數快取資訊等。通常可以採取非同步處理的方式。

一些一段短時間內（幾秒，幾分鐘）輸出固定資訊的場景。比如每隔30s更新熱點資訊，票價資訊等。可以通過設定快取超時自動剔除的方式進行處理。

3、最終一致性需求

保障資料狀態的最終一致性。

三、快取的粒度

所謂粒度，也即快取資訊塊層級，大小。選擇何種粒度的快取，取決於我們應用的整體架構，資料儲存規劃及具體的應用場景。

拿使用者資訊來舉例，是快取活躍資訊？還是相對靜態的資訊？是按單屬性層級來快取？還是按整個物件資訊？

不同的資料粒度，也決定著我們儲存快取的形式：整個物件的二進位制序列化資料？更透明直觀的json字串？屬性與值的一一對映？

每種形式都有各自的使用優缺點，開發者可以從應用、儲存及維護成本各方面進行全面性評估選擇。

四、快取穿透的危害

第一小節，我們提到過關於快取穿透發生的原因：快取未命中。那為什麼會未命中呢？

1、資料暫時不存在於快取中

所謂暫時，可以指資料初始尚未載入到快取，lazy load 按需按時時事載入應用；

也可以是快取資料被我們特定的快取過期策略自動或主動過期，通常使用的過期策略包括元素數量限制，記憶體佔用限制及生存時間限制。

其實，無論是初始未載入還是快取過期，刪除，這些都屬於我們假定的正常應用場景，再次我們不予過多評論。

2、資料從來不存在

當一個查詢不存在資料的請求到來，其必然會穿過快取，達到持久化儲存層。

持久話儲存的響應能力是有限的，當這種請求達到一定的量級，服務可能就要面臨著宕機的危險。

至此，我們對於快取的作用認知，也需要進一步延伸：降低下層負載，保護後端資源。

造成這種快取穿透的原因可以簡單的分為內外兩方面誘因：內部的應用邏輯問題及外部惡意攻擊、爬蟲干擾等。

內部問題容易解決，內觀可預知，良性優化即可；

反而是外部的不可預料，可能需要更謹慎的進行多面的防禦性處理。

其實，不論內部還是外部，在快取層面需要處理的就只有一件事：有效攔截穿透。

到此，通常慣性的思維第一步，就是把造成快取穿透的資料放置到快取中，無論其是否存在在於持久化儲存中。

比如對於正常的已刪除的使用者資料，做快取層面的軟刪除處理，以狀態資訊做標註（我存在，其實我不存在！