Key類型

統(tǒng)計排名機制

大Key

• 支持的數(shù)據(jù)類型

  • Redis原生數(shù)據(jù)結(jié)構(gòu)：String、List、Hash、Set、Zset、Stream。

  • Tair自研數(shù)據(jù)結(jié)構(gòu)：TairString、TairHash、TairGIS、TairBloom、TairDoc、TairCpc、TairZset、TairRoaring、TairTS、TairSearch。

• 大Key（元素數(shù)量多的Key）

  • 統(tǒng)計閾值：2000（字符串長度或元素數(shù)量）。

  • 大Key容量：每個主節(jié)點3個。如果實例為集群架構(gòu)或讀寫分離架構(gòu)，系統(tǒng)會展示每個數(shù)據(jù)分片或只讀節(jié)點中，每種數(shù)據(jù)類型排名前3的Key。

  • 統(tǒng)計規(guī)則：

    • 根據(jù)Key中的字符串長度（僅String類型）或元素數(shù)量進行排序。

    • Key的大小不同時，按順序取前3個到達閾值的Key。

    • Key的大小相同時，先進入統(tǒng)計的Key排序靠前。

• 大Key（占用內(nèi)存大的Key）

  • 統(tǒng)計閾值：單個元素大于50 KB或者整個Object大于500 MB。

  • 大Key容量：每個主節(jié)點3個。如果實例為集群架構(gòu)或讀寫分離架構(gòu)，系統(tǒng)會展示每個數(shù)據(jù)分片或只讀節(jié)點中，每種數(shù)據(jù)類型排名前3的Key。

  • 統(tǒng)計規(guī)則：

    • 根據(jù)Key的內(nèi)存占用大小進行排序（參考MEMORY USAGE命令）。

    • Key的大小不同時，按順序取前3個到達閾值的Key。

    • Key的大小相同時，按字符串字典序排序。

熱Key

以最近最少使用算法LRU（Least Recently Used）為基礎(chǔ)，經(jīng)過高效的排序以及統(tǒng)計算法識別出當(dāng)前實例的熱點Key。

類別

說明

大Key

• 客戶端執(zhí)行命令的時長變慢。

• 實例的內(nèi)存達到maxmemory參數(shù)定義的上限引發(fā)操作阻塞或重要的Key被逐出，甚至引發(fā)內(nèi)存溢出（Out Of Memory）。

• 集群架構(gòu)下，某個數(shù)據(jù)分片的內(nèi)存使用率遠超其他數(shù)據(jù)分片，無法使數(shù)據(jù)分片的內(nèi)存資源達到均衡。

• 對大Key執(zhí)行讀請求，會使實例的帶寬使用率被占滿，導(dǎo)致自身服務(wù)變慢，同時易波及相關(guān)的服務(wù)。

• 對大Key執(zhí)行刪除操作，易造成主庫較長時間的阻塞，進而可能引發(fā)同步中斷或主從切換。

熱Key

• 占用大量的CPU資源，影響其他請求并導(dǎo)致整體性能降低。

• 集群架構(gòu)下，產(chǎn)生訪問傾斜，即某個數(shù)據(jù)分片被大量訪問，而其他數(shù)據(jù)分片處于空閑狀態(tài)，可能引起該數(shù)據(jù)分片的連接數(shù)被耗盡，新的連接建立請求被拒絕等問題。

• 在搶購或秒殺場景下，可能因商品對應(yīng)庫存Key的請求量過大，超出實例處理能力造成超賣。

• 熱Key的請求壓力數(shù)量超出實例的承受能力易造成緩存擊穿，即大量請求將被直接指向后端的存儲層，導(dǎo)致存儲訪問量激增甚至宕機，從而影響其他業(yè)務(wù)。

方法

優(yōu)缺點

說明

實時Top Key統(tǒng)計（推薦）

• 優(yōu)點：準確性高、對性能幾乎無影響。

• 缺點：展示的Key數(shù)量有一定限制，但能滿足常規(guī)場景下的需求。

可實時展示實例中的大Key和熱Key信息，同時支持查看4天內(nèi)大Key和熱Key的歷史信息。該功能可幫助您掌握Key在內(nèi)存中的占用、Key的訪問頻次等信息，溯源分析問題，為您的優(yōu)化操作提供數(shù)據(jù)支持。

離線全量Key分析

• 優(yōu)點：可對歷史備份數(shù)據(jù)進行分析，對線上服務(wù)無影響。

• 缺點：時效性差，RDB文件較大時耗時較長。

對RDB備份文件進行定制化的分析，幫助您發(fā)現(xiàn)實例中的大Key，掌握Key在內(nèi)存中的占用和分布、Key過期時間等信息，為您的優(yōu)化操作提供數(shù)據(jù)支持，幫助您避免因Key傾斜引發(fā)的內(nèi)存不足、性能下降等問題。

通過redis-cli的bigkeys和hotkeys參數(shù)查找大Key和熱Key

• 優(yōu)點：方便、快速、安全。

• 缺點：分析結(jié)果不可定制化，準確性與時效性差。

通過內(nèi)置命令對目標Key進行分析

