大廠Redis熱點key解決之道
1 熱點key產生原因
1.1 消費的數據>>>生產的數據
- 比如電商秒殺活動、明星頭條微博
- 大量發布、瀏覽的熱點新聞、熱點評論等讀多寫少場景
1.2 分片的請求量突破單點性能極限
在服務端讀數據進行訪問時，往往會對數據進行分片，此過程中會在某一主機 Server 上對相應的 Key 進行訪問，當訪問超過 Server 極限時，就會導致熱點 Key 問題。
2 熱點Key的危害
- 流量過于集中，突破物理網卡的極限
- 請求過多，緩存分片服務被打垮
- 緩存擊穿
熱點Key請求某一主機，超過該主機網卡上限時，導致服務器中的其它服務無法正常進行
=》
熱點過于集中，熱點Key緩存過多，超過目前緩存容量，導致緩存分片服務被打垮
=》
緩存服務崩潰，此時再有請求產生，會緩存到后臺DB，導致緩存擊穿，進一步還會導致緩存雪崩。
3 解決方案
3.1 服務端緩存
Client會將請求發送到Server，而Server是多線程服務，本地就具有一個基于Cache LRU策略的緩存空間。當Server本身擁堵時，Server不會將請求進一步發送給DB而是直接返回，只有當Server本身暢通時才會將Client請求發送至DB，并且將該數據重新寫入緩存。此時就完成了緩存的訪問跟重建。
缺陷
- 緩存失效，多線程構建緩存問題
- 緩存丟失，緩存構建問題
- 臟讀
3.2 使用Memcache、Redis
在客戶端單獨部署緩存。使用過程中Client首先訪問服務層，再對同一主機上的緩存層進行訪問。該種解決方案具有就近訪問、速度快、沒有帶寬限制的優點。
缺陷
- 內存資源浪費
- 臟讀
3.3 本地緩存
缺陷
- 需要提前獲知熱點
- 緩存容量有限
- 不一致性時間增長
- 熱點Key遺漏
3.4 隨機后綴
使用Redis做緩存，那可以把一個熱點Key的緩存查詢壓力，分散到多個Redis節點。一個非常熱點的數據，數據更新不是很頻繁，但是查詢非常頻繁，要保證基本保證100%的緩存命中率，該怎么處理?
核心思想：空間換時間，即同一熱點key保留2份：
- 不帶后綴
不帶的后綴的有TTL
- 帶后綴
帶后綴的沒有TTL
先查詢不帶后綴的，查詢不到，則：
- 后端查詢DB更新緩存
- 查詢帶后綴返回給調用方
這樣即可盡可能避免緩存擊穿。
參考
https://www.alibabacloud.com/help/zh/doc-detail/67252.htm
本文轉載自微信公眾號「JavaEdge」，可以通過以下二維碼關注。轉載本文請聯系JavaEdge公眾號。
