一、定義

引用百度百科的定義：

對(duì)于集群系統(tǒng)，一般緩存是分布式的，即不同節(jié)點(diǎn)負(fù)責(zé)一定范圍的緩存數(shù)據(jù)。我們把緩存數(shù)據(jù)分散度不夠，導(dǎo)致大量的緩存數(shù)據(jù)集中到了一臺(tái)或者幾臺(tái)服務(wù)節(jié)點(diǎn)上，稱(chēng)為數(shù)據(jù)傾斜。一般來(lái)說(shuō)數(shù)據(jù)傾斜是由于負(fù)載均衡實(shí)施的效果不好引起的。

二、危害

如果發(fā)生了數(shù)據(jù)傾斜，那么就會(huì)有某一臺(tái)機(jī)器或幾臺(tái)保存了大量數(shù)據(jù)。輕則造成性能下降，處理請(qǐng)求速度驟降。重則造成Redis服務(wù)器崩潰，緩存服務(wù)不可用，將性能影響范圍擴(kuò)散到DB層，對(duì)后端服務(wù)造成不可估量的后果。

三、數(shù)據(jù)傾斜的分類(lèi)及應(yīng)對(duì)方案

1、寫(xiě)入傾斜

示例

如圖，在某些情況下，實(shí)例上的數(shù)據(jù)分布不均衡，某個(gè)實(shí)例上的數(shù)據(jù)特別多。

分析及應(yīng)對(duì)方案

1、bigkey導(dǎo)致傾斜

bigkey指的是某個(gè) Redis 實(shí)例上保存了一個(gè)很大的 value （String 類(lèi)型）或者是大量的集合元素（集合類(lèi)型）的 key ，這個(gè) key 就被稱(chēng)之為 bigkey ，而bigkey這種情況會(huì)導(dǎo)致集群中的某個(gè)實(shí)例的數(shù)據(jù)量很大，內(nèi)存資源消耗也相應(yīng)增加。

應(yīng)對(duì)方案

在業(yè)務(wù)層生成數(shù)據(jù)時(shí)，要盡量避免把過(guò)多的數(shù)據(jù)保存在同一個(gè)鍵值對(duì)中。如果 bigkey 正好是集合類(lèi)型，還有一個(gè)方法，就是把 bigkey 拆分成很多個(gè)小的集合類(lèi)型數(shù)據(jù)，分散保存在不同的實(shí)例上。

2、Slot分配不均導(dǎo)致傾斜

介紹一下slot，slot全稱(chēng)HashSlot(哈希槽)，類(lèi)似于數(shù)據(jù)分區(qū)，每個(gè)key都會(huì)根據(jù)Hash算法計(jì)算出它應(yīng)該屬于哪個(gè)哈希槽，最終落到那個(gè)哈希槽中。而 Redis Cluster 就是采用哈希槽的方式來(lái)處理數(shù)據(jù)和實(shí)例間的映射關(guān)系。事實(shí)上，在 Redis Cluster 分片集群中一共有16384 個(gè) Slot。 這里的Hash算法市面上的方式一般是先計(jì)算hash值，然后將計(jì)算結(jié)果對(duì)slot個(gè)數(shù)取模，最終確定落到哪個(gè)slot上。而計(jì)算hash值的算法有很多，常用的像CRC16、CRC64、sha1等等 運(yùn)維在構(gòu)建切片集群時(shí)候，需要手動(dòng)分配哈希槽，并且把16384 個(gè)槽都分配完，否則 Redis 集群無(wú)法正常工作。由于是手動(dòng)分配，則可能會(huì)導(dǎo)致部分實(shí)例所分配的slot過(guò)多，導(dǎo)致數(shù)據(jù)傾斜。

應(yīng)對(duì)方案

使用CLUSTER SLOTS 命令來(lái)查看slot分配情況，使用CLUSTER SETSLOT，CLUSTER GETKEYSINSLOT，MIGRATE這三個(gè)命令來(lái)進(jìn)行slot數(shù)據(jù)的遷移，具體內(nèi)容不再這里細(xì)說(shuō)，感興趣的同學(xué)可以自行學(xué)習(xí)一下。

3.Hash Tag導(dǎo)致傾斜

Hash Tag 定義 :指當(dāng)一個(gè)key包含 {} 的時(shí)候，就不對(duì)整個(gè)key做hash，而僅對(duì) {} 包括的字符串做hash。假設(shè)hash算法為sha1。

