redis的安裝和簡單使用

循例介紹一下了,redis是內存數據庫,是簡單的key-value結構,也是nosql數據庫,由於結構簡單,並且用的是內存,因此速度很是之快.至於問有多快?你們知道之前的機械硬盤,單盤速度其實也還好,而內存的讀寫速度是機械硬盤的6萬倍.因此,redis比硬盤有多快,可見一斑了.固然如今都用固態硬盤,狀況仍是比之前好很多的.這裏再也不詳細類比,知道是這回事就好.

安裝

================================

好了,固然先說安裝了,安裝redis很簡單,先說明,咱們服務器都是linux.

首先要說明一下,內存數據庫並不表明徹底不用硬盤空間,由於通常爲了數據安全,配置上會備份必定數據到硬盤的,因此仍是得準備必定的硬盤空間.

下載地址:

wget "http://download.redis.io/releases/redis-3.2.0.tar.gz"

是編譯版本,如今都出到3.2了,不過版本差別不大,低版本只是不支持集羣或主從而已,實際上功能沒差.

安裝時有依賴包提示就記得yum下,通常就C語言庫相關的,這些大部分在初始化系統就必須裝上的了.

下面來看安裝方法,很簡單:

#解壓編譯包
tar xzf redis-3.2.0.tar.gz
#進入解壓後的文件夾
cd redis-3.2.0
#編譯安裝
make
make install
#順便說說,若是你想安裝在自定義目錄也是能夠的
make prefix=(你的目錄) install

當make install命令執行完成後，會在/usr/local/bin目錄下生成幾個可執行文件，它們的做用以下：

redis-server：    Redis服務器的daemon啓動程序

redis-cli：       Redis命令行操做工具。也能夠用telnet根據其純文本協議來操做

redis-benchmark： Redis性能測試工具，測試Redis在當前系統下的讀寫性能

redis-check-aof： 數據修復

redis-check-dump：檢查導出工具 

安裝完了,就要看配置了,配置文件名能夠隨便改,位置也不固定要放什麼位置,由於啓動的時候能夠指定配置文件啓動.

還記得編譯目錄嗎?裏面就有配置文件模板,複製過來就能夠用了,固然了,按照你本身的需求改一下仍是有必要的,

cd redis-3.2.0
ll *.conf
-rw-rw-r-- 1 root root 45390 May  6 15:11 redis.conf
-rw-rw-r-- 1 root root  7109 May  6 15:11 sentinel.conf

一個是redis的配置文件,一個是哨兵,屬於redis集羣應用的配置文件

配置太多,咱們先看一些重點:

cat redis.conf
#容許後臺運行
daemonize  yes
#設置端口,最好是非默認端口
port 6666
#綁定登陸IP,安全考慮,最好是內網
bind 10.10.2.21
#命名並指定當前redis的PID路徑,用以區分多個redis
pidfile /data/redis/data/config/redis_6666.pid
#命名並指定當前redis日誌文件路徑
logfile "/data/redis/data/logs/redis_6666.log"
#指定RDB文件名,用以備份數據到硬盤並區分不一樣redis,當使用內存超過可用內存的45%時觸發快照功能
dbfilename dump_6666.rdb
#指定當前redis的根目錄,用來存放RDB/AOF文件
dir /data/redis/data
#當前redis的認證密鑰,redis運行速度很是快,這個密碼要足夠強大
requirepass gggggggGGGGGGGGG999999999
#當前redis的最大容量限制,建議設置爲可用內存的45%內,最高能設置爲系統可用內存的95%
#可用config set maxmemory 去在線修改,但重啓失效,須要使用config rewrite命令去刷新配置文件
maxmemory 1024000000
#LRU的策略,有四種,看狀況選擇
maxmemory-policy allkeys-lru
#關閉自動持久化操做,默認狀況下RDB自動持久化是開啓的,會定時自動壓縮保存redis的全量數據.
#因爲redis是單線程操做的,這個操做無疑比較耗費資源並阻塞操做,有些只作緩存的環境也不見得數據有多重要.
#save ""
#默認狀況下AOF持久化方式是關閉的,須要手動開啓,和RDB各有特色,相對RDB沒那麼阻塞操做.
#appendonly yes
#在開啓AOF以後,須要設置下面兩個參數,避免AOF文件不斷增大,影響後續操做.
#auto-aof-rewrite-percentage 100
#auto-aof-rewrite-min-size 64mb

