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