Redis 混合存儲最佳實踐指南

Redis 混合存儲實例是阿里雲自主研發的兼容Redis協議和特性的雲數據庫產品，混合存儲實例突破 Redis 數據必須所有存儲到內存的限制，使用磁盤存儲全量數據，並將熱數據緩存到內存，實現訪問性能與存儲成本的完美平衡。

架構及特性

命令兼容

混合存儲兼容絕大多數 Redis 命令，與原生 Redis 相比，以下命令不支持或受限制；不支持的主要緣由是考慮到性能，如業務中有使用到，請提交工單。

Keys（鍵）	List（鏈表）	Scripting（Lua腳本）
RENAME	LINSERT	SCRIPT 不支持LOAD和DEBUG子命令
RENAMENX	LREM
MOVE
SWAPDB
SORT 不支持STORE選項

選型指南 - 場景

選型指南 - 規格

選擇混合存儲實例時，須要選擇合適的【內存配置 + 磁盤配置】；磁盤決定能存儲的數據總量，內存決定能存儲的熱數據總量，實例生產時會根據存儲的規格配置選擇合適的CPU資源配置，目前暫不支持自定義CPU核數。

好比【64GB內存 + 256GB磁盤】實例，意思是實例最多能存儲 256GB 的數據（以KV存儲引擎的物理文件總大小爲準），其中 64GB 數據能夠緩存在內存。

案例1：用戶A 使用 Redis Cluster 存儲了 100GB 的數據，總的訪問QPS不到2W，其中80%的數據都不多訪問到。用戶A 可使用 【32GB內存 + 128GB磁盤】 混合存儲實例，節省了近 70GB 的內存存儲，存儲成本降低50%+。
   
案例2：用戶B 在IDC自建 Pika/SSDB 實例，解決Redis存儲成本高的問題，存儲了約 400GB 的數據，其中活躍訪問的在10%左右，集羣運維負擔很重，想遷移至雲數據庫；用戶B 可使用 【64GB內存 + 512GB磁盤】混合存儲實例，來保證免運維的同時，服務質量不降低。

注：因 Redis 數據存儲到 KV 存儲引擎，每一個key都會額外元數據信息，存儲空間佔用會有必定的放大，建議在磁盤空間選擇上，留有適當餘量，按實際存儲需求的 1.2 - 1.5倍預估。

性能指標

Redis 混合存儲的性能與內存磁盤配比，以及業務的訪問高度相關；根據規格配置及業務訪問模式的不一樣，簡單 set/get 的性能可在幾千到數萬之間波動。最好狀況全部的訪問都內存命中，性能與 Redis 內存版基本一致；最差狀況全部的訪問都須要從磁盤讀取。

測試場景：2000w key，value大小爲1KB，25%的熱key能存儲在內存，get 請求測試數據以下

測試集	內存版（100%數據在內存）	混合存儲版（25%數據在內存）
隨機訪問	12.3(萬）	1.5
高斯分佈80%的機率訪問20%的key	12.0	5.4
高斯分佈99%的機率訪問1%的key	13.5	11.4

應用場景

視頻直播類

視頻直播類業務每每存在大量熱點數據，大部分的請求都來自於熱門的直播間。使用 Redis 混合存儲型實例，內存中保留熱門直播間的數據，不活躍的直播間數據被自動存儲到磁盤上，能夠達到對有限內存的最佳利用效果。

電商類

電商類應用有大量的商品數據，新上架的商品會被頻繁訪問，而較老的商品訪問熱度不高；使用 Redis 混合存儲型實例，能夠輕鬆突破內存容量限制，將大量的商品數據存儲到磁盤，在正常業務請求中，活躍的商品數據會逐步緩存在內存中，以最低的成本知足業務需求。

在線教育類

在線教育類的場景，有大量的課程、題庫、師生交流信息等數據，一般只有熱門課程、最新題庫題庫會被頻繁訪問； 使用 Redis 混合存儲型，將大量的課程信息存儲到磁盤，活躍的課程、題庫信息會換入到內存並常駐內存，保證高頻訪問數據的性能，實現性能與存儲成本的平衡。

其餘場景

其餘數據訪問有明顯冷熱特性，對性能要求不高的場景都可使用Redis混合存儲來下降存儲成本。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。