• 優(yōu)點：方便、對線上服務(wù)影響小。

• 缺點：返回的Key序列化長度并不等同于它在內(nèi)存空間中的真實長度，因此不夠準確，僅可作為參考。

對不同數(shù)據(jù)類型的目標Key，分別通過如下風(fēng)險較低的命令進行分析，來判斷目標Key是否符合大Key判定標準。

• STRING類型：執(zhí)行STRLEN命令，返回對應(yīng)Key的value的字節(jié)數(shù)。

• LIST類型：執(zhí)行LLEN命令，返回對應(yīng)Key的列表長度。

• HASH類型：執(zhí)行HLEN命令，返回對應(yīng)Key的成員數(shù)量。

• SET類型：執(zhí)行SCARD命令，返回對應(yīng)Key的成員數(shù)量。

• ZSET類型：執(zhí)行ZCARD命令，返回對應(yīng)Key的成員數(shù)量。

• STREAM類型：執(zhí)行XLEN命令，返回對應(yīng)Key的成員數(shù)量。

通過業(yè)務(wù)層定位熱Key

• 優(yōu)點：可準確并及時地定位熱Key。

• 缺點：業(yè)務(wù)代碼復(fù)雜度的增加，同時可能會降低一些性能。

通過在業(yè)務(wù)層增加相應(yīng)的代碼對實例的訪問進行記錄并異步匯總分析。

通過redis-rdb-tools工具以定制化方式找出大Key

• 優(yōu)點：支持定制化分析，對線上服務(wù)無影響。

• 缺點：時效性差，RDB文件較大時耗時較長。

Redis-rdb-tools是通過Python編寫，支持定制化分析RDB快照文件的開源工具。您可以根據(jù)您的精細化需求，全面地分析實例中所有Key的內(nèi)存占用情況，同時也支持靈活地分析查詢。

通過MONITOR命令找出熱Key

• 優(yōu)點：方便、安全。

• 缺點：會占用CPU、內(nèi)存、網(wǎng)絡(luò)資源，時效性與準確性較差。

MONITOR命令能夠忠實地打印實例中的所有請求，包括時間信息、Client信息、命令以及Key信息。

在發(fā)生緊急情況時，可以通過短暫執(zhí)行MONITOR命令并將返回信息輸入至文件，在關(guān)閉MONITOR命令后，對文件中請求進行歸類分析，找出這段時間中的熱Key。

類別

處理方法

大Key

• 對大Key進行拆分

  例如將含有數(shù)萬成員的一個HASH Key拆分為多個HASH Key，并確保每個Key的成員數(shù)量在合理范圍。在集群架構(gòu)中，拆分大Key能對數(shù)據(jù)分片間的內(nèi)存平衡起到顯著作用。

• 對大Key進行清理

  將不適用數(shù)據(jù)存至其它存儲，并在實例中刪除此類數(shù)據(jù)。

  說明

  • Redis開源版4.0及之后版本：您可以通過UNLINK命令安全地刪除大Key甚至特大Key，該命令能夠以非阻塞的方式，逐步地清理傳入的Key。

  • Redis開源版4.0之前的版本：建議先通過SCAN命令讀取部分數(shù)據(jù)，然后進行刪除，避免一次性刪除大量key導(dǎo)致Redis阻塞。

• 監(jiān)控實例的內(nèi)存水位

  您可以通過監(jiān)控系統(tǒng)設(shè)置合理的內(nèi)存報警閾值進行提醒，例如內(nèi)存使用率超過70%、內(nèi)存在1小時內(nèi)增長率超過20%等。通過此類監(jiān)控手段，可以提前規(guī)避許多問題，例如LIST數(shù)據(jù)類型的消費程序故障造成對應(yīng)Key的列表數(shù)量持續(xù)增長，將告警轉(zhuǎn)變?yōu)轭A(yù)警從而避免故障的發(fā)生，更多信息，請參見報警設(shè)置。

• 對過期數(shù)據(jù)進行定期清理

  堆積大量過期數(shù)據(jù)會造成大Key的產(chǎn)生，例如在HASH數(shù)據(jù)類型中以增量的形式不斷寫入大量數(shù)據(jù)而忽略了數(shù)據(jù)的時效性。可以通過定時任務(wù)的方式對失效數(shù)據(jù)進行清理。

  說明

  在清理HASH數(shù)據(jù)時，建議通過HSCAN命令配合HDEL命令對失效數(shù)據(jù)進行清理，避免清理大量數(shù)據(jù)造成實例阻塞。

