一 面試題引入

• 阿里廣告平臺，海量數(shù)據(jù)里查詢某一固定前綴的key。
• 小紅書，你如何在生產(chǎn)上限制keys * / flushdb / flushall等危險命令以防止誤刪誤用？
• 美團：MEMORY USAGE 命令你用過嗎？
• BigKey 問題，多大算big，如何發(fā)現(xiàn)，如何刪除，如何處理？
• BigKey 你做過調優(yōu)嗎？惰性釋放lazyfree了解過嗎？
• Morekey問題，生產(chǎn)上redis數(shù)據(jù)庫有1000W記錄，該如何遍歷？key*可以嗎？

二 MoreKey案例

2.1 大批量往redis里面插入2000W測試數(shù)據(jù)key

2.1.1 Linux Bash下執(zhí)行，插入100W

for((i=1;i<=100*10000;i++)); do echo "set K$i V$i" >> /tmp/redisTest.txt ; done; 

2.1.2 通過redis提供的管道 --pipe命令插入100W大批量數(shù)據(jù)

cat /tmp/redisTest.txt | /opt/redis-7.0.0/src/redis-cli -h 127.0.0.1 -p 6379 -a 111111 --pipe

2.2 key *

key * 這個指令有致命的弊端，在實際環(huán)境中最好不要使用

這個指令沒有offset、limit參數(shù)，是要一次性吐出所有滿足條件的key，由于redis是單線程的，其所有操作都是原子的，而keys算法是遍歷算法，復雜度是O(n)，如果實例中有千萬級以上的key，這個指令就會導致Redis服務卡頓，所有讀寫Redis的其它的指令都會被延后甚至會超時報錯，可能會引起緩存雪崩甚至數(shù)據(jù)庫宕機。

2.3 生產(chǎn)上如何限制keys*/flushdb/flushall等危險命令以防止誤刪誤用？

通過配置設置禁用這些命令，redis.conf在SECURITY這一項中：

2.4 不用keys * 不滿卡頓，那該用什么？

2.4.1 scan命令

類似mysql limit ，但不完全相同。
Redis SCAN命令及其相關命令 SSCAN，HSCAN，ZSCAN命令都是用于增量遍歷集合中的元素。

• SCAN：用于迭代當前數(shù)據(jù)庫中的數(shù)據(jù)庫鍵
• SSCAN：用于迭代集合鍵中的元素
• HSCAN：用于迭代哈希鍵中的鍵值對
• ZSCAN：用于迭代有序集合中的元素（包括元素成員和元素分值）

2.4.2 scan命令用于迭代數(shù)據(jù)庫中的數(shù)據(jù)庫鍵

redis SCAN 命令基本語法如下：

SCAN cousor [MATCH pattern] [COUNT count]

• cursor：游標
• pattern：匹配的模式
• count：指定從數(shù)據(jù)集里返回多少元素，默認值是10

基于游標的迭代器，需要基于上一次的游標延續(xù)之前的迭代過程以0作為游標開始一次新的迭代，直到命令返回游標0完成一次遍歷，不保證每次執(zhí)行都返回某個給定數(shù)量的元素，支持模糊查詢。一次返回的數(shù)量不可控，只能是大概率符合count參數(shù)。

• SCAN命令是一個基于游標的迭代器，每次被調用之后，都會想用戶返回一個新的游標，用戶在下次迭代時需要使用這個新游標作為SCAN命令的游標參數(shù)，以此來延續(xù)之前的迭代過程。
• SCAN返回一個包含兩個元素的數(shù)組
  • 第一個元素：用于進行下一次迭代的新游標
  • 第二個元素：是一個數(shù)組，這個數(shù)組中包含了所有被迭代的元素。如果新游標返回零表示迭代已結束。

SCAN的遍歷順序：非常特別，它不是從第一維數(shù)組的第零位一直遍歷到末尾，而是采用了高位進位加法來遍歷，之所以使用這樣特殊的方式進行遍歷，是考慮到字典的擴容和縮容時避免槽位的遍歷重復和遺漏。

三 BigKey

3.1 多大算Big

• 阿里云Redis開發(fā)規(guī)范：

拒絕bigkey（防止網(wǎng)卡流量，慢查詢）
string類型控制在10KB以內，hash、list、set、zset元素個數(shù)不要超過5000。
非字符串的bigkey，不要使用del刪除，使用hscan、sscan、zscan方式漸進式刪除，同時要注意防止bigkey過期時間自動刪除問題（例如一個200萬的zset設置1小時過期，會觸發(fā)del操作，造成阻塞，而且該操作不會出現(xiàn)在慢查詢中（latency可查））。

• string和二級結構
  • string是value，最大512MB 但是大于10KB就是bigkey。
  • list/hash/set和zset，個數(shù)超過5000就是bigkey 

    

3.2 bigkey的危害

• 內存不均，集群遷移困難
• 超時刪除，大key刪除作梗
• 網(wǎng)絡流量阻塞

3.3 如何產(chǎn)生

• 社交類：典型案例粉絲逐步遞增
• 匯總統(tǒng)計：某個報表，月日年的積累

3.4 如何發(fā)現(xiàn)

• redis-cli --bigkeys

  • 好處：給出每種數(shù)據(jù)結構Top 1 bigkey，同時給出每種數(shù)據(jù)類型的鍵值個數(shù) + 平均大小
  • 不足：想查詢大于10KB的所有key，–bigkeys參數(shù)就無能為力了。需要用到memory usage來計算每個鍵值的字節(jié)數(shù)

• MOMROY USAGE ：給出一個key和它的值在RAM中所占用的字節(jié)數(shù)（計算每個鍵值的字節(jié)數(shù)）。

3.5 如何刪除

非字符串的bigkey，不要使用del刪除，使用hscan、sscan、zscan方式漸進式刪除。

• string：一般用del，如果過于龐大使用unlink
• hash：使用hscan每次獲取少量field-value，再使用hdel刪除每個field

list：使用ltrim漸進式逐步刪除，直到全部刪除完成。

Ltrim對一個列表進行修剪（trim），就是說，讓列表只保留指定區(qū)域內的元素，不在指定區(qū)間之內的元素都將被刪除。下標0表示列表的第一個元素，以1表示列表的第二個元素，以此類推。也可以使用負數(shù)下標，以-1表示列表的最后一個元素，-2表示列表的倒數(shù)第二個元素，以此類推。
語法：LTRIM key_NAME START STOP

set：使用sscan每次獲取部分元素，再使用srem命令刪除每個元素

zset：使用zscan每次獲取部分元素，再使用ZREMRANGEBYRANK命令刪除每個元素

四 BigKey生產(chǎn)調優(yōu)

在redis.conf配置文件LAZY FREEING相關說明：

到此這篇關于Redis如何解決BigKey的文章就介紹到這了,更多相關Redis BigKey內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！ 

最新評論