如何發現並處理大Key和熱Key - Tair

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

大Key和熱Key的定義

重要

下述例子中的具體數值僅供參考，在實際業務中，您需要根據執行個體的實際業務情境進行綜合判斷。

名詞

解釋

舉例

大Key

通常以Key的大小和Key中成員的數量來綜合判定。

Key本身的資料量過大。例如，一個String類型的Key，它的值為5 MB。
Key中的成員數過多。例如，一個ZSET類型的Key，它的成員數量為10,000個。
Key中成員的資料量過大。例如，一個Hash類型的Key，它的成員數量雖然只有2,000個但這些成員的Value（值）總大小為100 MB。

熱Key

通常以其接收到的Key被請求頻率來判定。

QPS集中在特定的Key。例如，Tair執行個體的總QPS（每秒查詢率）為10,000，而其中一個Key的每秒訪問量達到了7,000。
頻寬使用率集中在特定的Key。例如，對一個擁有上千個成員且總大小為1 MB的HASH Key每秒發送大量的HGETALL操作請求。
CPU使用時間佔比集中在特定的Key。例如，對一個擁有數萬個成員的Key（ZSET類型）每秒發送大量的ZRANGE操作請求。

大Key和熱Key引發的問題

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

大Key和熱Key產生的原因

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

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

快速找出大Key和熱Key

Tair提供多種方案協助您輕鬆找出大Key與熱Key。

方法	優缺點	說明
即時Top Key統計（推薦）	優點：準確性高、對效能幾乎無影響。缺點：展示的Key數量有一定限制，但能滿足常規情境下的需求。	可即時展示執行個體中的大Key和熱Key資訊，同時支援查看4天內大Key和熱Key的歷史資訊。該功能可協助您掌握Key在記憶體中的佔用、Key的訪問頻次等資訊，溯源分析問題，為您的最佳化操作提供資料支援。
離線全量Key分析	優點：可對歷史備份資料進行分析，對線上服務無影響。缺點：時效性差，RDB檔案較大時耗時較長。	對Tair的RDB備份檔案進行定製化的分析，協助您發現執行個體中的大Key，掌握Key在記憶體中的佔用和分布、Key到期時間等資訊，為您的最佳化操作提供資料支援，協助您避免因Key傾斜引發的記憶體不足、效能下降等問題。
通過redis-cli的bigkeys和hotkeys參數尋找大Key和熱Key	優點：方便、快速、安全。缺點：分析結果不可定製化，準確性與時效性差。	Redis原生工具提供了bigkeys參數能夠使redis-cli以遍曆的方式分析Tair執行個體中的所有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參數無法直接實現該類需求。同時，自Redis 4.0版本起提供了hotkeys參數，可以快速幫您找出業務中的熱Key，命令樣本為：`redis-cli -h r-*************.redis.rds.aliyuncs.com -a <password> --hotkeys`。
通過Redis內建命令對目標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)，有阻塞Tair執行個體的風險，不建議使用。
通過業務層定位熱Key	優點：可準確並及時地定位熱Key。缺點：業務代碼複雜度的增加，同時可能會降低一些效能。	通過在業務層增加相應的代碼對Tair的訪問進行記錄並非同步匯總分析。
通過redis-rdb-tools工具以定製化方式找出大Key	優點：支援定製化分析，對線上服務無影響。缺點：時效性差，RDB檔案較大時耗時較長。	Redis-rdb-tools是通過Python編寫，支援定製化分析Tair RDB快照檔案的開源工具。您可以根據您的精細化需求，全面地分析Tair執行個體中所有Key的記憶體佔用情況，同時也支援靈活地分析查詢。
通過MONITOR命令找出熱Key	優點：方便、安全。缺點：會佔用CPU、記憶體、網路資源，時效性與準確性較差。	MONITOR命令能夠忠實地列印Tair中的所有請求，包括時間資訊、Client資訊、命令以及Key資訊。在發生緊急情況時，可以通過短暫執行MONITOR命令並將返回資訊輸入至檔案，在關閉MONITOR命令後，對檔案中請求進行歸類分析，找出這段時間中的熱Key。說明由於MONITOR命令對Tair執行個體效能消耗較大，非特殊情況不推薦使用MONITOR命令。

最佳化大Key與熱Key

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