詳細解析以下:

-----------------------------------------------------------------------------------

1 daemonize  no

默認狀況下，redis 不是在後臺運行的，若是須要在後臺運行，把該項的值更改成yes。

2 pidfile  /var/run/redis.pid

當Redis 在後臺運行的時候，Redis 默認會把pid 文件放在/var/run/redis.pid，你能夠配置到其餘地址。當運行多個redis 服務時，須要指定不一樣的pid 文件和端口

3 port

監聽端口，默認爲6379

4 #bind 127.0.0.1

指定Redis 只接收來自於該IP 地址的請求，若是不進行設置，那麼將處理全部請求，在生產環境中爲了安全最好設置該項。默認註釋掉，不開啓

5 timeout 0

設置客戶端鏈接時的超時時間，單位爲秒。當客戶端在這段時間內沒有發出任何指令，那麼關閉該鏈接

6 tcp-keepalive 0

指定TCP鏈接是否爲長鏈接,"偵探"信號有server端維護。默認爲0.表示禁用

7 loglevel notice

log 等級分爲4 級，debug,verbose, notice, 和warning。生產環境下通常開啓notice

8 logfile stdout

配置log 文件地址，默認使用標準輸出，即打印在命令行終端的窗口上，修改成日誌文件目錄

9 databases 16

設置數據庫的個數，可使用SELECT 命令來切換數據庫。默認使用的數據庫是0號庫。默認16個庫

10 

save 900 1

save 300 10

save 60 10000

rdb自動持久化參數,保存數據快照的頻率，即將數據持久化到dump.rdb文件中的頻度。用來描述"在多少秒期間至少多少個變動操做"觸發snapshot數據保存動做,

    默認設置，意思是：

    if(在60 秒以內有10000 個keys 發生變化時){

    進行鏡像備份

    }else if(在300 秒以內有10 個keys 發生了變化){

    進行鏡像備份

    }else if(在900 秒以內有1 個keys 發生了變化){

    進行鏡像備份

    }

    若是設置爲空,例如:

    save ""

    即關閉rdb自動持久化.

    默認狀況下RDB自動持久化是開啓的,會定時自動壓縮保存redis的全量數據,可是因爲redis是單線程操做的,這個操做無疑比較耗費資源而阻塞操做,有些只作緩存的環境也不見得數據有多重要,關閉也是能夠的.

    注意:手動bgsave命令仍是可使用的,還須要留意dir參數的文件是否存在,若是存在,重啓後會把文件的數據加載進來

11 stop-writes-on-bgsave-error yes

當持久化出現錯誤時，是否依然繼續進行工做，是否終止全部的客戶端write請求。默認設置"yes"表示終止，一旦snapshot數據保存故障，那麼此server爲只讀服務。若是爲"no"，那麼這次snapshot將失敗，但下一次snapshot不會受到影響，不過若是出現故障,數據只能恢復到"最近一個成功點"

12 rdbcompression yes

在進行數據鏡像備份時，是否啓用rdb文件壓縮手段，默認爲yes。壓縮可能須要額外的cpu開支，不過這可以有效的減少rdb文件的大，有利於存儲/備份/傳輸/數據恢復

13 rdbchecksum yes

讀取和寫入時候，會損失10%性能

14 rdbchecksum yes

是否進行校驗和，是否對rdb文件使用CRC64校驗和,默認爲"yes"，那麼每一個rdb文件內容的末尾都會追加CRC校驗和，利於第三方校驗工具檢測文件完整性

14 dbfilename dump.rdb

鏡像快照備份文件的文件名，默認爲 dump.rdb,當使用內存超過可用內存的45%時觸發快照功能

15 dir ./

數據庫鏡像備份的文件rdb/AOF文件放置的路徑。這裏的路徑跟文件名要分開配置是由於Redis 在進行備份時，先會將當前數據庫的狀態寫入到一個臨時文件中，等備份完成時，再把該臨時文件替換爲上面所指定的文件，而這裏的臨時文件和上面所配置的備份文件都會放在這個指定的路徑當中

16 # slaveof <masterip> <masterport>

設置該數據庫爲其餘數據庫的從數據庫，併爲其指定master信息。

17 masterauth

當主數據庫鏈接須要密碼驗證時，在這裏指定

18 slave-serve-stale-data yes

