大廠Redis熱點key解決之道

  點擊上方“JavaEdge”，關注公衆號

設爲“星標”，好文章不錯過！

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

先查詢不帶後綴的，查詢不到，則：

1. 後端查詢DB更新緩存

2. 查詢帶後綴返回給調用方

這樣即可儘可能避免緩存擊穿。

參考

• https://www.alibabacloud.com/help/zh/doc-detail/67252.htm

往期推薦

由於不知線程池的bug,某Java程序員叕被祭天

程序員因重複記錄日誌撐爆ELK被辭退!

擁抱Kubernetes,再見了Spring Cloud

JDK爲何自己先破壞雙親委派模型?

目前交流羣已有 800+人，旨在促進技術交流，可關注公衆號添加筆者微信邀請進羣

喜歡文章，點個“在看、點贊、分享”素質三連支持一下~

本文分享自微信公衆號 - JavaEdge（Java-Edge）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。