摘要：高并發環境下構建快取服務需要注意哪些問題？
本文分享自華為云社區《【高并發】高并發環境下構建快取服務需要注意哪些問題？》，作者：冰 河，
快取特征
（1）命中率：命中數/(命中數+沒有命中數)
（2）最大元素（空間）：代表快取中可以存放的最大元素的數量，一旦快取中元素的數量超過這個值，或者快取資料所占的空間超過了最大支持的空間，將會觸發快取清空策略，根據不同的場景，合理設定最大元素（空間）的值，在一定程度上可以提高快取的命中率，從而更有效的使用快取，
（3）清空策略：FINO（先進先出）、LFU（最少使用）、LRU（最近最少使用）、過期時間、隨機等，
- FINO（先進先出）：最先進入快取的資料，在快取空間不夠或超出最大元素限制的情況下，會優先被清除掉，以騰出新的空間來接收新的資料，這種策略的演算法主要是比較快取元素的創建時間，在資料實時性較高的場景下，可以選擇這種策略，優先保證最新策略可用，
- LFU（最少使用）：無論元素是否過期，根據元素的被使用次數來判斷，清除使用次數最少的元素來釋放空間，演算法主要是比較元素的命中次數，在保證高頻資料有效的場景下，可以選擇這種策略，
- LRU（最近最少使用）：無論元素是否過期，根據元素最后一次被使用的時間戳，清除最遠使用時間戳的元素，釋放空間，演算法主要是比較元素最近一次被獲取的時間，在熱點資料場景下，可以選擇這種策略，
過期時間：根據過期時間判斷，清理過期時間最長的元素，或者清理最近要過期的元素，
快取命中率影響因素
（1）業務場景和業務需求
快取往往適合讀多寫少的場景，業務需求對實時性的要求，直接會影響到快取的過期時間和更新策略，實時性要求越低，就越適合快取，在相同Key和相同請求數的情況下，快取的時間越長，命中率就會越高，
（2）快取的設計（粒度和策略）
通常情況下，快取的粒度越小，命中率越高，快取的更新和命中策略也會影響快取的命中率，當資料發生變化時，直接更新快取的值會比移除快取或使快取過期的命中率更高，
（3）快取容量和基礎設施
快取的容量有限，則容易引起快取失效和被淘汰（目前多數的快取框架或中間件都采用了LRU演算法），同時，快取的技術選型也是至關重要的，比如采用應用內置的本地快取就比較容易出現單機瓶頸，而采用分布式快取則畢竟容易擴展，所以需要做好系統容量規劃，并考慮是否可擴展，此外，不同的快取框架或中間件，其效率和穩定性也是存在差異的，
（4）其他因素
當快取節點發生故障時，需要避免快取失效并最大程度降低影響，這種特殊情況也是架構師需要考慮的，業內比較典型的做法就是通過一致性Hash演算法，或者通過節點冗余的方式，
有些朋友可能會有這樣的理解誤區：既然業務需求對資料時效性要求很高，而快取時間又會影響到快取命中率，那么系統就別使用快取了，其實這忽略了一個重要因素–并發，通常來講，在相同快取時間和key的情況下，并發越高，快取的收益會越高，即便快取時間很短，
提高快取命中率的方法
從架構師的角度，需要應用盡可能的通過快取直接獲取資料，并避免快取失效，這也是比較考驗架構師能力的，需要在業務需求，快取粒度，快取策略，技術選型等各個方面去通盤考慮并做權衡，盡可能的聚焦在高頻訪問且時效性要求不高的熱點業務上，通過快取預加載（預熱）、增加存盤容量、調整快取粒度、更新快取等手段來提高命中率，
對于時效性很高（或快取空間有限），內容跨度很大（或訪問很隨機），并且訪問量不高的應用來說快取命中率可能長期很低，可能預熱后的快取還沒來得被訪問就已經過期了，
快取的分類和應用場景
（1）本地快取：編程實作（成員變數、區域變數、靜態變數）、Guava Cache
（2）分布式快取：Memcached、Redis
高并發場景下快取常見問題
（1）快取的一致性
更新資料庫成功——更新快取失敗
更新快取成功——更新資料庫失敗
更新資料庫成功——淘汰快取失敗
淘汰快取成功——更新資料庫失敗
（2）快取并發
并發時請求快取時已過期或者沒有命中或者更新的情況下有大量的請求訪問資料庫，
解決辦法：在快取更新或者過期的情況下,先嘗試獲取到lock,當更新完成后,嘗試釋放鎖,其他的請求只需要犧牲一定的等待時間
（3）快取穿透
在高并發的場景下,如果某一個key被高并發的訪問沒有被命中,出于對容錯性的考慮會嘗試從后端的資料庫獲取，從而導致大量的請求訪問了資料庫,主要是當key對應的資料為慷訓者為null的情況下，這就導致資料庫中并發的執行了很多不必要的查詢操作，從而導致了巨大的沖擊和壓力，
解決方法：快取空物件：對查詢結果為空的物件也進行快取，如果是集合可以快取一個空的集合，而不是null,如果是單個物件可以通過欄位標識來區分,需要保證快取資料的時效性(實作相對簡單)，適合命中不高但可能會頻繁更新的資料，
單獨過濾處理：對所有可能對應資料為空的key進行統一的存放,并在請求前做攔截(實作相對復雜)，適合命中不高更新不頻繁的資料
（4）快取顛簸問題
快取的顛簸問題，有些地方可能被稱為“快取抖動”，可以看作是一種比“雪崩”更輕微的故障，但是也會在一段時間內對系統造成沖擊和性能影響，一般是由于快取節點故障導致，業內推薦的做法是通過一致性Hash演算法來解決，
（5）快取雪崩現象
快取雪崩就是指由于快取的原因，導致大量請求到達后端資料庫，從而導致資料庫崩潰，整個系統崩潰，發生災難，導致這種現象的原因有很多種，上面提到的“快取并發”，“快取穿透”，“快取顛簸”等問題，其實都可能會導致快取雪崩現象發生，這些問題也可能會被惡意攻擊者所利用，還有一種情況，例如某個時間點內，系統預加載的快取周期性集中失效了，也可能會導致雪崩，為了避免這種周期性失效，可以通過設定不同的過期時間，來錯開快取過期，從而避免快取集中失效，
從應用架構角度，我們可以通過限流、降級、熔斷等手段來降低影響，也可以通過多級快取來避免這種災難，
此外，從整個研發體系流程的角度，應該加強壓力測驗，盡量模擬真實場景，盡早的暴露問題從而防范，
（6）快取無底洞現象
該問題由 facebook 的作業人員提出的， facebook 在 2010 年左右，memcached 節點就已經達3000 個，快取數千 G 內容，他們發現了一個問題—memcached 連接頻率，效率下降了，于是加 memcached 節點，添加了后，發現因為連接頻率導致的問題，仍然存在，并沒有好轉，稱之為”無底洞現象”，
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/541308.html
標籤：其他