一起分析Redis熱點數據問題解決方案

這篇文章為大家帶來了關於Redis的相關知識，其中主要介紹了關於Redis熱點key大Value解決方案的相關問題，下面一起來看一下，希望對大家有幫助。

推薦學習：Redis影片教學

#關於Redis 熱點資料& 大key 大value 問題也是容易被問到的高階問題，不如一次痛快點學完，讓面試官無話可說，個人工作經驗中，熱點數據問題在工作中相比雪崩更容易遇到，只是大部分時候熱點不夠熱，都會被提前告警解決，但這個問題一旦控制不了造成的線上問題也是足夠讓你今年績效墊底了，廢話不說進入正題。

正常情況下，Redis 叢集中資料都是均勻分配到每個節點，請求也會均勻的分佈到每個分片上，但在一些特殊場景中，例如外部爬蟲、攻擊、熱點商品等，最典型的就是明星在微博上宣布離婚，吃瓜群眾紛紛湧入留言，導致微博評論功能崩潰，這種短時間內某些key 訪問量過於大，對於這種相同的key 會請求到同一台資料分片上，導致此分片負載較高成為瓶頸問題，導致雪崩等一系列問題。

1、面試官：你在專案中有沒有遇到 Redis 熱點數據問題，通常都是什麼原因造成的？

問題分析：上次聽群組裡大佬面試阿里p7 就被問到這個問題，難度指數五顆星，對我等小白著實是加分項。

答：關於熱點資料問題我有話要說，這個問題我早在剛學習使用Redis 時就從已經意識到了，所以在使用時會刻意避免，堅決不會為自己挖坑，熱點資料最大的問題會造成Reids 叢集負載不均衡（也就是資料傾斜）導致的故障，這些問題對於Redis 叢集都是致命打擊。

先說造成Reids 叢集負載不均衡故障的主要原因：

1. #高訪問量的Key，也就是熱key，根據過去的維護經驗一個key 訪問的QPS 超過1000 就要高度關注了，比如熱門商品，熱門話題等。
2. 大Value，有些key 存取QPS 雖然不高，但由於value 很大，造成網卡負載較大，網卡流量被打滿，單一機器可能出現千兆/ 秒，IO 故障。
3. 熱點 Key 大 Value 同時存在，伺服器殺手。

那麼熱點key 或大Value 會造成哪些故障呢：

1. 資料傾斜問題：大Value 會導致群集不同節點資料分佈不均勻，造成資料傾斜問題，大量讀寫比例非常高的請求都會落到同一個redis server 上，該redis 的負載就會嚴重升高，容易打掛。
2. QPS 傾斜：分片上的 QPS 不均。
3.  大 Value 會導致 Redis 伺服器緩衝區不足，造成 get 逾時。
4. 由於 Value 過大，導致機房網路卡流量不足。
5. Redis 快取失效導致資料庫層被擊穿的連鎖反應。

2、面試官：真實專案中，那熱點資料問題你是如何準確定位的呢？

答：這個問題的解決方法比較寬泛，要具體看不同業務場景，例如公司組織促銷活動，那參加促銷的商品肯定是有辦法提前統計的，這種場景就可以通過預估法。對於突發事件，不確定因素，Redis 會自行監控熱點資料。大概歸納下：

1. 提前獲知法：
   根據業務，人肉統計or 系統統計可能會成為熱點的數據，如，促銷活動商品，熱門話題，假日話題，紀念日活動等。
2. Redis 用戶端收集法：
   呼叫端透過計數的方式統計 key 的請求次數，但是無法預知 key 的個數，程式碼侵入性強。

   public Connection sendCommand(final ProtocolCommand cmd, final byte[]... args) {
       //从参数中获取key
       String key = analysis(args);
       //计数
       counterKey(key);
       //ignore
   }

3. Redis 叢集代理層統計：
   像Twemproxy，codis 這些基於代理的Redis 分散式架構，統一的入口，可以在Proxy 層做收集上報，但是缺點很明顯，並非所有的Redis 叢集架構都有proxy。

   