當主master服務器掛機或主從複製在進行時，是否依然能夠容許客戶訪問可能過時的數據。在"yes"狀況下,slave繼續向客戶端提供只讀服務,有可能此時的數據已通過期；在"no"狀況下，任何向此server發送的數據請求服務(包括客戶端和此server的slave)都將被告知"error"

19 slave-read-only yes

slave是否爲"只讀"，強烈建議爲"yes"

20 # repl-ping-slave-period 10

slave向指定的master發送ping消息的時間間隔(秒)，默認爲10

21 # repl-timeout 60

lave與master通信中,最大空閒時間,默認60秒.超時將致使鏈接關閉

22 repl-disable-tcp-nodelay no

slave與master的鏈接,是否禁用TCP nodelay選項。"yes"表示禁用,那麼socket通信中數據將會以packet方式發送(packet大小受到socket buffer限制)。

能夠提升socket通信的效率(tcp交互次數),可是小數據將會被buffer,不會被當即發送,對於接受者可能存在延遲。"no"表示開啓tcp nodelay選項,任何數據都會被當即發送,及時性較好,可是效率較低，建議設爲no

23 slave-priority 100

適用Sentinel模塊(unstable,M-S集羣管理和監控),須要額外的配置文件支持。slave的權重值,默認100.當master失效後,Sentinel將會從slave列表中找到權重值最低(>0)的slave,並提高爲master。若是權重值爲0,表示此slave爲"觀察者",不參與master選舉

24 # requirepass foobared

設置客戶端鏈接後進行任何其餘指定前須要使用的密碼。警告：由於redis 速度至關快，因此在一臺比較好的服務器下，一個外部的用戶能夠在一秒鐘進行150K 次的密碼嘗試，這意味着你須要指定很是很是強大的密碼來防止被破解。

25 # rename-command CONFIG 3ed984507a5dcd722aeade310065ce5d    (方式:MD5('CONFIG^!'))

重命名指令,對於一些與"server"控制有關的指令,可能不但願遠程客戶端(非管理員用戶)連接隨意使用,那麼就能夠把這些指令重命名爲"難以閱讀"的其餘字符串

26 # maxclients 10000

限制同時鏈接的客戶數量。當鏈接數超過這個值時，redis 將再也不接收其餘鏈接請求，客戶端嘗試鏈接時將收到error 信息。默認爲10000，要考慮系統文件描述符限制，不宜過大，浪費文件描述符，具體多少根據具體狀況而定

27 # maxmemory <bytes>

redis-cache所能使用的最大內存(bytes),默認爲0,表示"無限制",最終由OS物理內存大小決定(若是物理內存不足,有可能會使用swap)。此值儘可能不要超過機器的物理內存尺寸,從性能和實施的角度考慮,能夠爲物理內存3/4。此配置須要和"maxmemory-policy"配合使用,當redis中內存數據達到maxmemory時,觸發"清除策略"。在"內存不足"時,任何write操做(好比set,lpush等)都會觸發"清除策略"的執行。在實際環境中,建議redis的全部物理機器的硬件配置保持一致(內存一致),同時確保master/slave中"maxmemory""policy"配置一致。可使用客戶端命令config set maxmemory 去在線修改值，這個命令是當即生效的，但會在重啓後會失效，須要使用config rewrite命令去刷新配置文件

當內存滿了的時候，若是還接收到set 命令，redis 將先嚐試剔除設置過expire 信息的key，而無論該key 的過時時間尚未到達。在刪除時，

將按照過時時間進行刪除，最先將要被過時的key 將最早被刪除。若是帶有expire 信息的key 都刪光了，內存還不夠用，那麼將返回錯誤。這樣，redis 將再也不接收寫請求，只接收get 請求。maxmemory 的設置比較適合於把redis 看成於相似memcached的緩存來使用。

28 # maxmemory-policy volatile-lru

內存不足"時,數據清除策略,默認爲"volatile-lru"。

volatile-lru  ->對"過時集合"中的數據採起LRU(近期最少使用)算法.若是對key使用"expire"指令指定了過時時間,那麼此key將會被添加到"過時集合"中。將已通過期/LRU的數據優先移除.若是"過時集合"中所有移除仍不能知足內存需求,將OOM.

allkeys-lru ->對全部的數據,採用LRU算法

