Redis冷熱數據識別與交換怎么實現

本文小編為大家詳細介紹“Redis冷熱數據識別與交換怎么實現”，內容詳細，步驟清晰，細節處理妥當，希望這篇“Redis冷熱數據識別與交換怎么實現”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

背景

Redis混合存儲產品是阿里云自主研發的完全兼容Redis協議和特性的混合存儲產品。

通過將部分冷數據存儲到磁盤，在保證絕大部分訪問性能不下降的基礎上，大大降低了用戶成本并突破了內存對Redis單實例數據量的限制。

其中，對冷熱數據的識別和交換是混合存儲產品性能的關鍵因素。

冷熱數據定義

在Redis混合存儲中，內存和磁盤的比例是用戶可以自由選擇的：

Redis混合存儲實例將所有的Key都認為是熱數據，以少量的內存為代價保證所有Key的訪問請求的性能是高效且一致的。而對于Value部分，在內存不足的情況下，實例本身會根據最近訪問時間，訪問頻度，Value大小等維度選取出部分value作為冷數據后臺異步存儲到磁盤上直到內存小于制定閾值為止。

在Redis混合存儲實例中，我們將所有的Key都認為是熱數據保存在內存中是出于以下兩點考慮：

1. Key的訪問頻度比Value要高很多。

2. 作為KV數據庫，通常的訪問請求都需要先查找Key確認Key是否存在，而要確認一個key不存在，就需要以某種形式檢查所有Key的集合。在內存中保留所有Key，可以保證key的查找速度與純內存版完全一致。

3. Key的大小占比很低。

4. 即使是普通字符串類型，通常的業務模型里面Value比Key要大幾倍。而對于Set，List，Hash等集合對象，所有成員加起來組成的Value更是比Key大了好幾個數量級。

因此，Redis混合存儲實例的適用場景主要有以下兩種：

1. 數據訪問不均勻，存在熱點數據；

2. 內存不足以放下所有數據，且Value較大(相對于Key而言)

冷熱數據識別

當內存不足時的情況下，實例會按照最近訪問時間，訪問頻度，value大小等維度計算出value的權重，將權重最低的value存儲到磁盤上并從內存中刪除。

偽代碼如下：

理想的情況下，我們當然希望能夠準確的計算出當前最冷的value。然而，value的冷熱程度根據訪問情況動態變化的，每次都重新計算所有value的冷熱權重的時間消耗是完全不可接受的。

Redis本身在內存滿的情況下會根據用戶設置的淘汰策略淘汰數據，而熱數據從內存寫到磁盤也可以認為是一種“淘汰”的過程。從性能，準確率以及用戶理解程度考慮，我們在冷熱數據識別時采用和Redis類似的近似計算方法,支持多種策略, 通過隨機采樣小部分數據來降低CPU和內存消耗，通過eviction pool利用采樣歷史信息來輔助提高準確率。

上圖為不同版本和不同采樣樣本數目配置下，Redis近似淘汰算法的命中率示意圖。淺灰色的點為被淘汰數據，灰色的點為未淘汰數據，綠色點為測試過程中新加入的數據。

冷熱數據交換

Redis混合存儲在冷熱數據交換過程在后臺IO線程中完成。

熱數據->冷數據

異步方式：

1. 主線程在內存接近最大值時，生成一系列數據換出任務；

2. 后臺線程執行這些數據換出任務，執行完畢之后通知主線程；

3. 主線程更新釋放內存中的value，更新內存中數據字典中的value為一個簡單的元信息；

4. 同步方式：

如果寫入流量過大，異步方式來不及換出數據，導致內存超出最大規格內存。主線程將直接執行數據換出任務，達到變相限流的目的。

冷數據->熱數據

異步方式：

1. 主線程在執行命令前，先判斷命令涉及的value是否都在內存中；

2. 如果不是，生成數據加載任務，掛起該客戶端，主線程繼續處理其他客戶端請求；

3. 后臺線程執行數據加載任務，執行完畢后通知主線程；

4. 主線程在內存中更新數據字典中的value，喚醒之前掛起的客戶端，處理其請求。

5. 同步方式：

在Lua腳本，具體命令執行階段，如果發現有value存儲在磁盤上，主線程將直接執行數據加載任務，保證Lua腳本和命令的語義不變。

讀到這里，這篇“Redis冷熱數據識別與交換怎么實現”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。