4. Redis 服務端收集：
   監控Redis 單一分片的QPS，發現QPS 傾斜到一定程度的節點進行monitor，取得熱點key， Redis 提供了monitor命令，可以統計出一段時間內的某Redis 節點上的所有命令，分析熱點key，在高並發條件下，會存在內存暴漲和Redis 性能的隱患，所以此種方法適合在短時間內使用；同樣只能統計一個Redis 節點的熱點key，對於叢集需要總計統計，業務角度講稍微麻煩一點。
    

   

   以上為說的這 4 個方法都是現在業界比較常用的，方法，我透過學習 Redis 原始碼還有一個新的想法。第 5 種：修改 Redis 原始碼。

5.  修改Redis 原始碼：(從讀取原始碼想到的想法)

   我發現Redis4.0 為我們帶來了許多新特性，其中便包含基於LFU 的熱點key 發現機制，有了這個新特性，我們就可以在此基礎上實現熱點key 的統計，這個只是我的個人思路。

   面試官心理：小伙子還挺有想法，思路挺開闊，還打起了修改源碼的注意，我都沒這個野心。團隊裡就需要這樣的人。

   （發現問題，分析問題，解決問題，不等面試官發問，直接講述如何解決熱點數據問題，這才是核心內容）

#3、如何解決熱點資料問題

 答：關於如何治理熱點資料問題，解決這個問題主要從兩個面向考慮，第一是資料分片，讓壓力均攤到群集的多個分片上，防止單一機器打掛，第二是遷移隔離。

概括總結：

1. key 分割：
   如果目前key 的型別是一個二級資料結構，例如哈希類型。如果該哈希元素個數較多，可以考慮將目前hash 進行拆分，這樣該熱點key 可以拆分為若干個新的key 分佈到不同Redis 節點上，從而減輕壓力
2. 遷移熱點key：
   以Redis Cluster 為例，可以將熱點key 所在的slot 單獨遷移到一個新的Redis 節點上，這樣這個熱點key 即使QPS 很高，也不會影響到整個集群的其他業務，也可以客製化開發，熱點key 自動遷移到獨立節點上，此方案也較多重副本。
3. 熱點key 限流：
   對於讀取指令我們可以透過遷移熱點key 然後加入從節點來解決，對於寫指令我們可以透過單獨針對這個熱點key 來限流。
4. 增加本地快取：
   對於資料一致性不是那麼高的業務，可以將熱點key 快取到業務機器的本地快取中，因為是業務端的本地記憶體中，省去了一次遠端的IO 呼叫。但是當資料更新時，可能會造成業務和 Redis 資料不一致。

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

 4、面試官：關於 Redis 最後一個問題，Redis 支援豐富的資料類型，那麼這些資料類型儲存的大 Value 如何解決，線上有遇到這種情況嗎？

 問題分析：比起熱點key 大概念，大Value 的概念比好好理解，由於Redis 是單執行緒運行的，如果一次操作的value 很大會對整個redis 的回應時間造成負面影響，因為Redis 是Key - Value 結構資料庫，大value 就是單一value 佔用記憶體較大，對Redis 叢集造成最直接的影響就是資料傾斜。

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

我先說多大的Value 算大，根據公司基礎架構給出的經驗值可做以下劃分：

註：（經驗值不是標準，都是根據集群維運人員長期觀察線上case 總結出來的）

1. 大：string 類型value > 10K，set、list、hash、zset 等集合資料型別中的元素個數> 1000。
2. 超大： string 類型 value > 100K，set、list、hash、zset 等集合資料型別中的元素個數 > 10000。

由於Redis 是單執行緒運行的，如果一次操作的value 很大會對整個redis 的回應時間造成負面影響，所以，業務上能拆則拆，下面舉幾個典型的分拆方案：

1.  一个较大的 key-value 拆分成几个 key-value ，将操作压力平摊到多个 redis 实例中，降低对单个 redis 的 IO 影响
2. 将分拆后的几个 key-value 存储在一个 hash 中，每个 field 代表一个具体的属性，使用 hget,hmget 来获取部分的 value，使用 hset，hmset 来更新部分属性。
3. hash、set、zset、list 中存储过多的元素

类似于场景一中的第一个做法，可以将这些元素分拆。

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

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

现在，固定一个桶的数量，比如 10000，每次存取的时候，先在本地计算 field 的 hash 值，模除 10000，确定该 field 落在哪个 key 上，核心思想就是将 value 打散，每次只 get 你需要的。

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

推荐学习：Redis学习教程

以上是一起分析Redis熱點數據問題解決方案的詳細內容。更多資訊請關注PHP中文網其他相關文章！