volatile-random ->對"過時集合"中的數據採起"隨即選取"算法,並移除選中的K-V,直到"內存足夠"爲止. 若是若是"過時集合"中所有移除所有移除仍不能知足,將OOM

allkeys-random ->對全部的數據,採起"隨機選取"算法,並移除選中的K-V,直到"內存足夠"爲止

volatile-ttl ->對"過時集合"中的數據採起TTL算法(最小存活時間),移除即將過時的數據.

noeviction ->不作任何干擾操做,直接返回OOM異常

另外，若是數據的過時不會對"應用系統"帶來異常,且系統中write操做比較密集,建議採起"allkeys-lru"

29 # maxmemory-samples 3

默認值3，上面LRU和最小TTL策略並不是嚴謹的策略，而是大約估算的方式，所以能夠選擇取樣值以便檢查

29 appendonly no

aof持久化開關,默認狀況下，redis 會在後臺異步的把數據庫鏡像備份到磁盤，可是該備份是很是耗時的，並且備份也不能很頻繁。因此redis 提供了另一種更加高效的數據庫備份及災難恢復方式。開啓append only 模式以後，redis 會把所接收到的每一次寫操做請求都追加到appendonly.aof 文件中，當redis 從新啓動時，會從該文件恢復出以前的狀態。可是這樣會形成appendonly.aof 文件過大，因此redis 還支持了BGREWRITEAOF 指令，對appendonly.aof 進行從新整理。若是不常常進行數據遷移操做，推薦生產環境下的作法爲關閉鏡像，開啓appendonly.aof，同時能夠選擇在訪問較少的時間天天對appendonly.aof 進行重寫一次。

另外，對master機器,主要負責寫，建議使用AOF,對於slave,主要負責讀，挑選出1-2臺開啓AOF，其他的建議關閉

30 # appendfilename appendonly.aof

aof文件名字，默認爲appendonly.aof

31 appendfsync everysec

設置對appendonly.aof 文件進行同步的頻率。always 表示每次有寫操做都進行同步，everysec(默認) 表示對寫操做進行累積，每秒同步一次。no不主動fsync，由OS本身來完成。這個須要根據實際業務場景進行配置

32 no-appendfsync-on-rewrite no

在aof rewrite期間,是否對aof新記錄的append暫緩使用文件同步策略,主要考慮磁盤IO開支和請求阻塞時間。默認爲no,表示"不暫緩",新的aof記錄仍然會被當即同步

33 auto-aof-rewrite-percentage 100

當Aof log增加超過指定比例時，重寫log file， 設置爲0表示不自動重寫Aof 日誌，重寫是爲了使aof體積保持最小，而確保保存最完整的數據。相對於「上一次」rewrite，本次rewrite觸發時aof文件應該增加的百分比。每一次rewrite以後，redis都會記錄下此時「新aof」文件的大小(例如A)，那麼當aof文件增加到A*(1 + p)以後 , 觸發下一次rewrite，每一次aof記錄的添加，都會檢測當前aof文件的尺寸。 
34 auto-aof-rewrite-min-size 64mb

觸發aof rewrite的最小文件尺寸,aof文件rewrite觸發的最小文件尺寸(mb,gb),只有大於此aof文件大於此尺寸是纔會觸發rewrite，默認「64mb」

35 lua-time-limit 5000

lua腳本運行的最大時間

36 slowlog-log-slower-than 10000

"慢操做日誌"記錄,單位:微秒(百萬分之一秒,1000 * 1000),若是操做時間超過此值,將會把command信息"記錄"起來.(內存,非文件)。其中"操做時間"不包括網絡IO開支,只包括請求達到server後進行"內存實施"的時間."0"表示記錄所有操做

37 slowlog-max-len 128

"慢操做日誌"保留的最大條數,"記錄"將會被隊列化,若是超過了此長度,舊記錄將會被移除。能夠經過"SLOWLOG <subcommand> args"查看慢記錄的信息(SLOWLOG get 10,SLOWLOG reset)

38

 hash-max-ziplist-entries 512

hash類型的數據結構在編碼上可使用ziplist和hashtable。ziplist的特色就是文件存儲(以及內存存儲)所需的空間較小,在內容較小時,性能和hashtable幾乎同樣.所以redis對hash類型默認採起ziplist。若是hash中條目的條目個數或者value長度達到閥值,將會被重構爲hashtable。

這個參數指的是ziplist中容許存儲的最大條目個數，，默認爲512，建議爲128

