如何找出最佳化大Key與熱Key,產生的原因和問題 - Tair (Redis® OSS-Compatible)

在使用Tair (Redis OSS-compatible)執行個體的過程中，如果未能及時發現並處理Big keys（下文稱為“大Key”）與Hotkeys（下文稱為“熱Key”），可能會導致服務效能下降、使用者體驗變差，甚至引發大面積故障。本文將介紹大Key與熱Key產生的原因、其可能引發的問題及如何快速找出大Key與熱Key並將其最佳化的方案。

大Key和熱Key的定義

Key類型	統計排名機制
大Key	支援的資料類型 Redis原生資料結構：String、List、Hash、Set、Zset、Stream。 Tair自研資料結構：TairString、TairHash、TairGIS、TairBloom、TairDoc、TairCpc、TairZset、TairRoaring、TairTS、TairSearch。大Key（元素數量多的Key）統計閾值：2000（字串長度或元素數量）。大Key容量：每個主節點3個。如果執行個體為叢集架構或讀寫分離架構，系統會展示每個資料分區或唯讀節點中，每種資料類型排名前3的Key。統計規則：根據Key中的字串長度（僅String類型）或元素數量進行排序。 Key的大小不同時，按順序取前3個到達閾值的Key。 Key的大小相同時，先進入統計的Key排序靠前。大Key（佔用記憶體大的Key）統計閾值：單個元素大於50 KB或者整個Object大於500 MB。大Key容量：每個主節點3個。如果執行個體為叢集架構或讀寫分離架構，系統會展示每個資料分區或唯讀節點中，每種資料類型排名前3的Key。統計規則：根據Key的記憶體佔用大小進行排序（參考MEMORY USAGE命令）。 Key的大小不同時，按順序取前3個到達閾值的Key。 Key的大小相同時，按字串字典序排序。說明長時間未操作過的Key可能不會被統計，您可以通過離線全量Key分析功能瞭解關於大Key的更多資訊，例如Key的記憶體佔有情況、Key的數量分布情況、Key中元素的記憶體佔用和分布情況、Key到期時間分布等資訊。更多資訊請參見離線全量Key分析。
熱Key	以最近最少使用演算法LRU（Least Recently Used）為基礎，經過高效的排序以及統計演算法識別出當前執行個體的熱點Key。說明在更新版本至Tair社區版7.0.18、6.0.2.9、5.5.2.9或Tair記憶體型5.0.50版本及以上時：在同一時間支援最多統計50個熱點Key（在上述版本之前，Tair社區版僅支援統計20個熱點Key）。當某個Key的QPS大於5,000時會被記錄為熱點Key（在上述版本之前，當Key的QPS大於3,000時即會被記錄為熱點Key）。支援展示熱點Key的精確QPS（在上述版本之前，僅支援在熱點Key的QPS小於6000時展示大致的QPS範圍）。

說明

上述為即時Top Key統計功能中大Key和熱Key的統計排名機制，在實際業務中，您需要根據執行個體的實際業務情境進行綜合判斷。

大Key和熱Key引發的問題

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

大Key和熱Key產生的原因

未正確使用Tair (Redis OSS-compatible)、業務規劃不足、無效資料的堆積、訪問量突增等都會產生大Key與熱Key，如：

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

快速找出大Key和熱Key

Tair (Redis OSS-compatible)提供多種方案協助您輕鬆找出大Key與熱Key。

方法	優缺點	說明
即時Top Key統計（推薦）	優點：準確性高、對效能幾乎無影響。缺點：展示的Key數量有一定限制，但能滿足常規情境下的需求。	可即時展示執行個體中的大Key和熱Key資訊，同時支援查看4天內大Key和熱Key的歷史資訊。該功能可協助您掌握Key在記憶體中的佔用、Key的訪問頻次等資訊，溯源分析問題，為您的最佳化操作提供資料支援。
離線全量Key分析	優點：可對歷史備份資料進行分析，對線上服務無影響。缺點：時效性差，RDB檔案較大時耗時較長。	對RDB備份檔案進行定製化的分析，協助您發現執行個體中的大Key，掌握Key在記憶體中的佔用和分布、Key到期時間等資訊，為您的最佳化操作提供資料支援，協助您避免因Key傾斜引發的記憶體不足、效能下降等問題。
通過redis-cli的bigkeys和hotkeys參數尋找大Key和熱Key	優點：方便、快速、安全。缺點：分析結果不可定製化，準確性與時效性差。	redis-cli提供了bigkeys與hotkeys參數能夠以遍曆的方式分析執行個體中的所有Key，並返回Key的整體統計資訊與每個資料類型中Top1的大Key。以bigkeys為例，其僅能分析並輸入六種資料類型（STRING、LIST、HASH、SET、ZSET、STREAM），命令樣本為`redis-cli -h r-***************.redis.rds.aliyuncs.com -a <password> --bigkeys`。說明若您只需要分析STRING類型的大key或是找出成員數量超過10個的HASH Key，則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快照檔案的開源工具。您可以根據您的精細化需求，全面地分析執行個體中所有Key的記憶體佔用情況，同時也支援靈活地分析查詢。
通過MONITOR命令找出熱Key	優點：方便、安全。缺點：會佔用CPU、記憶體、網路資源，時效性與準確性較差。	MONITOR命令能夠忠實地列印執行個體中的所有請求，包括時間資訊、Client資訊、命令以及Key資訊。在發生緊急情況時，可以通過短暫執行MONITOR命令並將返回資訊輸入至檔案，在關閉MONITOR命令後，對檔案中請求進行歸類分析，找出這段時間中的熱Key。說明由於MONITOR命令對執行個體效能消耗較大，非特殊情況不推薦使用MONITOR命令。

