大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信息，同時支持查看4天內大Key和熱Key的歷史信息。該功能可幫助您掌握Key在內存中的占用、Key的訪問頻次等信息，溯源分析問題，為您的優化操作提供數據支持。 |
離線全量Key分析 | | 對Tair的RDB備份文件進行定制化的分析，幫助您發現實例中的大Key，掌握Key在內存中的占用和分布、Key過期時間等信息，為您的優化操作提供數據支持，幫助您避免因Key傾斜引發的內存不足、性能下降等問題。 |
通過redis-cli的bigkeys和hotkeys參數查找大Key和熱Key | 優點：方便、快速、安全。 缺點：分析結果不可定制化，準確性與時效性差。
| redis-cli提供了bigkeys與hotkeys參數能夠以遍歷的方式分析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參數無法直接實現該類需求。 |
通過Tair內置命令對目標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 | | 通過在業務層增加相應的代碼對Tair的訪問進行記錄并異步匯總分析。 |
通過redis-rdb-tools工具以定制化方式找出大Key | 優點：支持定制化分析，對線上服務無影響。 缺點：時效性差，RDB文件較大時耗時較長。
| Redis-rdb-tools是通過Python編寫，支持定制化分析RDB快照文件的開源工具。您可以根據您的精細化需求，全面地分析Tair實例中所有Key的內存占用情況，同時也支持靈活地分析查詢。 |
通過MONITOR命令找出熱Key | | Tair的MONITOR命令能夠忠實地打印Tair中的所有請求，包括時間信息、Client信息、命令以及Key信息。 在發生緊急情況時，可以通過短暫執行MONITOR命令并將返回信息輸入至文件，在關閉MONITOR命令后，對文件中請求進行歸類分析，找出這段時間中的熱Key。
說明 由于MONITOR命令對Tair實例性能消耗較大，非特殊情況不推薦使用MONITOR命令。 |
優化大Key與熱Key
類別 | 處理方法 |
大Key | 對大Key進行拆分 例如將含有數萬成員的一個HASH Key拆分為多個HASH Key，并確保每個Key的成員數量在合理范圍。在集群架構中，拆分大Key能對數據分片間的內存平衡起到顯著作用。 對大Key進行清理 將不適用Tair能力的數據存至其它存儲，并在Tair中刪除此類數據。 監控Tair的內存水位 您可以通過監控系統設置合理的Tair內存報警閾值進行提醒，例如Tair內存使用率超過70%、Tair的內存在1小時內增長率超過20%等。通過此類監控手段，可以提前規避許多問題，例如LIST數據類型的消費程序故障造成對應Key的列表數量持續增長，將告警轉變為預警從而避免故障的發生，更多信息，請參見報警設置。 對過期數據進行定期清理 堆積大量過期數據會造成大Key的產生，例如在HASH數據類型中以增量的形式不斷寫入大量數據而忽略了數據的時效性。可以通過定時任務的方式對失效數據進行清理。
說明 在清理HASH數據時，建議通過HSCAN命令配合HDEL命令對失效數據進行清理，避免清理大量數據造成Tair阻塞。 使用阿里云的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開源版轉變為支持大量高級特性的Tair（企業版）等，更多信息，請參見變更實例配置。
說明 讀寫分離架構同樣存在缺點，在請求量極大的場景下，讀寫分離架構會產生不可避免的延遲，此時會有讀取到臟數據的問題。因此，在讀、寫壓力都較大且對數據一致性要求很高的場景下，讀寫分離架構并不是最優方案。 使用阿里云Tair的QueryCache特性 云數據庫 Tair（兼容 Redis）會根據高效的排序和統計算法識別出實例中存在的熱點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問題。
|