hash-max-ziplist-value 64

ziplist中容許條目value值最大字節數，默認爲64，建議爲1024

39 

list-max-ziplist-entries 512

list-max-ziplist-value 64

對於list類型,將會採起ziplist,linkedlist兩種編碼類型。解釋同上。

40 set-max-intset-entries 512

intset中容許保存的最大條目個數,若是達到閥值,intset將會被重構爲hashtable

41 

zset-max-ziplist-entries 128

zset-max-ziplist-value 64

zset爲有序集合,有2中編碼類型:ziplist,skiplist。由於"排序"將會消耗額外的性能,當zset中數據較多時,將會被重構爲skiplist。

42 activerehashing yes

是否開啓頂層數據結構的rehash功能,若是內存容許,請開啓。rehash可以很大程度上提升K-V存取的效率

43 

client-output-buffer-limit normal 0 0 0

client-output-buffer-limit slave 256mb 64mb 60

client-output-buffer-limit pubsub 32mb 8mb 60

客戶端buffer控制。在客戶端與server進行的交互中,每一個鏈接都會與一個buffer關聯,此buffer用來隊列化等待被client接受的響應信息。若是client不能及時的消費響應信息,那麼buffer將會被不斷積壓而給server帶來內存壓力.若是buffer中積壓的數據達到閥值,將會致使鏈接被關閉,buffer被移除。

buffer控制類型包括:normal -> 普通鏈接；slave ->與slave之間的鏈接；pubsub ->pub/sub類型鏈接，此類型的鏈接，每每會產生此種問題;由於pub端會密集的發佈消息,可是sub端可能消費不足.

指令格式:client-output-buffer-limit <class> <hard> <soft> <seconds>",其中hard表示buffer最大值,一旦達到閥值將當即關閉鏈接;

soft表示"容忍值",它和seconds配合,若是buffer值超過soft且持續時間達到了seconds,也將當即關閉鏈接,若是超過了soft可是在seconds以後，buffer數據小於了soft,鏈接將會被保留.

其中hard和soft都設置爲0,則表示禁用buffer控制.一般hard值大於soft.

44 hz 10

Redis server執行後臺任務的頻率,默認爲10,此值越大表示redis對"間歇性task"的執行次數越頻繁(次數/秒)。"間歇性task"包括"過時集合"檢測、關閉"空閒超時"的鏈接等,此值必須大於0且小於500。此值太小就意味着更多的cpu週期消耗,後臺task被輪詢的次數更頻繁。此值過大意味着"內存敏感"性較差。建議採用默認值。

45 

# include /path/to/local.conf

# include /path/to/other.conf

額外載入配置文件。

#能夠經過下面命令去在線修改參數,但重啓失效,
config set maxmemory 6442450944
#使用下面命令寫進配置文件
config rewrite

------------------------------------------------------------------------------------

而後來看看啓動

#使用配置文件啓動redis
redis-server /(自定義路徑)/redis.conf
#而後測試下能不能用
redis-cli -p 6379(指定的端口號,可不填,即默認) -a "密碼" [-c "命令"(可選,非交互式操做)]
set mykey  "hi"
ok
get mykey
"hi"
#關閉redis
redis-cli shutdown
#或
kill pid

注意:在重啓服務器以前，須要在Redis-cli工具上輸入shutdown save命令，意思是強制讓Redis數據庫執行保存操做並關閉Redis服務，這樣作能保證在執行Redis關閉時不丟失任何數據。

操做

 首先來看看命令行終端輸出模式操做介紹:

