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

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

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

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

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

2、請求分片集中，超過單 Server 的性能極限。

在服務(wù)端讀數(shù)據(jù)進行訪問時，往往會對數(shù)據(jù)進行分片切分，此過程中會在某一主機 Server 上對相應(yīng)的 Key 進行訪問，當(dāng)訪問超過 Server 極限時，就會導(dǎo)致熱點 Key 問題的產(chǎn)生。

二、熱點Key問題的危害

 

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

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

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

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

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

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

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

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

 

首先 Client 會將請求發(fā)送至 Server 上，而 Server 又是一個多線程的服務(wù)，本地就具有一個基于 Cache LRU 策略的緩存空間。

當(dāng) Server 本身就擁堵時，Server 不會將請求進一步發(fā)送給 DB 而是直接返回，只有當(dāng) Server 本身暢通時才會將 Client 請求發(fā)送至 DB，并且將該數(shù)據(jù)重新寫入到緩存中。

此時就完成了緩存的訪問跟重建。

但該方案也存在以下問題：

• 緩存失效，多線程構(gòu)建緩存問題
• 緩存丟失，緩存構(gòu)建問題
• 臟讀問題

2、使用 Memcache、Redis 方案

 

該方案通過在客戶端單獨部署緩存的方式來解決熱點 Key 問題。

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

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

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

3、使用本地緩存方案

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

• 需要提前獲知熱點
• 緩存容量有限
• 不一致性時間增長
• 熱點 Key 遺漏

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

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

 

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

• SLB 層做負載均衡
• Proxy 層做讀寫分離自動路由
• Master 負責(zé)寫請求
• ReadOnly 節(jié)點負責(zé)讀請求
• Slave 節(jié)點和 Master 節(jié)點做高可用

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

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

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

讀寫分離同時具有可以靈活擴容讀熱點能力、可以存儲大量熱點Key、對客戶端友好等優(yōu)點。

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

 

該方案通過主動發(fā)現(xiàn)熱點并對其進行存儲來解決熱點 Key 的問題。

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

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

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

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

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

四、熱點 key 處理

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

 

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

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

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

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

 

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

DB 計算熱點時，主要運用的方法和優(yōu)勢有：

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

五、方案對比

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

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