日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

公告:魔扣目錄網為廣大站長提供免費收錄網站服務,提交前請做好本站友鏈:【 網站目錄:http://www.ylptlb.cn 】, 免友鏈快審服務(50元/站),

點擊這里在線咨詢客服
新站提交
  • 網站:51998
  • 待審:31
  • 小程序:12
  • 文章:1030137
  • 會員:747

在處理大型數據時,redis 作為我們的非關系型數據庫經常出現在解決方案之中。然而,在使用 Redis 的過程中,有一些問題可能會悄無聲息地影響我們的系統性能,其中最具代表性的就是 Big Key 問題。

這個問題往往被低估,Big Key會對 Redis 的效率和整體性能產生重大影響。在本文中,我們將深入探索 Big Key 問題的源頭,討論它如何影響系統性能,并提供相應的解決策略。通過了解和解決 Big Key 問題,我們可以更有效地利用 Redis,優化我們的系統并提高性能。

Redis中的Big Key問題:排查與解決思路

一、Big Key問題介紹

在Redis中,每個key都有一個對應的value,如果某個key的value過大,就會導致Redis的性能下降或者崩潰。

因為Redis需要將大key全部加載到內存中,這會占用大量的內存空間,會降低Redis的響應速度,這個問題被稱為Big Key問題。

不要小看這個問題,它可是能讓你的Redis瞬間變成“烏龜”,由于Redis單線程的特性,操作Big Key的通常比較耗時,也就意味著Big Key阻塞Redis的可能性很大,這樣會造成客戶端阻塞或者引起故障切換,有可能導致“慢查詢”或其他連鎖反應。

一般而言,下面這兩種情況可以被稱為Big Key:

  • String 類型的 key 對應的value超過 10 MB。
  • list、set、hash、zset等集合類型,集合元素個數超過 5000個。

以上對Big Key的判斷標準并不唯一,只是一個大體的標準。在實際業務開發中,對Big Key的判斷是需要根據具體的使用場景做不同的判斷。比如操作某個 key 導致請求響應時間變慢,那么這個 key 就可以判定成 Big Key。

在Redis中,Big Key通常是由以下幾種原因導致的:

  • 對象序列化后的大小過大。
  • 存儲大量數據的容器,如set、list等。
  • 大型數據結構,如bitmap、hyperloglog等。

如果不及時處理這些大key,它們會逐漸消耗Redis服務器的內存資源,最終導致Redis崩潰。

二、Big Key問題排查

當出現Redis性能急劇下降的情況時,很可能是由于存在大key導致的。在排除大key問題時,可以考慮采取以下幾種方法:

1.BIGKEYS命令

Redis自帶的 BIGKEYS 命令可以查詢當前Redis中所有key的信息,對整個數據庫中的鍵值對大小情況進行統計分析。

比如說,統計每種數據類型的鍵值對個數以及平均大小。

此外,這個命令執行后,會輸出每種數據類型中最大的 big key 的信息,對于 String 類型來說,會輸出最大 big key 的字節長度,對于集合類型來說,會輸出最大 big key 的元素個數。

BIGKEYS命令會掃描整個數據庫,這個命令本身會阻塞Redis,找出所有的大鍵,并將其以一個列表的形式返回給客戶端。

命令格式如下:

$ redis-cli --bigkeys

返回示例如下:

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).

[00.00%] Biggest string found so far 'a' with 3 bytes
[05.14%] Biggest list   found so far 'b' with 100004 items
[35.77%] Biggest string found so far 'c' with 6 bytes
[73.91%] Biggest hash   found so far 'd' with 3 fields

-------- summary -------

Sampled 506 keys in the keyspace!
Total key length in bytes is 3452 (avg len 6.82)

Biggest string found 'c' has 6 bytes
Biggest   list found 'b' has 100004 items
Biggest   hash found 'd' has 3 fields

