高併發場景下的快取有哪些常見的問題？

一、快取一致性問題

當資料時效性要求很高時，需要保證快取中的資料與資料庫中的保持一致，而且需要保證快取節點和副本中的資料也保持一致，不能出現差異現象。

這就比較依賴快取的過期和更新策略。一般會在資料發生更改的時，主動更新快取中的資料或者移除對應的快取。

二、快取併發問題

快取過期後將嘗試從後端資料庫獲取資料，這是一個看似合理的流程。但是，在高併發場景下，有可能多個請求併發的去從資料庫獲取資料，對後端資料庫造成極大的衝擊，甚至導致 “雪崩”現象。

此外，當某個快取key在被更新時，同時也可能被大量請求在獲取，這也會導致一致性的問題。那如何避免類似問題呢？

我們會想到類似“鎖”的機制，在快取更新或者過期的情況下，先嚐試獲取到鎖，當更新或者從資料庫獲取完成後再釋放鎖，其他的請求只需要犧牲一定的等待時間，即可直接從快取中繼續獲取資料。

三、快取穿透問題

快取穿透在有些地方也稱為“擊穿”。很多朋友對快取穿透的理解是：由於快取故障或者快取過期導致大量請求穿透到後端資料庫伺服器，從而對資料庫造成巨大沖擊。

這其實是一種誤解。真正的快取穿透應該是這樣的：

在高併發場景下，如果某一個key被高併發訪問，沒有被命中，出於對容錯性考慮，會嘗試去從後端資料庫中獲取，從而導致了大量請求達到資料庫，而當該key對應的資料本身就是空的情況下，這就導致資料庫中併發的去執行了很多不必要的查詢操作，從而導致巨大沖擊和壓力。

可以透過下面的幾種常用方式來避免快取傳統問題：

1、快取空物件

對查詢結果為空的物件也進行快取，如果是集合，可以快取一個空的集合（非null），如果是快取單個物件，可以透過欄位標識來區分。這樣避免請求穿透到後端資料庫。

同時，也需要保證快取資料的時效性。這種方式實現起來成本較低，比較適合命中不高，但可能被頻繁更新的資料。

2、單獨過濾處理

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

四、快取顛簸問題

快取的顛簸問題，有些地方可能被成為“快取抖動”，可以看做是一種比“雪崩”更輕微的故障，但是也會在一段時間內對系統造成衝擊和效能影響。一般是由於快取節點故障導致。業內推薦的做法是透過一致性Hash演算法來解決。

五、快取的雪崩現象

快取雪崩就是指由於快取的原因，導致大量請求到達後端資料庫，從而導致資料庫崩潰，整個系統崩潰，發生災難。

導致這種現象的原因有很多種，上面提到的“快取併發”，“快取穿透”，“快取顛簸”等問題，其實都可能會導致快取雪崩現象發生。這些問題也可能會被惡意攻擊者所利用。

還有一種情況，例如某個時間點內，系統預載入的快取週期性集中失效了，也可能會導致雪崩。為了避免這種週期性失效，可以透過設定不同的過期時間，來錯開快取過期，從而避免快取集中失效。

從應用架構角度，我們可以透過限流、降級、熔斷等手段來降低影響，也可以透過多級快取來避免這種災難。

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

六、快取無底洞現象

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

他們發現了一個問題---memcached 連線頻率，效率下降了，於是加 memcached 節點，新增了後，發現因為連線頻率導致的問題，仍然存在，並沒有好轉，稱之為”無底洞現象”。 

目前主流的資料庫、快取、Nosql、搜尋中介軟體等技術棧中，都支援“分片”技術，來滿足“高效能、高併發、高可用、可擴充套件”等要求。

有些是在client端透過Hash取模（或一致性Hash）將值對映到不同的例項上，有些是在client端透過範圍取值的方式對映的。當然，也有些是在服務端進行的。

但是，每一次操作都可能需要和不同節點進行網路通訊來完成，例項節點越多，則開銷會越大，對效能影響就越大。

主要可以從如下幾個方面避免和最佳化：

1、資料分佈方式

有些業務資料可能適合Hash分佈，而有些業務適合採用範圍分佈，這樣能夠從一定程度避免網路IO的開銷。

2、IO最佳化

可以充分利用連線池，NIO等技術來儘可能降低連線開銷，增強併發連線能力。

3、資料訪問方式

一次性獲取大的資料集，會比分多次去獲取小資料集的網路IO開銷更小。

當然，快取無底洞現象並不常見。在絕大多數的公司裡可能根本不會遇到。