免費訂閱，天天收到這樣的好信息私活接單qq羣：716817407
web
緩存的使用，是一個逐漸演進的過程。面試
問一下你本身，最直接的使用緩存的緣由是什麼？spring
無它，惟快而已！數據庫
追溯一下本身最開始使用緩存的場景，一些數據庫裏存儲的不變的配置信息，服務啓動時，直接加載到本地公共模塊，方便其它功能模塊共享使用。這即是最基本，最簡單的本地緩存應用。json
1、服務與緩存
所謂的服務，簡而言之，一層應用 + 一層數據，應用從數據層獲取數據而後加工輸出。後端
數據層，一般咱們指的是持久化介質上的持久化存儲。它有多種形式的，能夠是文件，或者數據庫。設計模式
數據存儲在持久化介質上，而應用運行與內存中。內存和持久化介質是兩個有着量級速度差異的不一樣介質，由此，應用和數據之間便有了「矛盾」。緩存
有了這「矛盾」的引子，便有了對緩存的迫切需求。微信
咱們說的緩存，必然要是存放於內存中的，這樣它便能距離應用更近，更快的給出應用所須要的數據，以得到更快的服務響應。mybatis
固然，並非緩存徹底隔絕持久層數據。緩存，伴隨而生的一個詞叫作命中率。
當咱們查詢的數據存在於緩存中的時候，咱們稱之爲「命中」，此時，所需數據能夠直接由緩存提供。
而對於未「命中」的數據，則須要穿過緩存層，進一步去持久化數據層獲取。此種情景，咱們稱之爲緩存穿透。
數據獲取以後，在返回給應用以前，咱們須要從新填充緩存，以供下一次「命中」查詢。
當應用發生數據操做變動，咱們則須要將變動同時更新到持久層及緩衝層。此時，咱們又會面臨另一個問題，「先」與「後」 的問題。
「先」與「後」的問題，咱們也稱之爲緩存一致性問題。
若是先更新緩存，則可能面臨持久層更新失敗，產生緩存髒數據的問題。
然則，假如先更新持久層，咱們又不得不面對從持久層更新成功以後到緩存更新以前這個間期，緩存對外提供舊數據的窘境。
緩存一致性問題，尤爲在高併發環境，須要根據特定場景進行更精妙的控制。
好比，併發修改的一致性鎖；好比，異步刷新的延遲刷新等等。
2、緩存與更新
上面咱們提到了緩存更新一致性的問題，從實際應用情景來說，能夠細分爲強一致性需求，弱一致性需求及最終一致性需求。
一、強一致性需求
好比，交易狀態信息，已下單、支付中，已支付等應用，須要咱們主動及時進行關聯更新並保證事務層面的一致性。
應景而生的許多包括分佈式事務等理論也爲咱們解決實際問題提供了很好的踐行方案。
二、弱一致性需求
一些涉及不過重要的信息更新，可以容忍短期（好比，幾分鐘）內持久層數據和緩存數據不一致的場景。好比不外顯的描述信息，統計性的計數緩存信息等。一般能夠採起異步處理的方式。
一些一段短期內（幾秒，幾分鐘）輸出固定信息的場景。好比每隔30s更新熱點信息，票價信息等。能夠經過設置緩存超時自動剔除的方式進行處理。
三、最終一致性需求
保障數據狀態的最終一致性。
3、緩存的粒度
所謂粒度，也即緩存信息塊層級，大小。選擇何種粒度的緩存，取決於咱們應用的總體架構，數據存儲規劃及具體的應用場景。
拿用戶信息來舉例，是緩存活躍信息？仍是相對靜態的信息？是按單屬性層級來緩存？仍是按整個對象信息？
不一樣的數據粒度，也決定着咱們存儲緩存的形式：整個對象的二進制序列化數據？更透明直觀的json字符串？屬性與值的一一映射？
每種形式都有各自的使用優缺點，開發者能夠從應用、存儲及維護成本各方面進行全面性評估選擇。另外，關注公衆號Java技術棧，在後臺回覆：面試，能夠獲取我整理的緩存系列面試題和答案，很是齊全。
4、緩存穿透的危害
第一小節，咱們提到過關於緩存穿透發生的緣由：緩存未命中。那爲何會未命中呢？
一、數據暫時不存在於緩存中
所謂暫時，能夠指數據初始還沒有加載到緩存，lazy load 按需按時時事加載應用；
也能夠是緩存數據被咱們特定的緩存過時策略自動或主動過時，一般使用的過時策略包括元素數量限制，內存佔用限制及生存時間限制。
其實，不管是初始未加載仍是緩存過時，刪除，這些都屬於咱們假定的正常應用場景，再次咱們不予過多評論。
二、數據歷來不存在
當一個查詢不存在數據的請求到來，其必然會穿過緩存，達到持久化存儲層。
持久話存儲的響應能力是有限的，當這種請求達到必定的量級，服務可能就要面臨着宕機的危險。
至此，咱們對於緩存的做用認知，也須要進一步延伸：下降下層負載，保護後端資源。
形成這種緩存穿透的緣由能夠簡單的分爲內外兩方面誘因：內部的應用邏輯問題及外部惡意攻擊、爬蟲干擾等。
內部問題容易解決，內觀可預知，良性優化便可；
反而是外部的不可預料，可能須要更謹慎的進行多面的防護性處理。
其實，不論內部仍是外部，在緩存層面須要處理的就只有一件事：有效攔截穿透。
到此，一般慣性的思惟第一步，就是把形成緩存穿透的數據放置到緩存中，不管其是否存在在於持久化存儲中。
好比對於正常的已刪除的用戶數據，作緩存層面的軟刪除處理，以狀態信息作標註（我存在，其實我不存在！ 😳）。就能夠很好的解決此類問題形成的穿透壓力。
可是，咱們有也個清楚的認知就，就是真正可以形成危害的是那些非正常的入侵數據。好比，窮盡遍歷的差異數據，一一存入緩存，惟一的結果就是緩存資源的溢滿用盡。這是一種至關恐怖的場景。
針對此種「大數據」型攻擊，布隆過濾攔截或許能夠成爲一個不錯的選擇。
5、也談緩存雪崩
上面一節中咱們談到了緩存的承載保護功能，一面快速響應，一面揹負保護持久層數據。
可是，若是緩存因爲某些緣由一時不能提供正常服務時，全部的請求就會穿透到持久存儲層，形成存儲層極端宕機狀況發生。
那麼，咱們應該如何應對這種狀況呢？
一、高可用
緩存的高可用是應對緩存雪崩的首要保障：主從，讀寫分離，動態擴容，一致性均衡，異地容災等。
實際應用如Redis的哨兵模式，集羣部署等。
推薦： Spring Boot 如何快速集成 Redis 哨兵？
二、服務治理之限流、熔斷降級
服務治理的目的是什麼？服務的穩定性。
限流即對異常流量的控制；熔斷、降級標的核心服務資源的保護。
筆者在輕量級熔斷降級框架 alibaba sentinel 應用介紹過當下流行的幾種流控框架的使用。
緩存、持久化數據存儲都是資源，或者咱們能夠從對緩存的流控及對持久化數據存儲的熔斷、降級保護來着手應對緩存雪崩的情景發生。
三、緩存元素的集中過時致使緩存失效
對於設置了過時時間的緩存元素，若是發生元素同時過時，則會有瞬間的外部請求直接到達持久存儲層。
在實際的緩存應用中，須要採起必定的措施，實現緩存元素過時時間的均勻分佈。另外，關注公衆號Java技術棧，在後臺回覆：面試，能夠獲取我整理的緩存系列面試題和答案，很是齊全。
2020-07-29
2020-05-12
2020-07-02
2020-07-23
2020-05-19
2020-04-23
2020-05-29
2020-08-15
2020-08-15
2020-08-14
本文分享自微信公衆號 - Java小白學心理（gh_9a909fa2fb55）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。