當我們需要遍歷redis所有key或者指定模式的key時,首先想到的是keys命令:
keys pattern
keys 的速度非常快,例如,redis在乙個有1百萬個key的資料庫裡面執行一次查詢需要的時間是40毫秒 。但在乙個大的資料庫中使用它仍然可能造成效能問題,如果你需要從乙個資料集中查詢特定的keys
, 你最好還是用 redis 的集合結構
sets
來代替。
keys命令使用很簡單。
但由於keys命令一次性返回所有匹配的key,所以,當redis中的key非常多時,對於記憶體的消耗和redis伺服器都是乙個隱患,
redis> mset one
1 two
2 three
3 four 4ok
redis> keys *o*
1) 「four」
2) 「one」
3) 「two」
redis> keys t??
1) 「two」
redis> keys *
1) 「four」
2) 「three」
3) 「one」
4) 「two」
redis>
對於redis 2.8以上版本給我們提供了乙個更好的遍歷key的命令 scan 該命令的基本格式:
scan
cursor
[match pattern]
[count count]
scan
每次執行都只會返回少量元素,所以可以用於生產環境,而不會出現像 keys 或者 smembers 命令帶來的可能會阻塞伺服器的問題。
scan命令是乙個基於游標的迭代器。這意味著命令每次被呼叫都需要使用上一次這個呼叫返回的游標作為該次呼叫的游標引數,以此來延續之前的迭代過程
當scan命令的游標引數(即cursor)被設定為 0 時, 伺服器將開始一次新的迭代, 而當伺服器向使用者返回值為 0 的游標時, 表示迭代已結束。
簡單的迭代演示:
在上面這個例子中, 第一次迭代使用 0 作為游標, 表示開始一次新的迭代。第二次迭代使用的是第一次迭代時返回的游標 17 ,作為新的迭代引數 。
redis 127
.0.0.1
:6379>
scan 0
1) 「17」
2) 1) 「
key:12」
2) 「
key:8」
3) 「
key:4」
4) 「
key:14」
5) 「
key:16」
6) 「
key:17」
7) 「
key:15」
8) 「
key:10」
9) 「
key:3」
10) 「
key:7」
11) 「
key:1」
redis 127
.0.0.1
:6379>
scan 17
1) 「0」
2) 1) 「
key:5」
2) 「
key:18」
3) 「
key:0」
4) 「
key:2」
5) 「
key:19」
6) 「
key:13」
7) 「
key:6」
8) 「
key:9」
9) 「
key:11」
顯而易見,scan命令的返回值 是乙個包含兩個元素的陣列, 第乙個陣列元素是用於進行下一次迭代的新游標, 而第二個陣列元素則又是乙個陣列, 這個陣列中包含了所有被迭代的元素。
注意:返回的游標不一定是遞增的,可能後一次返回的游標比前一次的小。
在第二次呼叫 scan 命令時, 命令返回了游標 0 , 這表示迭代已經結束, 整個資料集已經被完整遍歷過了。
full iteration :以 0 作為游標開始一次新的迭代, 一直呼叫 scan 命令, 直到命令返回游標 0 , 我們稱這個過程為一次完整遍歷。
scan增量式迭代命令並不保證每次執行都返回某個給定數量的元素,甚至可能會返回零個元素, 但只要命令返回的游標不是 0 , 應用程式就不應該將迭代視作結束。
不過命令返回的元素數量總是符合一定規則的, 對於乙個大資料集來說, 增量式迭代命令每次最多可能會返回數十個元素;而對於乙個足夠小的資料集來說,可能會一次迭代返回所有的key
對於增量式迭代命令不保證每次迭代所返回的元素數量,我們可以使用count選項, 對命令的行為進行一定程度上的調整。count 選項的作用就是讓使用者告知迭代命令, 在每次迭代中應該從資料集裡返回多少元素。使用count 選項對於對增量式迭代命令相當於一種提示, 大多數情況下這種提示都比較有效的控制了返回值的數量。
注意:count選項並不能嚴格控制返回的key數量,只能說是乙個大致的約束。並非每次迭代都要使用相同的 count 值,使用者可以在每次迭代中按自己的需要隨意改變 count 值, 只要記得將上次迭代返回的游標用到下次迭代裡面就可以了。
類似於keys 命令,增量式迭代命令通過給定 match 引數的方式實現了通過提供乙個 glob 風格的模式引數, 讓命令只返回和給定模式相匹配的元素。
match 選項對元素的模式匹配工作是在命令從資料集中取出元素後和向客戶端返回元素前的這段時間內進行的, 所以如果被迭代的資料集中只有少量元素和模式相匹配, 那麼迭代命令或許會在多次執行中都不返回任何元素。
以下是這種情況的乙個例子:
可以看出,以上的大部分迭代都不返回任何元素。在最後一次迭代, 我們通過將 count 選項的引數設定為 1000 , 強制命令為本次迭代掃瞄更多元素, 從而使得命令返回的元素也變多了。
redis 127
.0.0.1
:6379>
scan 0
match *11*
1) 「288」
2) 1) 「
key:911」
redis 127
.0.0.1
:6379>
scan 288
match *11*
1) 「224」
2) (
empty
list
orset)
redis 127
.0.0.1
:6379>
scan 224
match *11*
1) 「80」
2) (
empty
list
orset)
redis 127
.0.0.1
:6379>
scan 80
match *11*
1) 「176」
2) (
empty
list
orset)
redis 127
.0.0.1
:6379>
scan 176
match *11*
count 1000
1) 「0」
2) 1) 「
key:611」
2) 「
key:711」
3) 「
key:118」
4) 「
key:117」
5) 「
key:311」
6) 「
key:112」
7) 「
key:111」
8) 「
key:110」
9) 「
key:113」
10) 「
key:211」
11) 「
key:411」
12) 「
key:115」
13) 「
key:116」
14) 「
key:114」
15) 「
key:119」
16) 「
key:811」
17) 「
key:511」
18) 「
key:11」
redis 127
.0.0.1
:6379>
基於scan的這種安全性,建議大家在生產環境都使用scan命令來代替keys,不過注意,該命令是在2.8.0版本之後加入的,如果你的redis低於這個版本,則需要公升級redis。
下面用php**演示scan命令的使用:
<?php
redis使用ttl檢視key 鍵 的生存時間
ttl key 以秒為單位,返回給定 key 的剩餘生存時間 ttl,time to live 可用版本 1.0.0時間複雜度 o 1 返回值 當 key 不存在時,返回 2 當 key 存在但沒有設定剩餘生存時間時,返回 1 否則,以秒為單位,返回 key 的剩餘生存時間。在 redis 2.8 ...
redis使用ttl檢視key 鍵 的生存時間
ttl key 以秒為單位,返回給定 key 的剩餘生存時間 ttl,time to live 可用版本 1.0.0時間複雜度 o 1 返回值 當 key 不存在時,返回 2 當 key 存在但沒有設定剩餘生存時間時,返回 1 否則,以秒為單位,返回 key 的剩餘生存時間。在 redis 2.8 ...
檢視程序所消耗的記憶體
在舊版的作業系統中,可以在 windows 任務管理器中檢視每個程序消耗記憶體的情況。windows server 2008及後續產品有一些區別。預設情況下,windows 任務管理器僅顯示 記憶體 專用工作集 列。記憶體 專用工作集 是這個程序獨佔的物理記憶體。每個程序都有 閒 和 忙 的時候,忙...