緩存的使用，是一個逐漸演進的過程。問一下你自己，最直接的使用緩存的原因是什么?無它，唯快而已!

[[340376]]
圖片來自 Pexels

 

追溯一下自己最開始使用緩存的場景，一些數(shù)據(jù)庫里存儲的不變的配置信息，服務啟動時，直接加載到本地公共模塊，方便其它功能模塊共享使用。這便是最基本，最簡單的本地緩存應用。

服務與緩存

所謂的服務，簡而言之，一層應用+一層數(shù)據(jù)，應用從數(shù)據(jù)層獲取數(shù)據(jù)然后加工輸出。

數(shù)據(jù)層，通常我們指的是持久化介質上的持久化存儲。它有多種形式的，可以是文件，或者數(shù)據(jù)庫。

數(shù)據(jù)存儲在持久化介質上，而應用運行與內(nèi)存中。內(nèi)存和持久化介質是兩個有著量級速度差別的不同介質，由此，應用和數(shù)據(jù)之間便有了“矛盾”。

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

我們說的緩存，必然要是存放于內(nèi)存中的，這樣它便能距離應用更近，更快的給出應用所需要的數(shù)據(jù)，以獲得更快的服務響應。

 

當然，并不是緩存完全隔絕持久層數(shù)據(jù)。緩存，伴隨而生的一個詞叫做命中率。

當我們查詢的數(shù)據(jù)存在于緩存中的時候，我們稱之為“命中”，此時，所需數(shù)據(jù)可以直接由緩存提供。

而對于未“命中”的數(shù)據(jù)，則需要穿過緩存層，進一步去持久化數(shù)據(jù)層獲取。此種情景，我們稱之為緩存穿透。

數(shù)據(jù)獲取之后，在返回給應用之前，我們需要重新填充緩存，以供下一次“命中”查詢。

當然，上述我們所述只是指“讀”查詢情景。當應用發(fā)生數(shù)據(jù)操作變更，我們則需要將變更同時更新到持久層及緩沖層。

此時，我們又會面臨另外一個問題，“先”與“后”的問題。

 

“先”與“后”的問題，我們也稱之為緩存一致性問題。如果先更新緩存，則可能面臨持久層更新失敗，產(chǎn)生緩存臟數(shù)據(jù)的問題。

然則，假如先更新持久層，我們又不得不面對從持久層更新成功之后到緩存更新之前這個間期，緩存對外提供舊數(shù)據(jù)的窘境。

緩存一致性問題，尤其在高并發(fā)環(huán)境，需要根據(jù)特定場景進行更精妙的控制。比如，并發(fā)修改的一致性鎖;比如，異步刷新的延遲刷新等等。

緩存與更新

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

強一致性需求

比如，交易狀態(tài)信息，已下單、支付中，已支付等應用，需要我們主動及時進行關聯(lián)更新并保證事務層面的一致性。

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

弱一致性需求

一些涉及不太重要的信息更新，能夠容忍短時間(比如，幾分鐘)內(nèi)持久層數(shù)據(jù)和緩存數(shù)據(jù)不一致的場景。

比如不外顯的描述信息，統(tǒng)計性的計數(shù)緩存信息等。通?？梢圆扇‘惒教幚淼姆绞?。

一些一段短時間內(nèi)(幾秒，幾分鐘)輸出固定信息的場景。比如每隔 30s 更新熱點信息，票價信息等。可以通過設置緩存超時自動剔除的方式進行處理。

最終一致性需求

保障數(shù)據(jù)狀態(tài)的最終一致性。

緩存的粒度

所謂粒度，也即緩存信息塊層級，大小。選擇何種粒度的緩存，取決于我們應用的整體架構，數(shù)據(jù)存儲規(guī)劃及具體的應用場景。

拿用戶信息來舉例，是緩存活躍信息?還是相對靜態(tài)的信息?是按單屬性層級來緩存?還是按整個對象信息?

不同的數(shù)據(jù)粒度，也決定著我們存儲緩存的形式：整個對象的二進制序列化數(shù)據(jù)?更透明直觀的 json 字符串?屬性與值的一一映射?

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

緩存穿透的危害

前面我們提到過關于緩存穿透發(fā)生的原因：緩存未命中。那為什么會未命中呢?

數(shù)據(jù)暫時不存在于緩存中

所謂暫時，可以指數(shù)據(jù)初始尚未加載到緩存，lazy load 按需按時實時加載應用。

也可以是緩存數(shù)據(jù)被我們特定的緩存過期策略自動或主動過期，通常使用的過期策略包括元素數(shù)量限制，內(nèi)存占用限制及生存時間限制。

 

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

數(shù)據(jù)從來不存在

當一個查詢不存在數(shù)據(jù)的請求到來，其必然會穿過緩存，達到持久化存儲層。

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

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

 

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

內(nèi)部問題容易解決，內(nèi)觀可預知，良性優(yōu)化即可;反而是外部的不可預料，可能需要更謹慎的進行多面的防御性處理。

其實，不論內(nèi)部還是外部，在緩存層面需要處理的就只有一件事：有效攔截穿透。

到此，通常慣性的思維第一步，就是把造成緩存穿透的數(shù)據(jù)放置到緩存中，無論其是否存在在于持久化存儲中。

比如對于正常的已刪除的用戶數(shù)據(jù)，做緩存層面的軟刪除處理，以狀態(tài)信息做標注(我存在，其實我不存在!😳)。就可以很好的解決此類問題造成的穿透壓力。

但是，我們有也個清楚的認知就，就是真正能夠造成危害的是那些非正常的入侵數(shù)據(jù)。

比如，窮盡遍歷的差別數(shù)據(jù)，一一存入緩存，唯一的結果就是緩存資源的溢滿用盡。這是一種相當恐怖的場景。

針對此種“大數(shù)據(jù)”型攻擊，布隆過濾攔截或許可以成為一個不錯的選擇。

 

也談緩存雪崩

上面一節(jié)中我們談到了緩存的承載保護功能，一面快速響應，一面背負保護持久層數(shù)據(jù)。在某些以讀為主的服務中，緩存幾近承載近乎 90% 以上的請求。

但是，如果緩存由于某些原因一時不能提供正常服務時，所有的請求就會穿透到持久存儲層，造成存儲層極端宕機情況發(fā)生。

 

那么，我們應該如何應對這種情況呢?

高可用

緩存的高可用是應對緩存雪崩的首要保障：主從，讀寫分離，動態(tài)擴容，一致性均衡，異地容災等。

實際應用如 Redis 的哨兵模式，集群部署等：

 

服務治理之限流、熔斷降級

服務治理的目的是什么?服務的穩(wěn)定性。限流即對異常流量的控制;熔斷、降級標的核心服務資源的保護。

緩存、持久化數(shù)據(jù)存儲都是資源，或者我們可以從對緩存的流控及對持久化數(shù)據(jù)存儲的熔斷、降級保護來著手應對緩存雪崩的情景發(fā)生。

 

緩存元素的集中過期導致緩存失效

對于設置了過期時間的緩存元素，如果發(fā)生元素同時過期，則會有瞬間的外部請求直接到達持久存儲層。

在實際的緩存應用中，需要采取一定的措施，實現(xiàn)緩存元素過期時間的均勻分布。

作者：WindWant

編輯：陶家龍

出處：cnblogs.com/niejunlei/p/12914336.html