最佳化大Key與熱Key

類別	處理方法
大Key	對大Key進行拆分例如將含有數萬成員的一個HASH Key拆分為多個HASH Key，並確保每個Key的成員數量在合理範圍。在叢集架構中，拆分大Key能對資料分區間的記憶體平衡起到顯著作用。對大Key進行清理將不適用資料存至其它儲存，並在執行個體中刪除此類資料。說明 Redis開源版4.0及之後版本：您可以通過UNLINK命令安全地刪除大Key甚至特大Key，該命令能夠以非阻塞的方式，逐步地清理傳入的Key。 Redis開源版4.0之前的版本：建議先通過SCAN命令讀取部分資料，然後進行刪除，避免一次性刪除大量key導致Redis阻塞。監控執行個體的記憶體水位您可以通過監控系統設定合理的記憶體警示閾值進行提醒，例如記憶體使用量率超過70%、記憶體在1小時內增長率超過20%等。通過此類監控手段，可以提前規避許多問題，例如LIST資料類型的消費程式故障造成對應Key的列表數量持續增長，將警示轉變為預警從而避免故障的發生，更多資訊，請參見警示設定。對到期資料進行定期清理堆積大量到期資料會造成大Key的產生，例如在HASH資料類型中以增量的形式不斷寫入大量資料而忽略了資料的時效性。可以通過定時任務的方式對失效資料進行清理。說明在清理HASH資料時，建議通過HSCAN命令配合HDEL命令對失效資料進行清理，避免清理大量資料造成執行個體阻塞。使用阿里雲的Tair（企業版）避開失效資料的清理工作若HASH Key過多，存在大量的成員失效需要被清理的問題，又由於大量Key與大量失效資料疊加，無法通過定時任務對無效資料進行及時地清理，您可以通過阿里雲Tair服務高效地解決此類問題。 Tair具備Redis開源版所有特性（包括Redis開源版的高效能特點），同時提供了大量額外的進階功能。 TairHash是一種可為field設定到期時間和版本的Hash資料類型，它不但和Redis Hash一樣支援豐富的資料介面和高處理效能，還改變了Hash只能為Key設定到期時間的限制，可以為field設定到期時間和版本。這極大地提高了Hash資料類型的靈活性，簡化了很多情境下的業務開發工作。同時，TairHash使用高效的Active Expire演算法，實現了在對回應時間幾乎無影響的前提下，高效完成對field到期判斷和刪除的功能。此類進階功能的合理使用能夠解放大量Redis開源版的營運、故障處理工作並降低業務的代碼複雜度，更多資訊，請參見exHash。
熱Key	在叢集架構中對熱Key進行複製在叢集架構中，由於熱Key的遷移粒度問題，無法將請求分散至其他資料分區，導致單個資料分區的壓力無法下降。此時，可以將對應熱Key進行複製並遷移至其他資料分區，例如將熱Key foo複製出3個內容完全一樣的Key併名為foo2、foo3、foo4，將這三個Key遷移到其他資料分區來解決單個資料分區的熱Key壓力。說明該方案的缺點在於需要聯動修改代碼，同時帶來了資料一致性的挑戰（由原來更新一個Key演變為需要更新多個Key），僅建議該方案用來解決臨時棘手的問題。使用讀寫分離架構如果熱Key的產生來自於讀請求，您可以將執行個體改造成讀寫分離架構來降低每個資料分區的讀請求壓力，甚至可以不斷地增加從節點。但是讀寫分離架構在增加業務代碼複雜度的同時，也會增加叢集架構複雜度。不僅要為多個從節點提供轉寄層（如Proxy，LVS等）來實現負載平衡，還要考慮從節點數量顯著增加後帶來故障率增加的問題。叢集架構變更會為監控、營運、故障處理帶來了更大的挑戰。然而，阿里雲Tair (Redis OSS-compatible)服務以開箱即用的方式提供服務。在業務發生變化時，您僅需通過變更配置的方式調整執行個體架構來輕鬆應對，例如將主從架構轉變為讀寫分離架構、將讀寫分構架構轉變為叢集架構，以及將Redis開源版轉變為支援大量進階特性的Tair（企業版）等，更多資訊，請參見變更執行個體配置。說明讀寫分離架構同樣存在缺點，在請求量極大的情境下，讀寫分離架構會產生不可避免的延遲，此時會有讀取到髒資料的問題。因此，在讀、寫壓力都較大且對資料一致性要求很高的情境下，讀寫分離架構並不是最優方案。使用QueryCache特性 Tair (Redis OSS-compatible)會根據高效的排序和統計演算法識別出執行個體中存在的熱點Key（通常熱點Key的QPS大於5,000），開啟該功能後，代理節點Proxy會根據設定的規則緩衝熱點Key的請求和查詢結果（僅緩衝熱點Key的查詢結果，無需緩衝整個Key）。當在緩衝有效時間內收到相同的請求時，Proxy會直接返回結果至用戶端，無需和後端的資料分區執行互動。如果熱點Key的查詢結果發生改變，緩衝不會更新。開通該功能後，來自用戶端的同樣請求無需再與Proxy後端資料節點進行互動而是由Proxy直接返回資料，指向熱Key的請求由一個資料節點承擔轉為多個Proxy共同承擔，能夠大幅度降低資料節點的熱Key壓力。同時Tair的QueryCache功能還提供了大量的命令來方便您查看、管理代理程式查詢快取的情況，例如通過querycache keys命令查看所有被緩衝熱Key，通過querycache listall命令擷取所有已緩衝的所有命令等。更多資訊，請參見通過Proxy Query Cache最佳化熱點Key問題。