面試官：如何發(fā)現(xiàn) Redis 熱點(diǎn) Key ，解決方案有哪些？

熱點(diǎn)問題概述

產(chǎn)生原因

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

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

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

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

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

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

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

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

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

如前文講到的，當(dāng)某一熱點(diǎn) Key 的請求在某一主機(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í)再有請求產(chǎn)生，會(huì)緩存到后臺(tái) DB 上，由于DB 本身性能較弱，在面臨大請求時(shí)很容易發(fā)生請求穿透現(xiàn)象，會(huì)進(jìn)一步導(dǎo)致雪崩現(xiàn)象，嚴(yán)重影響設(shè)備的性能。

常見解決方案

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

服務(wù)端緩存方案

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

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

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

• 緩存丟失，緩存構(gòu)建問題

• 臟讀問題

使用 Memcache、Redis 方案

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

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

• 臟讀問題

使用本地緩存方案

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

• 需要提前獲知熱點(diǎn)

• 緩存容量有限

• 不一致性時(shí)間增長

• 熱點(diǎn) Key 遺漏

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

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

讀寫分離方案解決熱讀

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

• SLB 層做負(fù)載均衡

• Proxy 層做讀寫分離自動(dòng)路由

• Master 負(fù)責(zé)寫請求

• ReadOnly 節(jié)點(diǎn)負(fù)責(zé)讀請求

• Slave 節(jié)點(diǎn)和 Master 節(jié)點(diǎn)做高可用

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

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

該方案通過主動(dòng)發(fā)現(xiàn)熱點(diǎn)并對其進(jìn)行存儲(chǔ)來解決熱點(diǎn) Key 的問題。首先 Client 也會(huì)訪問 SLB，并且通過 SLB 將各種請求分發(fā)至 Proxy 中，Proxy 會(huì)按照基于路由的方式將請求轉(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ù)

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

熱點(diǎn) key 處理

熱點(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ù)的訪問能力。

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

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

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

• 基于統(tǒng)計(jì)閥值的熱點(diǎn)統(tǒng)計(jì)

• 基于統(tǒng)計(jì)周期的熱點(diǎn)統(tǒng)計(jì)

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

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

兩種方案對比

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

來源：https://github.com/AlibabaCloudDocs