找出並最佳化大Key與熱Key - Tair (Redis® OSS-Compatible)

Big keys（大Key）與Hot keys（熱Key）可能導致服務效能下降、請求逾時，甚至引發系統故障。本文介紹如何快速找出和最佳化大Key與熱Key，分析其產生原因及影響，並提供預防措施以降低對業務的影響。

步驟一：快速找出大Key和熱Key

阿里雲控制台工具

Tair和Redis在控制台提供了Top Key統計和離線全量Key分析功能協助您快速找出大Key與熱Key。

方法	使用限制	說明	操作步驟
Top Key統計（推薦）	僅Redis開源版5.0及以上版本和Tair（企業版）記憶體型、持久記憶體型支援該功能。	即時顯示每個分區中各資料類型前三的大Key和熱Key資訊。支援查看4天內大Key和熱Key的歷史資訊。	訪問執行個體列表，在上方選擇地區，然後單擊目標執行個體ID。在左側導覽列，單擊CloudDBA > 即時Top Key統計或離線全量Key分析。
離線全量Key分析	磁碟型執行個體不支援該功能。	對RDB備份檔案進行定製化的分析，得出Key在記憶體中的佔用和分布、Key到期時間等資訊。時效性差，RDB檔案較大時耗時較長。無法分析熱Key資訊。

如果您的執行個體不能使用上述功能，請參考以下方法。

其他方法找出大Key和熱Key

方法	優缺點	說明
通過redis-cli的bigkeys、memkeys和hotkeys參數	優點：方便、快速、安全。缺點：分析結果不可定製化，準確性與時效性差；需要遍曆執行個體當前所有Key，可能影響執行個體效能。	redis-cli的bigkeys、memkeys與hotkeys參數能擷取Key的整體統計資訊與每個資料類型中Top1的大Key或熱Key。區別如下： bigkeys：統計大Key資訊，集合或清單類型返回元素個數。 memkeys：統計大Key資訊，返回所有資料類型所佔記憶體大小。 hotkeys：統計熱Key資訊。支援的資料類型：STRING、LIST、HASH、SET、ZSET、STREAM。以bigkeys為例，命令樣本為`redis-cli -h r-***************.redis.rds.aliyuncs.com -a <password> --bigkeys`。
通過內建命令對目標Key進行分析	優點：對線上服務影響小。缺點：返回的Key序列化長度並不等同於它在記憶體空間中的真實長度，因此不夠準確，僅可作為參考。	對不同資料類型的目標Key，分別通過如下風險較低的命令進行分析，來判斷目標Key是否符合大Key判定標準。 STRING類型：STRLEN命令，返回對應Key的value的位元組數。 LIST類型：LLEN命令，返回對應Key的列表長度。 HASH類型：HLEN命令，返回對應Key的成員數量。 SET類型：SCARD命令，返回對應Key的成員數量。 ZSET類型：ZCARD命令，返回對應Key的成員數量。 STREAM類型：XLEN命令，返回對應Key的成員數量。說明 DEBUG OBJECT與MEMORY USAGE命令在執行時需佔用較多資源，且時間複雜度為O(N)，有阻塞執行個體的風險，不建議使用。
通過業務層定位熱Key	優點：可準確並及時地定位熱Key。缺點：業務代碼複雜度的增加，同時可能會降低一些效能。	通過在業務層增加相應的代碼對執行個體的訪問進行記錄並非同步匯總分析。
通過redis-rdb-tools工具以定製化方式找出大Key	優點：支援定製化分析，對線上服務無影響。缺點：時效性差，RDB檔案較大時耗時較長。	Redis-rdb-tools是通過Python編寫的開源工具，支援定製化分析RDB快照檔案。下載RDB檔案後，您可以根據業務需求分析執行個體中所有Key的記憶體佔用情況，並支援靈活地查詢。
通過MONITOR命令找出熱Key	優點：方便、安全。缺點：會佔用CPU、記憶體、網路資源，時效性與準確性較差。	MONITOR命令能夠忠實地列印執行個體中的所有請求，包括時間資訊、Client資訊、命令以及Key資訊。在發生緊急情況時，可以通過短暫執行MONITOR命令並將返回資訊輸入至檔案，在關閉MONITOR命令後，對檔案中請求進行歸類分析，找出這段時間中的熱Key。說明由於MONITOR命令對執行個體效能消耗較大，非特殊情況不推薦使用MONITOR命令。

步驟二：最佳化大Key與熱Key

大Key

