引言

關(guān)于 Redis 熱點(diǎn)數(shù)據(jù) & 大 key 大 value 問題也是容易被問的高階問題，不如一次痛快點(diǎn)說完，讓面試官無話可說，個(gè)人工作經(jīng)驗(yàn)中，熱點(diǎn)數(shù)據(jù)問題在工作中相比雪崩更容易遇到，只是大部分時(shí)候熱點(diǎn)不夠熱，都會(huì)被提前告警解決，但這個(gè)問題一旦控制不了造成的線上問題也是足夠讓你今年績效墊底了，廢話不說進(jìn)入正題。

正常情況下，Redis 集群中數(shù)據(jù)都是均勻分配到每個(gè)節(jié)點(diǎn)，請(qǐng)求也會(huì)均勻的分布到每個(gè)分片上，但在一些特殊場景中，比如外部爬蟲、攻擊、熱點(diǎn)商品等，最典型的就是明星在微博上宣布離婚，吃瓜群眾紛紛涌入留言，導(dǎo)致微博評(píng)論功能崩潰，這種短時(shí)間內(nèi)某些 key 訪問量過于大，對(duì)于這種相同的 key 會(huì)請(qǐng)求到同一臺(tái)數(shù)據(jù)分片上，導(dǎo)致該分片負(fù)載較高成為瓶頸問題，導(dǎo)致雪崩等一系列問題。

1、面試官：你在項(xiàng)目中有沒有遇到 Redis 熱點(diǎn)數(shù)據(jù)問題，一般都是什么原因引起的？

問題分析：上次聽群里大佬面試阿里 p7 就被問到這個(gè)問題，難度指數(shù)五顆星，對(duì)我等小白著實(shí)是加分項(xiàng)。

答：關(guān)于熱點(diǎn)數(shù)據(jù)問題我有話要說，這個(gè)問題我早在剛剛學(xué)習(xí)使用 Redis 時(shí)就從已經(jīng)意識(shí)到了，所以在使用時(shí)會(huì)刻意避免，堅(jiān)決不會(huì)給自己挖坑，熱點(diǎn)數(shù)據(jù)最大的問題會(huì)造成 Reids 集群負(fù)載不均衡（也就是數(shù)據(jù)傾斜）導(dǎo)致的故障，這些問題對(duì)于 Redis 集群都是致命打擊。

先說說造成 Reids 集群負(fù)載不均衡故障的主要原因：

• 高訪問量的 Key，也就是熱 key，根據(jù)過去的維護(hù)經(jīng)驗(yàn)一個(gè) key 訪問的 QPS 超過 1000 就要高度關(guān)注了，比如熱門商品，熱門話題等。
• 大 Value，有些 key 訪問 QPS 雖然不高，但是由于 value 很大，造成網(wǎng)卡負(fù)載較大，網(wǎng)卡流量被打滿，單臺(tái)機(jī)器可能出現(xiàn)千兆 / 秒，IO 故障。
• 熱點(diǎn) Key + 大 Value 同時(shí)存在，服務(wù)器殺手。

那么熱點(diǎn) key 或大 Value 會(huì)造成哪些故障呢：

• 數(shù)據(jù)傾斜問題：大 Value 會(huì)導(dǎo)致集群不同節(jié)點(diǎn)數(shù)據(jù)分布不均勻，造成數(shù)據(jù)傾斜問題，大量讀寫比例非常高的請(qǐng)求都會(huì)落到同一個(gè) redis server 上，該 redis 的負(fù)載就會(huì)嚴(yán)重升高，容易打掛。
• QPS 傾斜：分片上的 QPS 不均。
• 大 Value 會(huì)導(dǎo)致 Redis 服務(wù)器緩沖區(qū)不足，造成 get 超時(shí)。
• 由于 Value 過大，導(dǎo)致機(jī)房網(wǎng)卡流量不足。
• Redis 緩存失效導(dǎo)致數(shù)據(jù)庫層被擊穿的連鎖反應(yīng)。

2、面試官：真實(shí)項(xiàng)目中，那熱點(diǎn)數(shù)據(jù)問題你是如何準(zhǔn)確定位的呢？

答：這個(gè)問題的解決辦法比較寬泛，要具體看不同業(yè)務(wù)場景，比如公司組織促銷活動(dòng)，那參加促銷的商品肯定是有辦法提前統(tǒng)計(jì)的，這種場景就可以通過預(yù)估法。對(duì)于突發(fā)事件，不確定因素，Redis 會(huì)自己監(jiān)控?zé)狳c(diǎn)數(shù)據(jù)。大概歸納下：

提前獲知法：

