壓測報redis 熱點問題

熱點問題概述

產(chǎn)生原因

熱點問題產(chǎn)生的原因大致有以下兩種：

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

  在日常工作生活中一些突發(fā)的的事件，例如：雙十一期間某些熱門商品的降價促銷，當這其中的某一件商品被數(shù)萬次點擊瀏覽或者購買時，會形成一個較大的需求量，這種情況下就會造成熱點問題。同理，被大量刊發(fā)、瀏覽的熱點新聞、熱點評論、明星直播等，這些典型的讀多寫少的場景也會產(chǎn)生熱點問題。

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

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

熱點問題的危害

• 流量集中，達到物理網(wǎng)卡上限。
• 請求過多，緩存分片服務被打垮。
• DB擊穿，引起業(yè)務雪崩。

如前文講到的，當某一熱點Key的請求在某一主機上超過該主機網(wǎng)卡上限時，由于流量的過度集中，會導致服務器中其它服務無法進行。如果熱點過于集中，熱點Key的緩存過多，超過目前的緩存容量時，就會導致緩存分片服務被打垮現(xiàn)象的產(chǎn)生。當緩存服務崩潰后，此時再有請求產(chǎn)生，會緩存到后臺DB上，由于DB本身性能較弱，在面臨大請求時很容易發(fā)生請求穿透現(xiàn)象，會進一步導致雪崩現(xiàn)象，嚴重影響設備的性能。

常見解決方案

通常的解決方案主要集中在對客戶端和Server端進行相應的改造。

服務端緩存方案

首先Client會將請求發(fā)送至Server上，而Server又是一個多線程的服務，本地就具有一個基于Cache LRU策略的緩存空間。當Server本身就擁堵時，Server不會將請求進一步發(fā)送給DB而是直接返回，只有當Server本身暢通時才會將Client請求發(fā)送至DB，并且將該數(shù)據(jù)重新寫入到緩存中。此時就完成了緩存的訪問跟重建。

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

• 緩存失效，多線程構建緩存問題

• 緩存丟失，緩存構建問題

• 臟讀問題

使用Memcache、Redis方案

該方案通過在客戶端單獨部署緩存的方式來解決熱點Key問題。使用過程中Client首先訪問服務層，再對同一主機上的緩存層進行訪問。該種解決方案具有就近訪問、速度快、沒有帶寬限制的優(yōu)點，但是同時也存在以下問題。

• 內(nèi)存資源浪費

• 臟讀問題

使用本地緩存方案

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

• 需要提前獲知熱點

• 緩存容量有限

• 不一致性時間增長

• 熱點Key遺漏

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

阿里云數(shù)據(jù)庫解熱點之道

讀寫分離方案解決熱讀

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

• SLB層做負載均衡

• Proxy層做讀寫分離自動路由

• Master負責寫請求

• ReadOnly節(jié)點負責讀請求

• Replica節(jié)點和Master節(jié)點做高可用

實際過程中Client將請求傳到SLB，SLB又將其分發(fā)至多個Proxy內(nèi)，通過Proxy對請求的識別，將其進行分類發(fā)送。例如，將同為Write的請求發(fā)送到Master模塊內(nèi)，而將Read的請求發(fā)送至ReadOnly模塊。而模塊中的只讀節(jié)點可以進一步擴充，從而有效解決熱點讀的問題。讀寫分離同時具有可以靈活擴容讀熱點能力、可以存儲大量熱點Key、對客戶端友好等優(yōu)點。

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

該方案通過主動發(fā)現(xiàn)熱點并對其進行存儲來解決熱點Key的問題。首先Client也會訪問SLB，并且通過SLB將各種請求分發(fā)至Proxy中，Proxy會按照基于路由的方式將請求轉發(fā)至后端的Redis中。

在熱點key的解決上是采用在服務端增加緩存的方式進行。具體來說就是在Proxy上增加本地緩存，本地緩存采用LRU算法來緩存熱點數(shù)據(jù)，后端db節(jié)點增加熱點數(shù)據(jù)計算模塊來返回熱點數(shù)據(jù)。

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

• Proxy本地緩存熱點，讀能力可水平擴展

• DB節(jié)點定時計算熱點數(shù)據(jù)集合

• DB反饋 Proxy 熱點數(shù)據(jù)

• 對客戶端完全透明，不需做任何兼容

熱點key處理

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

在熱點Key的處理上主要分為寫入跟讀取兩種形式，在數(shù)據(jù)寫入過程當SLB收到數(shù)據(jù)K1并將其通過某一個Proxy寫入一個Redis，完成數(shù)據(jù)的寫入。假若經(jīng)過后端熱點模塊計算發(fā)現(xiàn)K1成為熱點key后， Proxy會將該熱點進行緩存，當下次客戶端再進行訪問K1時，可以不經(jīng)Redis。最后由于proxy是可以水平擴充的，因此可以任意增強熱點數(shù)據(jù)的訪問能力。

熱點數(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ù)進行標記。

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

• 基于統(tǒng)計閥值的熱點統(tǒng)計

• 基于統(tǒng)計周期的熱點統(tǒng)計

• 基于版本號實現(xiàn)的無需重置初值統(tǒng)計方法

• DB 計算同時具有對性能影響極其微小、內(nèi)存占用極其微小等優(yōu)點

兩種方案對比

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

轉載于:https://www.cnblogs.com/zgzf/p/10915455.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

以上是生活随笔為你收集整理的Redis 热点key的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。