方案	適用情境	操作建議
清理到期資料	大量到期資料堆積，如HASH中未清理的增量資料。	通過HSCAN命令配合HDEL命令對失效資料進行清理，避免清理大量資料造成執行個體阻塞。
壓縮大Key	JSON、XML文本資料等可壓縮資料，如日誌、配置。	序列化時啟動壓縮，如GZIP、Snappy。使用二進位序列化協議，如Protocol Buffers。說明壓縮和解壓縮操作需要消耗額外的CPU資源，可能影響處理效能。
拆分大Key	高頻訪問的HASH、ZSET等，如熱門排行榜。	按照商務邏輯拆分，如使用者ID、時間範圍。使用分區鍵設計，如：user:1001:shard1、user:1001:shard2。拆分大Key能有效避免資料扭曲。
轉存大Key	String類型大檔案或BLOB。	將不適用資料存至其它儲存（如OSS），並在執行個體中刪除此類資料。 Redis開源版4.0及之後版本：您可以通過UNLINK命令安全地刪除大Key甚至特大Key，該命令通過非同步方式清理 Key，避免阻塞主線程。 Redis開源版4.0之前的版本：建議先通過SCAN命令讀取部分資料，然後進行刪除，避免一次性刪除大量key導致主線程阻塞。

熱Key

方案	適用情境	操作建議
在叢集架構中對熱Key進行複製	熱Key作為整體儲存在單一分區，無法通過遷移部分資料分散請求。	將熱Key複製並遷移至其他資料分區，例如將熱Key foo複製出3個內容完全一樣的Key並命名為foo2、foo3、foo4，將這三個Key遷移到其他資料分區來解決單個資料分區的熱Key壓力。說明該方案的缺點是需修改代碼維護多個副本，且多副本間的資料一致性難以保障（例如更新操作需同步所有副本）。建議將該方案作為臨時解決方案，用於緩解緊急問題。
開啟讀寫分離	讀多寫少	如果開啟後讀請求負載依舊很高，可通過增加唯讀節點數量進一步緩解讀請求負載。說明在請求量極大的情境下，主備同步會產生不可避免的延遲，此時會出現讀取到髒資料的問題。因此，在讀、寫壓力都較大且對資料一致性要求很高的情境下，不推薦開啟讀寫分離。

步驟三：預防大Key和熱Key影響業務

大Key和熱Key產生的原因

Tair和Redis的最小資料分布粒度為Key。單個Key將儲存在特定的資料分區中，且不會被拆分。業務規劃不足、無效資料的堆積以及訪問量的突增等因素，均會使執行個體產生大Key與熱Key，如：

類別	原因
大Key	在不適用的情境下使用Tair和Redis，易造成Key的value過大，如使用String類型的Key存放大體積二進位檔案型資料；業務上線前規劃設計不足，沒有對Key中的成員進行合理的拆分，造成個別Key中的成員數量過多；未定期清理無效資料，造成如HASH類型Key中的成員持續不斷地增加；使用LIST類型Key的業務消費側發生代碼故障，造成對應Key的成員只增不減。
熱Key	預期外的訪問量陡增，如突然出現的爆款商品、訪問量暴漲的熱點新聞、直播間某主播搞活動帶來的大量刷屏點贊、遊戲中某地區發生多個工會之間的戰鬥涉及大量玩家等。

大Key和熱Key帶來的影響

類別	影響
大Key	用戶端執行命令的時間長度變慢。執行個體記憶體達到maxmemory上限時，可能導致操作阻塞、重要Key被逐出，甚至記憶體溢出（OOM）。叢集架構下，某個資料分區的記憶體使用量率遠超其他資料分區，無法使資料分區的記憶體資源達到均衡。對大Key執行讀請求，會使執行個體的頻寬使用率被佔滿，導致自身服務變慢，同時易波及相關的服務。對大Key執行刪除操作，易造成主庫較長時間的阻塞，進而可能引發同步中斷或主備切換。
熱Key	佔用大量的CPU資源，同時可能增加網路頻寬的使用，進而影響其他請求並導致整體效能降低。叢集架構下，產生訪問傾斜，即某個資料分區被大量訪問，而其他資料分區處於空閑狀態，可能引起該資料分區的串連數被耗盡，新的串連建立請求被拒絕等問題。在搶購或秒殺情境下，可能因商品對應庫存Key的請求量過大，超出執行個體處理能力造成超賣。熱Key的請求壓力數量超出執行個體的承受能力，容易造成緩衝擊穿，即大量請求將被直接指向後端的儲存層，導致儲存訪問量激增甚至宕機，從而影響其他業務。

預防策略

策略	說明
監控警示設定	設定合理的CPU、記憶體、串連數使用率等警示閾值進行警示，例如記憶體使用量率超過70%、記憶體在1小時內增長率超過20%等。出現警示時，按照本文步驟一和步驟二的指引定位並最佳化大Key和熱Key，在其發展到影響業務之前解決。
使用Tair（企業版）避開失效資料的清理工作	針對hash類型的大key情境，Tair（企業版）提供了增強型資料結構 TairHash。它支援為每個 field 設定到期時間和版本。通過合理使用 TairHash，可以顯著減少營運負擔、簡化業務代碼複雜度，並有效應對大 Key 和熱 Key 帶來的問題。