前言
Redis中有一個經典的問題，在巨大的數據量的情況下，做類似于查找符合某種規則的Key的信息，這里就有兩種方式，
一是keys命令，簡單粗暴，由于Redis單線程這一特性，keys命令是以阻塞的方式執行的，keys是以遍歷的方式實現的復雜度是 O(n），Redis庫中的key越多，查找實現代價越大，產生的阻塞時間越長。
二是scan命令，以非阻塞的方式實現key值的查找，絕大多數情況下是可以替代keys命令的，可選性更強
以下寫入100000條key***：value***格式的測試數據（ps：用pipline的話,1w一筆，每一筆在秒級完成）
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
# -*- coding: utf-8 -*-# !/usr/bin/env python3import redisimport sysimport datetimedef create_testdata(): r = redis.StrictRedis(host='***.***.***.***', port=****, db=0, password='root') counter = 0 with r.pipeline(transaction=False) as p: for i in range(0, 100000): p.set('key' + str(i), "value" + str(i)) counter = counter + 1 if (counter == 10000): p.execute() counter = 0 print("set by pipline loop")if __name__ == "__main__": create_testdata() |
比如這里查詢key111開頭的key有哪些？
若使用keys命令，則執行keys key1111*，一次性全部查出來。
同樣，如果使用scan命令，則用scan 0 match key1111* count 20
scan的語法為：SCAN cursor [MATCH pattern] [COUNT count]The default COUNT value is 10.
SCAN命令是一個基于游標的迭代器。這意味著命令每次被調用都需要使用上一次這個調用返回的游標作為該次調用的游標參數，以此來延續之前的迭代過程。
這里使用scan 0 match key1111* count 20命令來完成這個查詢，稍顯意外的是，使用一開始都沒有查詢到結果，這個要從scan命令的原理來看。
scan在遍歷key的時候，0就代表第一次，key1111*代表按照key1111開頭的模式匹配，count 20中的20并不是代表輸出符合條件的key，而是限定服務器單次遍歷的字典槽位數量(約等于)。
那么，什么又叫做槽的數據？這個槽是不是Redis集群中的slot？答案是否定的。其實上圖已經給出了答案了。
如果上面說的“字典槽”的數量是集群中的slot，又知道集群中的slot數量是16384，那么遍歷16384個槽之后，必然能遍歷出來所有的key信息，上面清楚地看到，當遍歷的字典槽的數量20000的時候，游標依舊沒有走完遍歷結果，因此這個字典槽并不等于集群中的slot的概念。
經過測試，在scan的時候，究竟遍歷多大的COUNT值能完全match到符合條件的key，跟具體對象的key的個數有關，
如果以超過key個數的count來scan，必定會一次性就查找到所有符合條件的key，比如在key個數為10W個的情況下，一次遍歷20w個字典槽，肯定能完全遍歷出來結果。
scan 指令是一系列指令，除了可以遍歷所有的 key 之外，還可以對指定的容器集合進行遍歷。
zscan 遍歷 zset 集合元素，
hscan 遍歷 hash 字典的元素、
sscan 遍歷 set 集合的元素。
SSCAN 命令、 HSCAN 命令和 ZSCAN 命令的第一個參數總是一個數據庫鍵（某個指定的key）。
另外，使用redis desktop manager的時候，當刷新某個庫的時候，控制臺自動不斷刷新scan命令，也就知道它在干嘛了
參考：http://jinguoxing.github.io/redis/2018/09/04/redis-scan/
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對服務器之家的支持。
原文鏈接：https://www.cnblogs.com/wy123/p/10955153.html
