大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：執行個體的總QPS（每秒查詢率）為10,000，而其中一個Key的每秒訪問量達到了7,000。 頻寬使用率集中在特定的Key：對一個擁有上千個成員且總大小為1 MB的HASH Key每秒發送大量的HGETALL操作請求。 CPU使用時間佔比集中在特定的Key：對一個擁有數萬個成員的Key（ZSET類型）每秒發送大量的ZRANGE操作請求。
|
說明 上述例子中的具體數值僅供參考，在實際業務中，您需要根據執行個體的實際業務情境進行綜合判斷。
大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資訊，同時支援查看4天內大Key和熱Key的歷史資訊。該功能可協助您掌握Key在記憶體中的佔用、Key的訪問頻次等資訊，溯源分析問題，為您的最佳化操作提供資料支援。 |
離線全量Key分析 | | 對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判定標準。 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 | | 通過在業務層增加相應的代碼對執行個體的訪問進行記錄並非同步匯總分析。 |
通過redis-rdb-tools工具以定製化方式找出大Key | 優點：支援定製化分析，對線上服務無影響。 缺點：時效性差，RDB檔案較大時耗時較長。
| Redis-rdb-tools是通過Python編寫，支援定製化分析RDB快照檔案的開源工具。您可以根據您的精細化需求，全面地分析執行個體中所有Key的記憶體佔用情況，同時也支援靈活地分析查詢。 |
通過MONITOR命令找出熱Key | | MONITOR命令能夠忠實地列印執行個體中的所有請求，包括時間資訊、Client資訊、命令以及Key資訊。 在發生緊急情況時，可以通過短暫執行MONITOR命令並將返回資訊輸入至檔案，在關閉MONITOR命令後，對檔案中請求進行歸類分析，找出這段時間中的熱Key。
說明 由於MONITOR命令對執行個體效能消耗較大，非特殊情況不推薦使用MONITOR命令。 |
最佳化大Key與熱Key
類別 | 處理方法 |
大Key | 對大Key進行拆分 例如將含有數萬成員的一個HASH Key拆分為多個HASH Key，並確保每個Key的成員數量在合理範圍。在叢集架構中，拆分大Key能對資料分區間的記憶體平衡起到顯著作用。 對大Key進行清理 將不適用資料存至其它儲存，並在執行個體中刪除此類資料。 監控執行個體的記憶體水位 您可以通過監控系統設定合理的記憶體警示閾值進行提醒，例如記憶體使用量率超過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問題。
|