• 使用阿里云的Tair（企業(yè)版）避開失效數(shù)據(jù)的清理工作

  若HASH Key過多，存在大量的成員失效需要被清理的問題，又由于大量Key與大量失效數(shù)據(jù)疊加，無法通過定時任務(wù)對無效數(shù)據(jù)進行及時地清理，您可以通過阿里云Tair服務(wù)高效地解決此類問題。

  Tair具備Redis開源版所有特性（包括Redis開源版的高性能特點），同時提供了大量額外的高級功能。

  TairHash是一種可為field設(shè)置過期時間和版本的Hash數(shù)據(jù)類型，它不但和Redis Hash一樣支持豐富的數(shù)據(jù)接口和高處理性能，還改變了Hash只能為Key設(shè)置過期時間的限制，可以為field設(shè)置過期時間和版本。這極大地提高了Hash數(shù)據(jù)類型的靈活性，簡化了很多場景下的業(yè)務(wù)開發(fā)工作。同時，TairHash使用高效的Active Expire算法，實現(xiàn)了在對響應(yīng)時間幾乎無影響的前提下，高效完成對field過期判斷和刪除的功能。

  此類高級功能的合理使用能夠解放大量Redis開源版的運維、故障處理工作并降低業(yè)務(wù)的代碼復(fù)雜度，更多信息，請參見exHash。

熱Key

• 在集群架構(gòu)中對熱Key進行復(fù)制

  在集群架構(gòu)中，由于熱Key的遷移粒度問題，無法將請求分散至其他數(shù)據(jù)分片，導(dǎo)致單個數(shù)據(jù)分片的壓力無法下降。此時，可以將對應(yīng)熱Key進行復(fù)制并遷移至其他數(shù)據(jù)分片，例如將熱Key foo復(fù)制出3個內(nèi)容完全一樣的Key并名為foo2、foo3、foo4，將這三個Key遷移到其他數(shù)據(jù)分片來解決單個數(shù)據(jù)分片的熱Key壓力。

  說明

  該方案的缺點在于需要聯(lián)動修改代碼，同時帶來了數(shù)據(jù)一致性的挑戰(zhàn)（由原來更新一個Key演變?yōu)樾枰露鄠€Key），僅建議該方案用來解決臨時棘手的問題。

• 使用讀寫分離架構(gòu)

  如果熱Key的產(chǎn)生來自于讀請求，您可以將實例改造成讀寫分離架構(gòu)來降低每個數(shù)據(jù)分片的讀請求壓力，甚至可以不斷地增加從節(jié)點。但是讀寫分離架構(gòu)在增加業(yè)務(wù)代碼復(fù)雜度的同時，也會增加集群架構(gòu)復(fù)雜度。不僅要為多個從節(jié)點提供轉(zhuǎn)發(fā)層（如Proxy，LVS等）來實現(xiàn)負載均衡，還要考慮從節(jié)點數(shù)量顯著增加后帶來故障率增加的問題。集群架構(gòu)變更會為監(jiān)控、運維、故障處理帶來了更大的挑戰(zhàn)。

  然而，阿里云云數(shù)據(jù)庫 Tair（兼容 Redis）服務(wù)以開箱即用的方式提供服務(wù)。在業(yè)務(wù)發(fā)生變化時，您僅需通過變配的方式調(diào)整實例架構(gòu)來輕松應(yīng)對，例如將主從架構(gòu)轉(zhuǎn)變?yōu)樽x寫分離架構(gòu)、將讀寫分構(gòu)架構(gòu)轉(zhuǎn)變?yōu)榧杭軜?gòu)，以及將Redis開源版轉(zhuǎn)變?yōu)橹С执罅扛呒壧匦缘?span data-tag="ph" id="b888b6efb6tha" docid="2259849" class="ph">Tair（企業(yè)版）等，更多信息，請參見變更實例配置。

  說明

  讀寫分離架構(gòu)同樣存在缺點，在請求量極大的場景下，讀寫分離架構(gòu)會產(chǎn)生不可避免的延遲，此時會有讀取到臟數(shù)據(jù)的問題。因此，在讀、寫壓力都較大且對數(shù)據(jù)一致性要求很高的場景下，讀寫分離架構(gòu)并不是最優(yōu)方案。

• 使用QueryCache特性

  云數(shù)據(jù)庫 Tair（兼容 Redis）會根據(jù)高效的排序和統(tǒng)計算法識別出實例中存在的熱點Key（通常熱點Key的QPS大于5,000），開啟該功能后，代理節(jié)點Proxy會根據(jù)設(shè)定的規(guī)則緩存熱點Key的請求和查詢結(jié)果（僅緩存熱點Key的查詢結(jié)果，無需緩存整個Key）。當(dāng)在緩存有效時間內(nèi)收到相同的請求時，Proxy會直接返回結(jié)果至客戶端，無需和后端的數(shù)據(jù)分片執(zhí)行交互。如果熱點Key的查詢結(jié)果發(fā)生改變，緩存不會更新。

  開通該功能后，來自客戶端的同樣請求無需再與Proxy后端數(shù)據(jù)節(jié)點進行交互而是由Proxy直接返回數(shù)據(jù)，指向熱Key的請求由一個數(shù)據(jù)節(jié)點承擔(dān)轉(zhuǎn)為多個Proxy共同承擔(dān)，能夠大幅度降低數(shù)據(jù)節(jié)點的熱Key壓力。同時Tair的QueryCache功能還提供了大量的命令來方便您查看、管理代理查詢緩存的情況，例如通過querycache keys命令查看所有被緩存熱Key，通過querycache listall命令獲取所有已緩存的所有命令等。更多信息，請參見通過Proxy Query Cache優(yōu)化熱點Key問題。