對(duì)user:{user1}:ids和user:{user1}:tweets，其hash值都等同于sha1(user1)。

也就是說(shuō)，如果不同 key 的 Hash Tag 內(nèi)容都是一樣的，那么，這些 key 對(duì)應(yīng)的數(shù)據(jù)會(huì)被映射到同一個(gè) Slot 中，同時(shí)會(huì)被分配到同一個(gè)實(shí)例上。

所以，如果不合理使用Hash Tag，會(huì)導(dǎo)致大量的數(shù)據(jù)可能被集中到一個(gè)實(shí)例上發(fā)生數(shù)據(jù)傾斜，集群中的負(fù)載不均衡。

應(yīng)對(duì)方案

按照需求合理使用Hash Tag，甚至可以考量是否需要用到Hash Tag。

2、讀取傾斜（熱key）

示例

一般來(lái)說(shuō)，讀取傾斜大多數(shù)都是熱key問(wèn)題導(dǎo)致的。如圖所示，雖然每個(gè)集群實(shí)例上的數(shù)據(jù)量相差并沒(méi)有很大，但是如果其中某個(gè)實(shí)例上的數(shù)據(jù)是熱點(diǎn)數(shù)據(jù)，那臺(tái)實(shí)例就會(huì)被訪(fǎng)問(wèn)得非常頻繁。

產(chǎn)生熱key的原因及危害

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

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

同理，被大量瀏覽的熱點(diǎn)數(shù)據(jù)、明星直播等，這些典型的讀多寫(xiě)少的場(chǎng)景也會(huì)產(chǎn)生熱點(diǎn)問(wèn)題。

危害：請(qǐng)求分片集中，超過(guò)單 Server 的性能極限。

在服務(wù)端讀數(shù)據(jù)訪(fǎng)問(wèn)Redis時(shí)，往往會(huì)對(duì)請(qǐng)求key進(jìn)行分片計(jì)算，此時(shí)中會(huì)將請(qǐng)求打到某一臺(tái) Server 上，如果熱點(diǎn)過(guò)于集中，熱點(diǎn) Key 的緩存過(guò)多，訪(fǎng)問(wèn)量超過(guò) Server 極限時(shí)，就會(huì)出現(xiàn)緩存分片服務(wù)被打垮現(xiàn)象的產(chǎn)生。當(dāng)緩存服務(wù)崩潰后，此時(shí)再有請(qǐng)求產(chǎn)生，就會(huì)打到DB 上，這也就是我們常說(shuō)的緩存穿透，如果沒(méi)有合理的解決，數(shù)據(jù)庫(kù)又沒(méi)有扛住大量的穿透請(qǐng)求，則會(huì)進(jìn)一步導(dǎo)致數(shù)據(jù)庫(kù)雪崩現(xiàn)象。造成所有連接此數(shù)據(jù)庫(kù)的系統(tǒng)服務(wù)不可用，上下游調(diào)用鏈中斷，產(chǎn)生不可估量的后果。

分析及應(yīng)對(duì)方案:

① 拆分熱key

拆分熱key，指的是把熱點(diǎn)數(shù)據(jù)拆分成多份，在每份數(shù)據(jù)副本的 key 中增加一個(gè)隨機(jī)后綴，讓它和其它副本數(shù)據(jù)不會(huì)被映射到同一個(gè) Slot 中。這里相當(dāng)于把一份數(shù)據(jù)復(fù)制到多個(gè)實(shí)例上，通過(guò)Hash算法實(shí)現(xiàn)一個(gè)簡(jiǎn)陋的負(fù)載均衡。同樣的，在讀取的時(shí)候也要增加隨機(jī)后綴，將對(duì)一個(gè)實(shí)例的讀取壓力，均攤到多個(gè)實(shí)例上。 例如：我們?cè)诜湃刖彺鏁r(shí)就將對(duì)應(yīng)業(yè)務(wù)的緩存key拆分成多個(gè)不同的key。如下圖所示，在寫(xiě)入緩存的過(guò)程中，我們首先將key拆成N份，比如某個(gè)請(qǐng)求進(jìn)來(lái)的key名字叫做"hot_key"，那我們就可以把它拆成“hot_key_001”、“hot_key_002”、“hot_key_003”、“hot_key_004”…，當(dāng)然了，每次更新和新增時(shí)都要記得去改動(dòng)這N個(gè)key，這就是拆key。

