高併發場景下使用緩存須要注意那些問題？

1、緩存一致性問題

當數據時效性要求很高時，須要保證緩存中的數據與數據庫中的保持一致，並且須要保證緩存節點和副本中的數據也保持一致，不能出現差別現象。這就比較依賴緩存的過時和更新策略。通常會在數據發生更改的時，主動更新緩存中的數據或者移除對應的緩存。

2、緩存併發問題

緩存過時後將嘗試從後端數據庫獲取數據，這是一個看似合理的流程。可是，在高併發場景下，有可能多個請求併發的去從數據庫獲取數據，對後端數據庫形成極大的衝擊，甚至致使 「雪崩」現象。此外，當某個緩存key在被更新時，同時也可能被大量請求在獲取，這也會致使一致性的問題。那如何避免相似問題呢？咱們會想到相似「鎖」的機制，在緩存更新或者過時的狀況下，先嚐試獲取到鎖，當更新或者從數據庫獲取完成後再釋放鎖，其餘的請求只須要犧牲必定的等待時間，便可直接從緩存中繼續獲取數據。

3、緩存穿透問題

緩存穿透在有些地方也稱爲「擊穿」。不少朋友對緩存穿透的理解是：因爲緩存故障或者緩存過時致使大量請求穿透到後端數據庫服務器，從而對數據庫形成巨大沖擊。

這實際上是一種誤解。真正的緩存穿透應該是這樣的：

在高併發場景下，若是某一個key被高併發訪問，沒有被命中，出於對容錯性考慮，會嘗試去從後端數據庫中獲取，從而致使了大量請求達到數據庫，而當該key對應的數據自己就是空的狀況下，這就致使數據庫中併發的去執行了不少沒必要要的查詢操做，從而致使巨大沖擊和壓力。

能夠經過下面的幾種經常使用方式來避免緩存傳統問題：

1. 緩存空對象

對查詢結果爲空的對象也進行緩存，若是是集合，能夠緩存一個空的集合（非null），若是是緩存單個對象，能夠經過字段標識來區分。這樣避免請求穿透到後端數據庫。同時，也須要保證緩存數據的時效性。這種方式實現起來成本較低，比較適合命中不高，但可能被頻繁更新的數據。

2. 單獨過濾處理

對全部可能對應數據爲空的key進行統一的存放，並在請求前作攔截，這樣避免請求穿透到後端數據庫。這種方式實現起來相對複雜，比較適合命中不高，可是更新不頻繁的數據。

4、緩存顛簸問題

緩存的顛簸問題，有些地方可能被成爲「緩存抖動」，能夠看作是一種比「雪崩」更輕微的故障，可是也會在一段時間內對系統形成衝擊和性能影響。通常是因爲緩存節點故障致使。業內推薦的作法是經過一致性Hash算法來解決。這裏不作過多闡述，能夠參照其餘資料。

5、緩存的雪崩現象

緩存雪崩就是指因爲緩存的緣由，致使大量請求到達後端數據庫，從而致使數據庫崩潰，整個系統崩潰，發生災難。致使這種現象的緣由有不少種，上面提到的「緩存併發」，「緩存穿透」，「緩存顛簸」等問題，其實均可能會致使緩存雪崩現象發生。這些問題也可能會被惡意***者所利用。還有一種狀況，例如某個時間點內，系統預加載的緩存週期性集中失效了，也可能會致使雪崩。爲了不這種週期性失效，能夠經過設置不一樣的過時時間，來錯開緩存過時，從而避免緩存集中失效。

從應用架構角度，咱們能夠經過限流、降級、熔斷等手段來下降影響，也能夠經過多級緩存來避免這種災難。

此外，從整個研發體系流程的角度，應該增強壓力測試，儘可能模擬真實場景，儘早的暴露問題從而防範。

6、緩存無底洞現象

該問題由 facebook 的工做人員提出的， facebook 在 2010 年左右，memcached 節點就已經達3000 個，緩存數千 G 內容。

他們發現了一個問題---memcached 鏈接頻率，效率降低了，因而加 memcached 節點，添加了後，發現由於鏈接頻率致使的問題，仍然存在，並無好轉，稱之爲」無底洞現象」。

目前主流的數據庫、緩存、Nosql、搜索中間件等技術棧中，都支持「分片」技術，來知足「高性能、高併發、高可用、可擴展」等要求。有些是在client端經過Hash取模（或一致性Hash）將值映射到不一樣的實例上，有些是在client端經過範圍取值的方式映射的。固然，也有些是在服務端進行的。可是，每一次操做均可能須要和不一樣節點進行網絡通訊來完成，實例節點越多，則開銷會越大，對性能影響就越大。

主要能夠從以下幾個方面避免和優化：

1. 數據分佈方式

有些業務數據可能適合Hash分佈，而有些業務適合採用範圍分佈，這樣可以從必定程度避免網絡IO的開銷。

2. IO優化

能夠充分利用鏈接池，NIO等技術來儘量下降鏈接開銷，加強併發鏈接能力。

3. 數據訪問方式

一次性獲取大的數據集，會比分屢次去獲取小數據集的網絡IO開銷更小。

固然，緩存無底洞現象並不常見。在絕大多數的公司裏可能根本不會遇到。