Redis熱點(diǎn)Key發(fā)現(xiàn)及常見解決方案是怎樣的

一、熱點(diǎn)Key問題產(chǎn)生的原因

1、用戶消費(fèi)的數(shù)據(jù)遠(yuǎn)大于生產(chǎn)的數(shù)據(jù)（熱賣商品、熱點(diǎn)新聞、熱點(diǎn)評(píng)論、明星直播）。

在日常工作生活中一些突發(fā)的的事件，例如：雙十一期間某些熱門商品的降價(jià)促銷，當(dāng)這其中的某一件商品被數(shù)萬(wàn)次點(diǎn)擊瀏覽或者購(gòu)買時(shí)，會(huì)形成一個(gè)較大的需求量，這種情況下就會(huì)造成熱點(diǎn)問題。

同理，被大量刊發(fā)、瀏覽的熱點(diǎn)新聞、熱點(diǎn)評(píng)論、明星直播等，這些典型的讀多寫少的場(chǎng)景也會(huì)產(chǎn)生熱點(diǎn)問題。

2、請(qǐng)求分片集中，超過單 Server 的性能極限。

在服務(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 問題的產(chǎn)生。

二、熱點(diǎn)Key問題的危害

 

• 1、流量集中，達(dá)到物理網(wǎng)卡上限。

• 2、請(qǐng)求過多，緩存分片服務(wù)被打垮。

• 3、DB 擊穿，引起業(yè)務(wù)雪崩。

如前文講到的，當(dāng)某一熱點(diǎn) Key 的請(qǐng)求在某一主機(jī)上超過該主機(jī)網(wǎng)卡上限時(shí)，由于流量的過度集中，會(huì)導(dǎo)致服務(wù)器中其它服務(wù)無法進(jìn)行。

如果熱點(diǎn)過于集中，熱點(diǎn) Key 的緩存過多，超過目前的緩存容量時(shí)，就會(huì)導(dǎo)致緩存分片服務(wù)被打垮現(xiàn)象的產(chǎn)生。

當(dāng)緩存服務(wù)崩潰后，此時(shí)再有請(qǐng)求產(chǎn)生，會(huì)緩存到后臺(tái) DB 上，由于DB 本身性能較弱，在面臨大請(qǐng)求時(shí)很容易發(fā)生請(qǐng)求穿透現(xiàn)象，會(huì)進(jìn)一步導(dǎo)致雪崩現(xiàn)象，嚴(yán)重影響設(shè)備的性能。

三、解決方案 通常的解決方案主要集中在對(duì)客戶端和 Server 端進(jìn)行相應(yīng)的改造。

1、服務(wù)端緩存方案

 

首先 Client 會(huì)將請(qǐng)求發(fā)送至 Server 上，而 Server 又是一個(gè)多線程的服務(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)建問題
• 臟讀問題

2、使用 Memcache、Redis 方案

 

該方案通過在客戶端單獨(dú)部署緩存的方式來解決熱點(diǎn) Key 問題。

使用過程中 Client 首先訪問服務(wù)層，再對(duì)同一主機(jī)上的緩存層進(jìn)行訪問。

該種解決方案具有就近訪問、速度快、沒有帶寬限制的優(yōu)點(diǎn)，但是同時(shí)也存在以下問題：

• 內(nèi)存資源浪費(fèi)
• 臟讀問題

3、使用本地緩存方案

使用本地緩存則存在以下問題：

• 需要提前獲知熱點(diǎn)
• 緩存容量有限
• 不一致性時(shí)間增長(zhǎng)
• 熱點(diǎn) Key 遺漏

傳統(tǒng)的熱點(diǎn)解決方案都存在各種各樣的問題，那么究竟該如何解決熱點(diǎn)問題呢？

4、讀寫分離方案解決熱讀

 

架構(gòu)中各節(jié)點(diǎn)的作用如下：

• SLB 層做負(fù)載均衡
• Proxy 層做讀寫分離自動(dòng)路由
• Master 負(fù)責(zé)寫請(qǐng)求
• ReadOnly 節(jié)點(diǎn)負(fù)責(zé)讀請(qǐng)求
• Slave 節(jié)點(diǎn)和 Master 節(jié)點(diǎn)做高可用

實(shí)際過程中 Client 將請(qǐng)求傳到 SLB，SLB 又將其分發(fā)至多個(gè) Proxy 內(nèi)，通過 Proxy 對(duì)請(qǐng)求的識(shí)別，將其進(jìn)行分類發(fā)送。

例如，將同為 Write 的請(qǐng)求發(fā)送到 Master 模塊內(nèi)，而將 Read 的請(qǐng)求發(fā)送至 ReadOnly 模塊。

而模塊中的只讀節(jié)點(diǎn)可以進(jìn)一步擴(kuò)充，從而有效解決熱點(diǎn)讀的問題。

讀寫分離同時(shí)具有可以靈活擴(kuò)容讀熱點(diǎn)能力、可以存儲(chǔ)大量熱點(diǎn)Key、對(duì)客戶端友好等優(yōu)點(diǎn)。

5、熱點(diǎn)數(shù)據(jù)解決方案

 

該方案通過主動(dòng)發(fā)現(xiàn)熱點(diǎn)并對(duì)其進(jìn)行存儲(chǔ)來解決熱點(diǎn) Key 的問題。

首先 Client 也會(huì)訪問 SLB，并且通過 SLB 將各種請(qǐng)求分發(fā)至 Proxy 中，Proxy 會(huì)按照基于路由的方式將請(qǐng)求轉(zhuǎn)發(fā)至后端的 Redis 中。

在熱點(diǎn) key 的解決上是采用在服務(wù)端增加緩存的方式進(jìn)行。

具體來說就是在 Proxy 上增加本地緩存，本地緩存采用 LRU 算法來緩存熱點(diǎn)數(shù)據(jù)，后端 db 節(jié)點(diǎn)增加熱點(diǎn)數(shù)據(jù)計(jì)算模塊來返回?zé)狳c(diǎn)數(shù)據(jù)。

