大Key和熱Key

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的歷史資訊。
對線上服務幾乎無影響。

離線全量Key分析

磁碟型執行個體不支援該功能。

對RDB備份檔案進行定製化的分析，得出Key在記憶體中的佔用和分布、Key到期時間等資訊。
對線上服務無影響。
時效性差，RDB檔案較大時耗時較長。
無法分析熱Key資訊。

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

其他方法找出大Key和熱Key

方法	優缺點	說明
通過redis-cli的bigkeys、memkeys和hotkeys參數尋找大Key和熱Key	優點：方便、快速、安全。缺點：分析結果不可定製化，準確性與時效性差；需要遍曆執行個體當前所有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	對大Key進行壓縮	建議在資料寫入緩衝前，通過序列化或壓縮演算法減少大Key的儲存空間。若壓縮後仍過大，可進一步拆分Key。
	對大Key進行拆分	例如將含有數萬成員的一個HASH Key拆分為多個HASH Key，並確保每個Key的成員數量在合理範圍。拆分大Key能有效避免資料扭曲。
	對大Key進行清理	將不適用資料存至其它儲存，並在執行個體中刪除此類資料。說明 Redis開源版4.0及之後版本：您可以通過UNLINK命令安全地刪除大Key甚至特大Key，該命令通過非同步方式清理 Key，避免阻塞主線程。 Redis開源版4.0之前的版本：建議先通過SCAN命令讀取部分資料，然後進行刪除，避免一次性刪除大量key導致主線程阻塞。
	對到期資料進行定期清理	堆積大量到期資料會造成大Key的產生，例如在HASH資料類型中，由於忽略資料時效性，可能會以增量形式不斷寫入大量資料。可以通過定時任務的方式對失效資料進行清理。說明在清理HASH資料時，建議通過HSCAN命令配合HDEL命令對失效資料進行清理，避免清理大量資料造成執行個體阻塞。
熱Key	在叢集架構中對熱Key進行複製	由於熱Key作為整體儲存在單一分區，無法通過遷移部分資料分散請求，導致單個資料分區的壓力無法下降。此時，可以將對應熱Key進行複製並遷移至其他資料分區，例如將熱Key foo複製出3個內容完全一樣的Key並命名為foo2、foo3、foo4，將這三個Key遷移到其他資料分區來解決單個資料分區的熱Key壓力。說明該方案的缺點是需修改代碼維護多個副本，且多副本間的資料一致性難以保障（例如更新操作需同步所有副本）。建議將該方案作為臨時解決方案，用於緩解棘手問題。
	開啟讀寫分離功能	若熱Key由讀請求引起，您可以開啟讀寫分離功能來降低每個資料分區的讀請求負載，如果開啟後讀請求負載依舊很高，可通過增加唯讀節點數量進一步緩解讀請求負載。說明讀寫分離同樣存在缺點，在請求量極大的情境下，讀寫分離會產生不可避免的延遲，此時會出現讀取到髒資料的問題。因此，在讀、寫壓力都較大且對資料一致性要求很高的情境下，不推薦開啟讀寫分離。
	開啟QueryCache功能	開啟該功能後，Tair和Redis會根據演算法識別出熱Key（通常熱Key的QPS大於5,000），代理節點Proxy會緩衝熱Key的請求和查詢結果（僅緩衝點Key的查詢結果，無需緩衝整個Key）。當在緩衝有效時間內收到相同的請求時，Proxy會直接返回結果至用戶端，無需和後端的資料分區執行互動。更多資訊，請參見通過Proxy Query Cache最佳化熱點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的請求壓力數量超出執行個體的承受能力，容易造成緩衝擊穿，即大量請求將被直接指向後端的儲存層，導致儲存訪問量激增甚至宕機，從而影響其他業務。

如何預防大Key和熱Key影響業務

方法	說明

方法	說明
配置監控警示	您可以通過監控系統設定合理的CPU、記憶體、串連數使用率等警示閾值進行警示，例如記憶體使用量率超過70%、記憶體在1小時內增長率超過20%等。出現警示時，根據上文內容找到並最佳化大Key和熱Key，在其發展到影響業務之前解決。更多資訊，請參見警示設定。
使用Tair（企業版）避開失效資料的清理工作	針對hash類型的大key情境，Tair（企業版）提供了增強型資料結構 TairHash。它支援為每個 field 設定到期時間和版本，突破了 Redis Hash 僅能為整個 Key 設定到期時間的限制。同時，TairHash 使用高效的 Active Expire 演算法，在幾乎不影響回應時間的情況下完成field的到期判斷與刪除操作。通過合理使用 TairHash，可以顯著減少營運負擔、簡化業務代碼複雜度，並有效應對大 Key 和熱 Key 帶來的問題。