對(duì)于Service端來(lái)講，我們要盡可能的將訪(fǎng)問(wèn)流量分流的足夠的均勻。 如何給即將訪(fǎng)問(wèn)的熱key上合理的加入后綴？說(shuō)一下市面上常用的方案，根據(jù)本機(jī)的ip或mac地址做hash，之后的值與拆key的數(shù)量做取余，最終決定拼接成什么樣的key后綴，從而打到哪臺(tái)機(jī)器上。當(dāng)然也有其他的解決方案，比如在服務(wù)啟動(dòng)時(shí)的一個(gè)隨機(jī)數(shù)對(duì)拆key的數(shù)量做取余。 偽代碼如下:

public boolean getRandomHotKey(String hotKey,int count) {
        int random = new Random().nextInt(count);
        randomKey = hotKey + "_" + random;
        Object data = redis.get(randomKey);
        if (data == null){
            data = getFromDB(); 
            redis.set(randomKey,expireTime + random);
        }
    }

② 多級(jí)緩存+動(dòng)態(tài)計(jì)算自動(dòng)發(fā)現(xiàn)熱點(diǎn)緩存

基本流程圖

該方案主要是通過(guò)主動(dòng)發(fā)現(xiàn)熱點(diǎn)并對(duì)其進(jìn)行本地緩存來(lái)解決熱點(diǎn) Key 的問(wèn)題。對(duì)，你沒(méi)有聽(tīng)錯(cuò)，就是在緩存上再架設(shè)一層緩存。具體來(lái)說(shuō)，就是在 Proxy上增加本地緩存，本地緩存采用LRU算法來(lái)緩存熱點(diǎn)數(shù)據(jù)，后端節(jié)點(diǎn)增加熱點(diǎn)數(shù)據(jù)計(jì)算模塊來(lái)返回?zé)狳c(diǎn)數(shù)據(jù)。當(dāng)然了，Client會(huì)訪(fǎng)問(wèn)SLB，并且通過(guò)SLB將各種請(qǐng)求分發(fā)至Proxy中，Proxy會(huì)按照基于路由的方式將請(qǐng)求轉(zhuǎn)發(fā)至Redis中。

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ì)客戶(hù)端完全透明，不需做任何兼容

熱點(diǎn)數(shù)據(jù)的發(fā)現(xiàn)與存儲(chǔ)

對(duì)于熱點(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)，在通過(guò) Proxy 請(qǐng)求進(jìn)行訪(fǎng)問(wèn)時(shí)，若 Redis 發(fā)現(xiàn)待訪(fǎng)點(diǎn)是一個(gè)熱點(diǎn)，就會(huì)進(jìn)入一個(gè)反饋階段，同時(shí)對(duì)該數(shù)據(jù)進(jìn)行標(biāo)記。

可以使用一個(gè)etcd或者zk集群來(lái)存儲(chǔ)反饋的熱點(diǎn)數(shù)據(jù)，然后本地所有節(jié)點(diǎn)監(jiān)聽(tīng)該熱點(diǎn)數(shù)據(jù)，進(jìn)而加載到本地JVM緩存中。

熱點(diǎn)數(shù)據(jù)的獲取

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

假若經(jīng)過(guò)后端熱點(diǎn)模塊計(jì)算發(fā)現(xiàn) Key1 成為熱點(diǎn) key 后， Proxy 會(huì)將該熱點(diǎn)進(jìn)行本地緩存，當(dāng)下次客戶(hù)端再進(jìn)行訪(fǎng)問(wèn) Key1 時(shí)，則可以不讀取 Redis，直接從 Proxy 返回?cái)?shù)據(jù)。

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

成熟方案: JD開(kāi)源hotKey

上述的緩存傾斜解決思路，目前較為成熟解決方案是京東開(kāi)源的項(xiàng)目HotKey，它擁有自動(dòng)探測(cè)熱Key、分布式一致性緩存的設(shè)計(jì)。原理就是在Client端做洞察，然后上報(bào)對(duì)應(yīng)Hotkey，Server端檢測(cè)到后，將對(duì)應(yīng)Hotkey下發(fā)到對(duì)應(yīng)服務(wù)端做本地緩存，并且能保證本地緩存和遠(yuǎn)程緩存的一致性。

到此這篇關(guān)于Redis數(shù)據(jù)庫(kù)的數(shù)據(jù)傾斜詳解的文章就介紹到這了,更多相關(guān)Redis數(shù)據(jù)傾斜內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論