Redis冷熱資料辨識與交換怎麼實現

背景

Redis混合儲存產品是阿里雲自主研發的完全相容Redis協定和特性的混合儲存產品。

透過將部分冷資料儲存到磁碟，在確保絕大部分存取效能不下降的基礎上，大大降低了使用者成本並突破了記憶體對Redis單一實例資料量的限制。

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

冷熱資料定義

在Redis混合儲存中，記憶體和磁碟的比例是使用者可以自由選擇的：

Redis混合式儲存實例將所有的Key都視為熱數據，以少量的記憶體為代價保證所有Key的存取請求的效能是高效且一致的。而對於Value部分，在記憶體不足的情況下，實例本身會根據最近存取時間，存取頻度，Value大小等維度選取出部分value作為冷資料後台非同步儲存到磁碟上直到記憶體小於制定閾值為止。

在Redis混合儲存實例中，我們將所有的Key都認為是熱資料保存在記憶體中是出於以下兩點考慮：

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

2. 作為KV資料庫，通常的存取請求都需要先查找Key確認Key是否存在，而要確認一個key不存在，就需要以某種形式檢查所有Key的集合。保留所有鍵值對於記憶體中的資料結構來說，能夠保證與純記憶體資料結構的查找速度完全一致。

3. Key的大小佔比很低。

4. 在一般的商業模型中，即使是普通字串類型，其Value一般比Key大幾倍。而對於Set，List，Hash等集合對象，所有成員加起來組成的Value更是比Key大了好幾個數量級。

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

1. 資料存取不均勻，存在熱點資料；

2. 記憶體不足以放下所有數據，且Value較大(相對於Key而言)

#冷熱數據識別

#當記憶體不足時的情況下，實例會依照最近存取時間，存取頻度，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冷熱資料辨識與交換怎麼實現的詳細內容。更多資訊請關注PHP中文網其他相關文章！