504 strings with 1403 bytes (99.60% of keys, avg size 2.78)
1 lists with 100004 items (00.20% of keys, avg size 100004.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
1 hashs with 3 fields (00.20% of keys, avg size 3.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

解讀下返回結果,從這個結果中可以看出:

  • Redis中樣本了506個鍵。
  • 這506個鍵總共占用了3452字節,平均每個鍵占用6.82字節。
  • 最大的字符串鍵是'c',值有6字節。
  • 最大的列表鍵是'b',有100004個元素。
  • 最大的哈希鍵是'd',有3個字段。
  • 有504個字符串鍵,總共1403字節,占所有鍵的99.60%,平均每個字符串鍵大小為2.78字節。
  • 有1個列表鍵,包含100004個元素,占所有鍵的0.20%,平均每個列表鍵大小為100004個元素。
  • 沒有集合(set)鍵。
  • 有1個哈希鍵,包含3個字段,占所有鍵的0.20%,平均每個哈希鍵大小為3個字段。
  • 沒有有序集合(zset)鍵。

這些信息可以幫助你理解Redis數據庫的使用狀態,以便進行相應的優化或調整。

需要注意的是,由于BIGKEYS命令需要掃描整個數據庫,所以它可能會對Redis實例造成一定的負擔。在執行這個命令之前,請確保你的Redis實例有足夠的資源來處理它,建議在從節點執行。

2.Debug Object

如果我們找到了Big Key,就需要對其進行進一步的分析。我們可以使用命令debug object key查看某個key的詳細信息,包括該key的value大小等。這時候你就可以“窺探”Redis的內部,看看到底是哪個key太大導致的問題。

Debug Object 命令是一個調試命令,當 key 存在時,返回有關信息。當 key 不存在時,返回一個錯誤。

redis 127.0.0.1:6379> DEBUG OBJECT key
Value at:0xb6838d20 refcount:1 encoding:raw serializedlength:9 lru:283790 lru_seconds_idle:150

redis 127.0.0.1:6379> DEBUG OBJECT key
(error) ERR no such key

第一次運行命令時,返回了 key 對應的具體信息。這些值的意思如下:

  • Value at:0xb6838d20:key 所在的內存地址。
  • refcount:1:引用計數,表示該對象被引用的次數。
  • encoding:raw:編碼類型,這里是 raw ,表示這個字符串對象的編碼類型。
  • serializedlength:9:序列化后的長度。
  • lru:283790:LRU (Least Recently Used)信息,即最近最少使用算法的相關信息,在內存淘汰策略中會用到。
  • lru_seconds_idle:150:該 key 已空閑多久(單位為秒),也就是自從最后一次訪問已經過去多少秒。

第二次運行命令時,返回了 (error) ERR no such key,說明在 Redis 中沒有找到名為 'key' 的鍵。

3.memory usage

在Redis4.0之前,只能通過DEBUG OBJECT命令估算key的內存使用(字段serializedlength),但DEBUG OBJECT命令是存在誤差的。

4.0版本及以上,更推薦使用memory usag命令。

memory usage命令使用非常簡單,格式為:memory usage key。

如果當前key存在,則返回key的value實際使用內存估算值,如果key不存在,則返回nil。

127.0.0.1:6379> set k1 value1
OK
127.0.0.1:6379> memory usage k1    //這里k1 value占用57字節內存
(integer) 57
127.0.0.1:6379> memory usage aaa  // aaa鍵不存在,返回nil.
(nil)

對于除String類型之外的類型,memory usage命令采用抽樣的方式,默認抽樣5個元素,所以計算是近似值,我們也可以手動指定抽樣的個數。

示例說明:生成一個100w個字段的hash鍵:hkey,每字段的value長度是從1~1024字節的隨機值。

127.0.0.1:6379> hlen hkey    // hkey有100w個字段,每個字段的value長度介于1~1024個字節
(integer) 1000000
127.0.0.1:6379> MEMORY usage hkey   //默認SAMPLES為5,分析hkey鍵內存占用521588753字節
(integer) 521588753
127.0.0.1:6379> MEMORY usage hkey SAMPLES  1000 //指定SAMPLES為1000,分析hkey鍵內存占用617977753字節
(integer) 617977753
127.0.0.1:6379> MEMORY usage hkey SAMPLES  10000 //指定SAMPLES為10000,分析hkey鍵內存占用624950853字節
(integer) 624950853

要想獲取key較精確的內存值,就指定更大抽樣個數。但是抽樣個數越大,占用cpu時間分片就越大。

4.redis-rdb-tools

redis-rdb-tools 是一個 Python/ target=_blank class=infotextkey>Python 的解析 rdb 文件的工具,在分析內存的時候,我們主要用它生成內存快照。可以把 rdb 快照文件生成 CSV 或 JSON 文件,也可以導入到 MySQL 生成報表來分析。

使用 PYPI 安裝:

pip install rdbtools

生成內存快照:

rdb -c memory dump.rdb > memory.csv

在生成的 CSV 文件中主要有以下幾列:

  • database key在Redis的db
  • type key類型
  • key key值
  • size_in_bytes key的內存大小
  • encoding value的存儲編碼形式
  • num_elements key中的value的個數
  • len_largest_element key中的value的長度

可以在MySQL中新建表然后導入進行分析,然后可以直接通過SQL語句進行查詢分析。

CREATE TABLE `memory` (
     `database` int(128) DEFAULT NULL,
     `type` varchar(128) DEFAULT NULL,
     `KEY` varchar(128),
     `size_in_bytes` bigint(20) DEFAULT NULL,
     `encoding` varchar(128) DEFAULT NULL,
     `num_elements` bigint(20) DEFAULT NULL,
     `len_largest_element` varchar(128) DEFAULT NULL,
     PRIMARY KEY (`KEY`)
 );

例如,查詢內存占用最高的3個 key:

mysql> SELECT * FROM memory ORDER BY size_in_bytes DESC LIMIT 3;
+----------+------+-----+---------------+-----------+--------------+---------------------+
| database | type | key | size_in_bytes | encoding  | num_elements | len_largest_element |
+----------+------+-----+---------------+-----------+--------------+---------------------+
|        0 | set  | k1  |        624550 | hashtable |        50000 | 10                  |
|        0 | set  | k2  |        420191 | hashtable |        46000 | 10                  |
|        0 | set  | k3  |        325465 | hashtable |        38000 | 10                  |
+----------+------+-----+---------------+-----------+--------------+---------------------+
3 rows in set (0.12 sec)

三、Big Key問題解決思路

當發現存在Big Key問題時,我們需要及時采取措施來解決這個問題。下面列出幾種可行的解決思路:

1.分割大key

將Big Key拆分成多個小key。這個方法比較簡單,但是需要修改應用程序的代碼。就像是把一個大蛋糕切成小蛋糕一樣,有點費力,但是可以解決問題。

或者嘗試將Big Key轉換成Redis的其他數據結構。例如,將Big Key轉換成Hash,List或者Set等數據結構。

2.對象壓縮

如果大key的產生原因主要是由于對象序列化后的體積過大,我們可以考慮使用壓縮算法來減小對象的大小。需要在客戶端使用一些壓縮算法對數據進行壓縮和解壓縮操作,例如LZF、SnAppy等。

3.直接刪除

如果你使用的是Redis 4.0+的版本,可以直接使用 unlink命令去異步刪除大key。4.0以下的版本 可以考慮使用 scan命令,分批次刪除。

無論采用哪種方法,日常使用中都需要注意以下幾點:

  • 避免使用過大的value。如果需要存儲大量的數據,可以將其拆分成多個小的value。就像是吃飯一樣,一口一口的吃,不要貪多嚼不爛。
  • 避免使用不必要的數據結構。例如,如果只需要存儲一個字符串,就不要使用Hash或者List等數據結構。
  • 定期清理過期的key。如果Redis中存在大量的過期key,就會導致Redis的性能下降。就像是家里的垃圾,需要定期清理。
  • 對象壓縮。

最后,結束本文時,我們要明確的是,Redis Big Key問題是所有使用Redis作為數據存儲方案的開發者都需要密切關注的重要話題。大Key可能會對Redis的性能產生嚴重影響,或者導致意外的內存問題。

因此,開發者應該充分利用現有的工具和策略來檢測和避免Big Key。在使用Redis時,需要注意避免使用過大的value和不必要的數據結構,以及定期清理過期的key。

另外,我們還應持續探索更高效、更可靠的解決方案,來優化我們的Redis實例,使其更穩定地為我們的應用提供服務。最后,不斷學習和實踐才是提高我們對Redis使用的理解,并準確處理Redis Big Key問題的最佳方式。

分享到:
標簽:Redis
用戶無頭像

網友整理

注冊時間:

網站:5 個   小程序:0 個  文章:12 篇

  • 51998

    網站

  • 12

    小程序

  • 1030137

    文章

  • 747

    會員

趕快注冊賬號,推廣您的網站吧!
最新入駐小程序

數獨大挑戰2018-06-03

數獨一種數學游戲,玩家需要根據9

答題星2018-06-03

您可以通過答題星輕松地創建試卷

全階人生考試2018-06-03

各種考試題,題庫,初中,高中,大學四六

運動步數有氧達人2018-06-03

記錄運動步數,積累氧氣值。還可偷

每日養生app2018-06-03

每日養生,天天健康

體育訓練成績評定2018-06-03

通用課目體育訓練成績評定