#在Shell命令行下啓動Redis客戶端工具。
redis-cli -h 127.0.0.1 -p 6379 -a '********'  
#清空當前選擇的數據庫，以便於對後面示例的理解。
redis 127.0.0.1:6379> flushdb
OK
#添加String類型的模擬數據。
redis 127.0.0.1:6379> set mykey 2
OK
redis 127.0.0.1:6379> set mykey2 "hello"
OK
#添加Set類型的模擬數據。
redis 127.0.0.1:6379> sadd mysetkey 1 2 3
(integer) 3
#添加Hash類型的模擬數據。
redis 127.0.0.1:6379> hset mmtest username "stephen"
(integer) 1
#根據參數中的模式，獲取當前數據庫中符合該模式的全部key，從輸出能夠看出，該命令在執行時並不區分與Key關聯的Value類型。
redis 127.0.0.1:6379> keys my*
1) "mysetkey"
2) "mykey"
3) "mykey2"
#刪除了兩個Keys。
redis 127.0.0.1:6379> del mykey mykey2
(integer) 2
#查看一下剛剛刪除的Key是否還存在，從返回結果看，mykey確實已經刪除了。
redis 127.0.0.1:6379> exists mykey
(integer) 0
#查看一下沒有刪除的Key，以和上面的命令結果進行比較。
redis 127.0.0.1:6379> exists mysetkey
(integer) 1
#將當前數據庫中的mysetkey鍵移入到ID爲1的數據庫中，從結果能夠看出已經移動成功。
redis 127.0.0.1:6379> move mysetkey 1
(integer) 1
#打開ID爲1的數據庫。
redis 127.0.0.1:6379> select 1
OK
#查看一下剛剛移動過來的Key是否存在，從返回結果看已經存在了。
redis 127.0.0.1:6379[1]> exists mysetkey
(integer) 1
#在從新打開ID爲0的缺省數據庫。
redis 127.0.0.1:6379[1]> select 0
OK
#查看一下剛剛移走的Key是否已經不存在，從返回結果看已經移走。
redis 127.0.0.1:6379> exists mysetkey
(integer) 0
#準備新的測試數據。    
redis 127.0.0.1:6379> set mykey "hello"
OK
#將mykey更名爲mykey1
redis 127.0.0.1:6379> rename mykey mykey1
OK
#因爲mykey已經被從新命名，再次獲取將返回nil。
redis 127.0.0.1:6379> get mykey
(nil)
#經過新的鍵名獲取。
redis 127.0.0.1:6379> get mykey1
"hello"
#因爲mykey已經不存在了，因此返回錯誤信息。
redis 127.0.0.1:6379> rename mykey mykey1
(error) ERR no such key
#爲renamenx準備測試key
redis 127.0.0.1:6379> set oldkey "hello"
OK
redis 127.0.0.1:6379> set newkey "world"
OK
#因爲newkey已經存在，所以該命令未能成功執行。
redis 127.0.0.1:6379> renamenx oldkey newkey
(integer) 0
#查看newkey的值，發現它也沒有被renamenx覆蓋。
redis 127.0.0.1:6379> get newkey
"world"
        
2. PERSIST/EXPIRE/EXPIREAT/TTL:    
#爲後面的示例準備的測試數據。
redis 127.0.0.1:6379> set mykey "hello"
OK
#將該鍵的超時設置爲100秒。
redis 127.0.0.1:6379> expire mykey 100
(integer) 1
#經過ttl命令查看一下還剩下多少秒。
redis 127.0.0.1:6379> ttl mykey
(integer) 97
#馬上執行persist命令，該存在超時的鍵變成持久化的鍵，即將該Key的超時去掉。
redis 127.0.0.1:6379> persist mykey
(integer) 1
#ttl的返回值告訴咱們，該鍵已經沒有超時了。
redis 127.0.0.1:6379> ttl mykey
(integer) -1
#爲後面的expire命令準備數據。
redis 127.0.0.1:6379> del mykey
(integer) 1
redis 127.0.0.1:6379> set mykey "hello"
OK
#設置該鍵的超時被100秒。
redis 127.0.0.1:6379> expire mykey 100
(integer) 1
#用ttl命令看一下當前還剩下多少秒，從結果中能夠看出還剩下96秒。
redis 127.0.0.1:6379> ttl mykey
(integer) 96
#從新更新該鍵的超時時間爲20秒，從返回值能夠看出該命令執行成功。
redis 127.0.0.1:6379> expire mykey 20
(integer) 1
#再用ttl確認一下，從結果中能夠看出果真被更新了。
redis 127.0.0.1:6379> ttl mykey
(integer) 17
#馬上更新該鍵的值，以使其超時無效。
redis 127.0.0.1:6379> set mykey "world"
OK
#從ttl的結果能夠看出，在上一條修改該鍵的命令執行後，該鍵的超時也無效了。
redis 127.0.0.1:6379> ttl mykey
(integer) -1