根據(jù)業(yè)務(wù)，人肉統(tǒng)計(jì) or 系統(tǒng)統(tǒng)計(jì)可能會(huì)成為熱點(diǎn)的數(shù)據(jù)，如，促銷活動(dòng)商品，熱門話題，節(jié)假日話題，紀(jì)念日活動(dòng)等。

Redis 客戶端收集法：

調(diào)用端通過計(jì)數(shù)的方式統(tǒng)計(jì) key 的請(qǐng)求次數(shù)，但是無法預(yù)知 key 的個(gè)數(shù)，代碼侵入性強(qiáng)。

public Connection sendCommand(final ProtocolCommand cmd, final byte[]... args) {
    //從參數(shù)中獲取key
    String key = analysis(args);
    //計(jì)數(shù)
    counterKey(key);
    //ignore
}

Redis 集群代理層統(tǒng)計(jì)：

像 Twemproxy，codis 這些基于代理的 Redis 分布式架構(gòu)，統(tǒng)一的入口，可以在 Proxy 層做收集上報(bào)，但是缺點(diǎn)很明顯，并非所有的 Redis 集群架構(gòu)都有 proxy。

Redis 服務(wù)端收集：

監(jiān)控 Redis 單個(gè)分片的 QPS，發(fā)現(xiàn) QPS 傾斜到一定程度的節(jié)點(diǎn)進(jìn)行 monitor，獲取熱點(diǎn) key， Redis 提供了 monitor 命令，可以統(tǒng)計(jì)出一段時(shí)間內(nèi)的某 Redis 節(jié)點(diǎn)上的所有命令，分析熱點(diǎn) key，在高并發(fā)條件下，會(huì)存在內(nèi)存暴漲和 Redis 性能的隱患，所以此種方法適合在短時(shí)間內(nèi)使用；同樣只能統(tǒng)計(jì)一個(gè) Redis 節(jié)點(diǎn)的熱點(diǎn) key，對(duì)于集群需要匯總統(tǒng)計(jì)，業(yè)務(wù)角度講稍微麻煩一點(diǎn)。

以上為說的這 4 個(gè)方法都是現(xiàn)在業(yè)界比較常用的，方法，我通過學(xué)習(xí) Redis 源碼還有一個(gè)新的想法。第 5 種：修改 Redis 源碼。

 修改 Redis 源代碼：(從讀源碼中想到的思路)

我發(fā)現(xiàn) Redis4.0 為我們帶來了許多新特性，其中便包括基于 LFU 的熱點(diǎn) key 發(fā)現(xiàn)機(jī)制，有了這個(gè)新特性，我們就可以在此基礎(chǔ)上實(shí)現(xiàn)熱點(diǎn) key 的統(tǒng)計(jì)，這個(gè)只是我的個(gè)人思路。

面試官心理：小伙子還挺有想法，思路挺開闊，還打起了修改源碼的注意，我都沒這個(gè)野心。團(tuán)隊(duì)里就需要這樣的人。

（發(fā)現(xiàn)問題，分析問題，解決問題，不等面試官發(fā)問，直接講述如何解決熱點(diǎn)數(shù)據(jù)問題，這才是核心內(nèi)容）

3、如何解決熱點(diǎn)數(shù)據(jù)問題

 答：關(guān)于如何治理熱點(diǎn)數(shù)據(jù)問題，解決這個(gè)問題主要從兩個(gè)方面考慮，第一是數(shù)據(jù)分片，讓壓力均攤到集群的多個(gè)分片上，防止單個(gè)機(jī)器打掛，第二是遷移隔離。

概括總結(jié)：

key 拆分：

如果當(dāng)前 key 的類型是一個(gè)二級(jí)數(shù)據(jù)結(jié)構(gòu)，例如哈希類型。如果該哈希元素個(gè)數(shù)較多，可以考慮將當(dāng)前 hash 進(jìn)行拆分，這樣該熱點(diǎn) key 可以拆分為若干個(gè)新的 key 分布到不同 Redis 節(jié)點(diǎn)上，從而減輕壓力

遷移熱點(diǎn) key：

以 Redis Cluster 為例，可以將熱點(diǎn) key 所在的 slot 單獨(dú)遷移到一個(gè)新的 Redis 節(jié)點(diǎn)上，這樣這個(gè)熱點(diǎn) key 即使 QPS 很高，也不會(huì)影響到整個(gè)集群的其他業(yè)務(wù)，還可以定制化開發(fā)，熱點(diǎn) key 自動(dòng)遷移到獨(dú)立節(jié)點(diǎn)上，這種方案也較多副本。

熱點(diǎn) key 限流：