Proxy 架構(gòu)的主要有以下優(yōu)點(diǎn)：

• Proxy 本地緩存熱點(diǎn)，讀能力可水平擴(kuò)展
• DB 節(jié)點(diǎn)定時(shí)計(jì)算熱點(diǎn)數(shù)據(jù)集合
• DB 反饋 Proxy 熱點(diǎn)數(shù)據(jù)
• 對(duì)客戶端完全透明，不需做任何兼容

四、熱點(diǎn) key 處理

1、熱點(diǎn)數(shù)據(jù)的讀取

 

在熱點(diǎn) Key 的處理上主要分為寫入跟讀取兩種形式，在數(shù)據(jù)寫入過程當(dāng) SLB 收到數(shù)據(jù) K1 并將其通過某一個(gè) Proxy 寫入一個(gè) Redis，完成數(shù)據(jù)的寫入。

假若經(jīng)過后端熱點(diǎn)模塊計(jì)算發(fā)現(xiàn) K1 成為熱點(diǎn) key 后， Proxy 會(huì)將該熱點(diǎn)進(jìn)行緩存，當(dāng)下次客戶端再進(jìn)行訪問 K1 時(shí)，可以不經(jīng) Redis。

最后由于 proxy 是可以水平擴(kuò)充的，因此可以任意增強(qiáng)熱點(diǎn)數(shù)據(jù)的訪問能力。

2、熱點(diǎn)數(shù)據(jù)的發(fā)現(xiàn)

 

對(duì)于 db 上熱點(diǎn)數(shù)據(jù)的發(fā)現(xiàn)，首先會(huì)在一個(gè)周期內(nèi)對(duì) Key 進(jìn)行請(qǐng)求統(tǒng)計(jì)，在達(dá)到請(qǐng)求量級(jí)后會(huì)對(duì)熱點(diǎn) Key 進(jìn)行熱點(diǎn)定位，并將所有的熱點(diǎn) Key 放入一個(gè)小的 LRU 鏈表內(nèi)，在通過 Proxy 請(qǐng)求進(jìn)行訪問時(shí)，若 Redis 發(fā)現(xiàn)待訪點(diǎn)是一個(gè)熱點(diǎn)，就會(huì)進(jìn)入一個(gè)反饋階段，同時(shí)對(duì)該數(shù)據(jù)進(jìn)行標(biāo)記。

DB 計(jì)算熱點(diǎn)時(shí)，主要運(yùn)用的方法和優(yōu)勢(shì)有：

• 1、基于統(tǒng)計(jì)閥值的熱點(diǎn)統(tǒng)計(jì)
• 2、基于統(tǒng)計(jì)周期的熱點(diǎn)統(tǒng)計(jì)
• 3、基于版本號(hào)實(shí)現(xiàn)的無需重置初值統(tǒng)計(jì)方法
• 4、DB 計(jì)算同時(shí)具有對(duì)性能影響極其微小、內(nèi)存占用極其微小等優(yōu)點(diǎn)

五、方案對(duì)比

通過上述對(duì)比分析可以看出，在解決熱點(diǎn) Key 上較傳統(tǒng)方法相比都有較大的提高，無論是基于讀寫分離方案還是熱點(diǎn)數(shù)據(jù)解決方案，在實(shí)際處理環(huán)境中都可以做靈活的水平能力擴(kuò)充、都對(duì)客戶端透明、都有一定的數(shù)據(jù)不一致性。

此外讀寫分離模式可以存儲(chǔ)更大量的熱點(diǎn)數(shù)據(jù)，而基于 Proxy 的模式有成本上的優(yōu)勢(shì)。