3. TYPE/RANDOMKEY/SORT:
#因爲mm鍵在數據庫中不存在，所以該命令返回none。
redis 127.0.0.1:6379> type mm
none
#mykey的值是字符串類型，所以返回string。
redis 127.0.0.1:6379> type mykey
string
#準備一個值是set類型的鍵。
redis 127.0.0.1:6379> sadd mysetkey 1 2
(integer) 2
#mysetkey的鍵是set，所以返回字符串set。
redis 127.0.0.1:6379> type mysetkey
set
#返回數據庫中的任意鍵。
redis 127.0.0.1:6379> randomkey
"oldkey"
#清空當前打開的數據庫。
redis 127.0.0.1:6379> flushdb
OK
#因爲沒有數據了，所以返回nil。
redis 127.0.0.1:6379> randomkey
(nil)
#在線搭建redis從庫,此時將會丟棄舊數據集，轉而開始對新主服務器進行同步
redis 127.0.0.1:6379> SLAVEOF 10.2.1.21 6379
#不過不少redis是有密碼的,因此要配置一下
CONFIG SET MASTERAUTH 123123
#在線關閉從庫配置,原來同步所得的數據集不會被丟棄。
redis 127.0.0.1:6379> SLAVEOF NO ONE
#能夠經過下面命令去在線修改參數,但重啓失效,
config set maxmemory 6442450944
#使用下面命令寫進配置文件
config rewrite

上面這些只是一部分的用法,可是對於通常測試就足夠了?,其餘還有list用法和hash用法什麼的,有興趣能夠更加深刻研究.

--------------------------------------------------------

相似於tail和tailf的概念,終端輸出模式就是一直連線,而下面的命令結果輸出模式就是命令執行就出一個結果,不會繼續連線.

下面來看命令結果輸出模式:

redis-cli參數

-h    設置檢測主機IP地址，默認爲127.0.0.1

-p    設置檢測主機的端口號，默認爲6379    

-s<socket>    服務器套接字(壓倒主機和端口)    

-a    鏈接到Master服務器時使用的密碼    

-r    執行指定的N次命令    

-i    執行命令後等待N秒，如–i 0.1 info(執行後等0.1秒)    

-n    指定鏈接N號ID數據庫，如 –n 3(鏈接3號數據庫)    

-x    從控制檯輸入的信息中讀取最後一個參數    

-d    定義多個定界符爲默認輸出格式（默認: \n）    

--raw    使用原數據格式返回輸出內容    

--latency    進入一個不斷延時採樣的特殊模式    

--slave    模擬一個從服務器到主服務器的命令顯示反饋    

--pipe    使用管道協議模式    

--bigkeys    監聽顯示數據量大的key值，--bigkeys -i 0.1     

--help    顯示命令行幫助信息    

--version    顯示版本號    

例子：

$ redis-cli進入命令行模式
$ redis-cli -n 3 set mykey "hi" 把mykey插入到第三個數據庫
$ redis-cli -r 3 info 重複執行info命令三次
下面還有一些比較特別的用法
GETSET: ./redis-cli getset nid 987654321 
# 表示返回指定key的原始值，並指定一個新值給他 
MGET: ./redis-cli mget nid uid … 
# 表示獲取多個key的值 
SETNX: ./redis-cli setnx nnid 888888 
# 表示當一個指定的key不存在時，設置這個key指定的value，若是存在，則設置不成功 
SETEX: ./redis-cli setex nid 5 666666 
# 表示設置一個key指定的value保存5秒後失效，設置key/value的有效期 
MSET: ./redis-cli mset nid0001 "0001" nid0002 "0002" nid0003 "0003"
# 表示多鍵值對的數據保存 
INCR: ./redis-cli incr count 
# 表示對給定key的value進行遞增(+1)的操做,固然value必須是一個integer 
INCRBY: ./redis-cli incrby count 5 
# 表示對給定key的value進行指定步長的遞增操做 
DECR: ./redis-cli decr count 
# 表示對給定key的value進行遞減(-1)的操做 
DECRBY: ./redis-cli decrby count 7 
# 表示對給定key的value進行指定步長的遞減操做 
APPEND: ./redis-cli append content "bad"   或者  ./redis-cli append content "good"
# 表示追加一個value到指定的key中，若是key不存在，則新建key 
SUBSTR: ./redis-cli substr content 0 4 
# 表示返回指定key的value的部分字符串
# 列表操做，精華 
RPUSH key string — 將某個值加入到一個key列表末尾 
LPUSH key string — 將某個值加入到一個key列表頭部 
LLEN key — 列表長度 
LRANGE key start end — 返回列表中某個範圍的值，至關於mysql裏面的分頁查詢那樣 
LTRIM key start end — 只保留列表中某個範圍的值 
LINDEX key index — 獲取列表中特定索引號的值，要注意是O(n)複雜度 
LSET key index value — 設置列表中某個位置的值 
RPOP key 
# 集合操做 
SADD key member — 增長元素 
SREM key member — 刪除元素 
SCARD key — 返回集合大小 
SISMEMBER key member — 判斷某個值是否在集合中 
SINTER key1 key2 ... keyN — 獲取多個集合的交集元素 
SMEMBERS key — 列出集合的全部元素 ?
更新日誌檢查 ，加--fix參數爲修復log文件
redis-check-aof appendonly.aof
檢查本地數據庫文件
redis-check-dump  dump.rdb