對(duì)于讀命令我們可以通過遷移熱點(diǎn) key 然后添加從節(jié)點(diǎn)來解決，對(duì)于寫命令我們可以通過單獨(dú)針對(duì)這個(gè)熱點(diǎn) key 來限流。

增加本地緩存：

對(duì)于數(shù)據(jù)一致性不是那么高的業(yè)務(wù)，可以將熱點(diǎn) key 緩存到業(yè)務(wù)機(jī)器的本地緩存中，因?yàn)槭菢I(yè)務(wù)端的本地內(nèi)存中，省去了一次遠(yuǎn)程的 IO 調(diào)用。但是當(dāng)數(shù)據(jù)更新時(shí)，可能會(huì)造成業(yè)務(wù)和 Redis 數(shù)據(jù)不一致。

面試官：你回答得很好，考慮得很全面。

4、面試官：關(guān)于 Redis 最后一個(gè)問題，Redis 支持豐富的數(shù)據(jù)類型，那么這些數(shù)據(jù)類型存儲(chǔ)的大 Value 如何解決，線上有遇到這種情況嗎？

 問題分析：相比熱點(diǎn) key 大概念，大 Value 的概念比好好理解，由于 Redis 是單線程運(yùn)行的，如果一次操作的 value 很大會(huì)對(duì)整個(gè) redis 的響應(yīng)時(shí)間造成負(fù)面影響，因?yàn)?Redis 是 Key - Value 結(jié)構(gòu)數(shù)據(jù)庫，大 value 就是單個(gè) value 占用內(nèi)存較大，對(duì) Redis 集群造成最直接的影響就是數(shù)據(jù)傾斜。

 答：（想難倒我？我可是有備而來。）

我先說說多大的 Value 算大，根據(jù)公司基礎(chǔ)架構(gòu)給出的經(jīng)驗(yàn)值可做以下劃分：

注：（經(jīng)驗(yàn)值不是標(biāo)準(zhǔn)，都是根據(jù)集群運(yùn)維人員長期觀察線上 case 總結(jié)出來的）

大：string 類型 value > 10K，set、list、hash、zset 等集合數(shù)據(jù)類型中的元素個(gè)數(shù) > 1000。

超大： string 類型 value > 100K，set、list、hash、zset 等集合數(shù)據(jù)類型中的元素個(gè)數(shù) > 10000。

由于 Redis 是單線程運(yùn)行的，如果一次操作的 value 很大會(huì)對(duì)整個(gè) redis 的響應(yīng)時(shí)間造成負(fù)面影響，所以，業(yè)務(wù)上能拆則拆，下面舉幾個(gè)典型的分拆方案：

• 一個(gè)較大的 key-value 拆分成幾個(gè) key-value ，將操作壓力平攤到多個(gè) redis 實(shí)例中，降低對(duì)單個(gè) redis 的 IO 影響
• 將分拆后的幾個(gè) key-value 存儲(chǔ)在一個(gè) hash 中，每個(gè) field 代表一個(gè)具體的屬性，使用 hget,hmget 來獲取部分的 value，使用 hset，hmset 來更新部分屬性。
• hash、set、zset、list 中存儲(chǔ)過多的元素

類似于場景一中的第一個(gè)做法，可以將這些元素分拆。

以 hash 為例，原先的正常存取流程是:

hget(hashKey, field); 
hset(hashKey, field, value)

現(xiàn)在，固定一個(gè)桶的數(shù)量，比如 10000，每次存取的時(shí)候，先在本地計(jì)算 field 的 hash 值，模除 10000，確定該 field 落在哪個(gè) key 上，核心思想就是將 value 打散，每次只 get 你需要的。

newHashKey = hashKey + (hash(field) % 10000); 
hset(newHashKey, field, value); 
hget(newHashKey, field)

面試官已經(jīng)被我折服，終于放棄了 Redis 的追問。

總結(jié)

如果你對(duì) Redis 真對(duì)不是很熟悉，有些人干脆說自己項(xiàng)目小，壓根沒有用過 Redis，只知道一些理論知識(shí)，那么我建議你讀者重點(diǎn)掌握《 說說 Redis 中有哪些數(shù)據(jù)結(jié)構(gòu)及底層實(shí)現(xiàn)原理》《緩存必問：Redis 持久化，高可用集群》《Redis 雪崩，穿透，擊穿三連問》這三篇，至于 Redis 熱點(diǎn)數(shù)據(jù)問題，如果想要多談點(diǎn)工資盡量掌握。推薦閱讀《Redis 開發(fā)與運(yùn)維》

以上就是面試分析分布式架構(gòu)Redis熱點(diǎn)key大Value解決方案的詳細(xì)內(nèi)容，更多關(guān)于分布式架構(gòu)面試Redis熱點(diǎn)key大Value的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論