========================================================

壓力測試

redis測試分兩種說法,第一種就是併發壓力,另外一種就是容量壓力了,

併發壓力能夠用redis自帶的軟件redis-benchmark來測試?,具體以下:

redis-benchmark參數

-h    設置檢測主機IP地址，默認爲127.0.0.1    

-p    設置檢測主機的端口號，默認爲6379    

-s<socket>    服務器套接字(壓倒主機和端口)    

-c    併發鏈接數    

-n    請求數    

-d    測試使用的數據集的大小/字節的值(默認3字節)    

-k    1：表示保持鏈接(默認值)0：從新鏈接    

-r    SET/GET/INCR方法使用隨機數插入數值，設置10則插入值爲rand:000000000000 - rand:000000000009    

-P    默認爲1(無管道)，當網絡延遲過長時，使用管道方式通訊(請求和響應打包發送接收)    

-q    簡約信息模式，只顯示查詢和秒值等基本信息。    

--csv    以CSV格式輸出信息    

-l    無線循環插入測試數據，ctrl+c中止    

-t<tests>    只運行<tests>測試逗號分隔的列表命令，如：-t ping,set,get    

-I    空閒模式。當即打開50個空閒鏈接和等待。   

例子： 

#SET/GET 100 bytes 檢測host爲127.0.0.1 端口爲6379的redis服務器性能
redis-benchmark -h 127.0.0.1 -p 6379 -q -d 100  
#5000個併發鏈接，100000個請求，檢測host爲127.0.0.1 端口爲6379的redis服務器性能 
redis-benchmark -h 127.0.0.1 -p 6379 -c 5000 -n 100000 
#向redis服務器發送100000個請求，每一個請求附帶60個併發客戶端
redis-benchmark -n 100000 -c 60

結果（部分）：

====== SET ======

對集合寫入測試

  100000 requests completed in 2.38 seconds

100000個請求在2.38秒內完成

  60 parallel clients

每次請求有60個併發客戶端

  3 bytes payload

每次寫入3個字節的數據

  keep alive: 1

保持一個鏈接，一臺服務器來處理這些請求

100.00% <= 62 milliseconds

全部請求在62毫秒內完成

42105.26 requests per second

每秒處理42105.26次請求

仍是比較直觀的

-----------------------------------

而後說說容量測試,其實很好理解,內存不是無限的,存放數據天然就是有限,雖說能夠去配置文件去用淘汰機制限制,可是知道容量頂點仍是能解決很多問題.

順便也說說,要是你設置的maxmemory 容量不夠,或者整個內存都不夠,而又沒有使用有效的LRU配置,那麼你的redis寫滿了以後會提示OOM,就是說內存不夠用,寫不進新數據.

說的就是maxmemory-policy這個設置,具體怎麼設置纔是合理的,則須要從業務層面去考慮了,例如說丟了一些舊key也沒所謂的,allkeys-lru就是最好了,嚴格來或,你用了這個策略其實也不用測試了,由於他會自動刪舊key,沒什麼頂不頂點的概念在..

測試容量的方法很簡單,就是不停的往裏面寫數據,而後看他頂點是多少.? 

參考腳本以下:

#!/bin/sh
keyset="keytest5"
valueset='模擬數據,隨便你寫'
dbname=5
a=0
for i in `seq 1 300000`
do
redis-cli -n $dbname 'set' ${keyset}${a} "${valueset}${a}" >/dev/null
#echo $a
let a++
done

測試結果很簡單,看info的最後一個結果就行了,哪裏會有顯示如今有多少個key在.