redis的基本操作

Redis 是一個高效能的key-value資料庫, 支援主從同步, 完全實現了釋出/訂閱機制, 因此可以用於聊天室等場景. 主要表現於多個瀏覽器之間的資訊同步和實時更新.

和Memcached類似，它支援儲存的value型別相對更多，包括string(字串)、list(連結串列)、set(集合)、zset(sorted set –有序集合)和hash（雜湊型別）。這些資料型別都支援push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，redis支援各種不同方式的排序。與memcached一樣，為了保證效率，資料都是快取在記憶體中。區別的是redis會週期性的把更新的資料寫入磁碟或者把修改操作寫入追加的記錄檔案，並且在此基礎上實現了master-slave(主從)同步。資料可以從master向任意數量的slave上同步，slave可以是關聯其他slave的master。這使得Redis可執行單層樹複製。存檔可以有意無意的對資料進行寫操作。由於完全實現了釋出/訂閱機制，使得slave在任何地方同步樹時，可訂閱一個頻道並接收master完整的訊息釋出記錄。同步對讀取操作的可擴充套件性和資料冗餘很有幫助.

• redis是key-value的資料結構，每條資料都是⼀個鍵值對
• 鍵的型別是字串
• 注意：鍵不能重複

• 值的型別分為五種：
• 字串string
• 雜湊hash
• 列表list
• 集合set
• 有序集合zset

• string型別
• 字串型別是Redis 中最為基礎的資料儲存型別，它在 Redis 中是二進位制安全的，這便意味著該型別可以接受任何格式的資料，如JPEG影象資料或Json物件描述資訊等。在Redis中字串型別的Value最多可以容納的資料長度是512M。

啟動服務

redis-server

啟動命令列

redis-cli

執行redis-cli即可啟動命令列工具, 也可自行指定host及port.

redis-cli -h localhost -p 6379 

• 設定鍵值

set key value

• 例1：設定鍵為name值為itcast的資料

set name itcast

• 設定鍵值及過期時間，以秒為單位

setex key seconds value

• 例2：設定鍵為aa值為aa過期時間為3秒的資料

setex aa 3 aa

• 設定多個鍵值

mset key1 value1 key2 value2 ...

• 例3：設定鍵為'a1'值為'python'、鍵為'a2'值為'java'、鍵為'a3'值為'c'

mset a1 python a2 java a3 c

• 追加值

append key value

• 例4：向鍵為a1中追加值' haha'

append 'a1' 'haha'

獲取

• 獲取：根據鍵獲取值，如果不存在此鍵則返回null

get key

• 例5：獲取鍵'name'的值

get 'name'

• 根據多個鍵獲取多個值

mget key1 key2 ...

• 例6：獲取鍵a1、a2、a3'的值

mget a1 a2 a3

• 檢視鍵對應的value的型別

type key

• 例4：檢視鍵a1的值型別，為redis⽀持的五種型別中的⼀種

type a1

• 刪除鍵及對應的值

del key1 key2 ...

• 例5：刪除鍵a2、a3

del a2 a3

• 設定過期時間，以秒為單位
• 如果沒有指定過期時間則⼀直存在，直到使⽤DEL移除

expire key seconds

• 例6：設定鍵'a1'的過期時間為3秒

expire 'a1' 3

檢視有效時間，以秒為單位

ttl key

對string的操作

127.0.0.1:6379> exists hello // 檢視key是否存在
(integer) 1 
127.0.0.1:6379> set hello world // 設定hello-world
OK 
127.0.0.1:6379> get hello // 獲取hello的值
"world" 
127.0.0.1:6379> type hello // 值型別
string 
127.0.0.1:6379[2]> substr hello 1 2 // 獲取substring
"or"
127.0.0.1:6379[2]> append hello ! // 字串連線
(integer) 6
127.0.0.1:6379[2]> get hello
"world!"
127.0.0.1:6379> set haha heihei
OK
127.0.0.1:6379> keys h* // 返回滿足條件的所有key
1) "hello"
3) "haha"
127.0.0.1:6379> randomkey // 隨機返回一個key
"haha"
127.0.0.1:6379> randomkey
"hello"
127.0.0.1:6379> rename hello hehe // 重新命名key
OK
127.0.0.1:6379> get haha
"heihei"
127.0.0.1:6379> expire haha 10
(integer) 1 // 設定haha的活動時間(s)
127.0.0.1:6379> ttl haha
(integer) 7 // 獲取haha的活動時間
127.0.0.1:6379> get haha
(nil) // expire 時間到期後,該haha-heihei會刪除
127.0.0.1:6379[2]> del hello
(integer) 0

對list的操作

redis中的list在底層實現上是連結串列. 因此, 無論list的空間複雜度是多少, 其時間複雜度是常數級別的. 即使用lpush在10個元素的list頭部插入新元素, 和在上萬個元素的lists頭部插入新元素的速度相當. 但lists中的元素定位會比較慢.
常見操作有lpush, rpush, lrange等.

127.0.0.1:6379[2]> lpush list1 1 // 頭部插入資料
(integer) 1
127.0.0.1:6379[2]> lpush list1 2 
(integer) 2
127.0.0.1:6379[2]> rpush list1 0 // 尾部插入資料
(integer) 3
127.0.0.1:6379[2]> lrange list1 0 1 // 列出編號0~1的元素
1) "2"
2) "1"
127.0.0.1:6379[2]> lrange list1 0 -1 // 列出編號0到倒數第一個的元素
1) "2"
2) "1"
3) "0"
127.0.0.1:6379[2]> llen list1 // lists長度
127.0.0.1:6379[2]> lindex list1 1 // 根據index獲取元素
"1"
127.0.0.1:6379[2]> ltrim list1 1 2 // 擷取,僅保留編號1~2之間的元素
OK
127.0.0.1:6379[2]> lrange list1 0 10
1) "1"
2) "0"
(integer) 3
127.0.0.1:6379[2]> lset list1 1 haha // 給1位置的元素賦值為haha
OK
127.0.0.1:6379[2]> lset list1 2 haha // 賦值,不能超出lists範圍
(error) ERR index out of range
127.0.0.1:6379[2]> lrange list1 0 10
1) "1"
2) "haha"
127.0.0.1:6379[2]> rpush list1 haha
(integer) 3
127.0.0.1:6379[2]> rpush list1 haha
(integer) 4
127.0.0.1:6379[2]> lrange list1 0 10
1) "1"
2) "haha"
3) "haha"
4) "haha"
127.0.0.1:6379[2]> lrem list1 2 haha 刪除2個值為haha的元素
(integer) 2
127.0.0.1:6379[2]> lrange list1 0 10
1) "1"
2) "haha"
127.0.0.1:6379[2]> lpop list1
"1"
127.0.0.1:6379[2]> lrange list1 0 10
1) "haha"

　　可以使用list來實現一個訊息佇列(如部落格的評論內容), 確保先後順序, 而不必像mysql那樣使用order by來排序.
使用lrange還可以很方便地實現分頁功能

對set的操作

redis的set是無序的集合, 其中的元素沒有先後順序.
常見操作如下:

127.0.0.1:6379[2]> sadd set1 0 // 像set1中新增元素0
(integer) 1
127.0.0.1:6379[2]> sadd set1 1
(integer) 1
127.0.0.1:6379[2]> smembers set1 // 返回set1中的所有元素
1) "0"
2) "1"
127.0.0.1:6379[2]> scard set1 // 返回set的基數
(integer) 2
127.0.0.1:6379[2]> sismember set1 0 // 測試set1中是否包含元素0
(integer) 1
127.0.0.1:6379[2]> srandmember set1 // 隨機返回一個元素
"0"
127.0.0.1:6379[2]> sadd set2 0
(integer) 1
127.0.0.1:6379[2]> sadd set2 2
(integer) 1
127.0.0.1:6379[2]> sinter set1 set2 // 求交集
1) "0"
127.0.0.1:6379[2]> sinterstore set3 set1 set2 // 儲存交集到set3
(integer) 1
127.0.0.1:6379[2]> smembers set3
1) "0"
127.0.0.1:6379[2]> sunion set1 set2 // 求並集
1) "0"
2) "1"
3) "2"
127.0.0.1:6379[2]> sdiff set1 set2 // 求差集
1) "1"
127.0.0.1:6379[2]> sdiff set2 set1
1) "2"

對zset的操作

zset是一種有序集合(sorted set), 其中每個元素都關聯一個序號score.
常見操作有zrange, zadd, zrevrange等

127.0.0.1:6379[2]> zadd zset1 1 dianping.com // 新增元素, score為1
(integer) 1
127.0.0.1:6379[2]> zadd zset1 2 baidu.com
(integer) 1
127.0.0.1:6379[2]> zadd zset1 3 qq.com
(integer) 1
127.0.0.1:6379[2]> zcard zset1 // 返回zset的基數
(integer) 3
127.0.0.1:6379[2]> zscore zset1 dianping.com // 返回元素的score
"1"
127.0.0.1:6379[2]> zrank zset1 dianping.com // 返回元素的rank
(integer) 0
127.0.0.1:6379[2]> zrange zset1 0 1 // 選取元素, score
從小到大
1) "dianping.com"
2) "baidu.com"
127.0.0.1:6379[2]> zrevrange zset1 0 1 // score從大到小
1) "qq.com"
2) "baidu.com"
127.0.0.1:6379[2]> zrem zset1 qq.com // 刪除元素
(integer) 0

127.0.0.1:6379[2]> zincrby zset1 5 taobao.com // 如果元素不存在, 則新增該元素, 設定score為5
"5"
127.0.0.1:6379[2]> zcard zset1
(integer) 3
127.0.0.1:6379[2]> zincrby zset1 10 dianping.com // 如果元素存在, 則其score增加10
"11"
127.0.0.1:6379[2]> zrange zset1 0 10 withscores
1) "taobao.com"
2) "5"
3) "dianping.com"
4) "11"

　　此外, 還有zrevrank, zrevrange, zrangebyscore, zremrangebyrank, zramrangebyscore, zinterstore/zunionstore等操作.

.

對hash的操作

hash也是一種非常常見的結構.

127.0.0.1:6379[2]> hset hash1 key1 value1 // 新增元素
(integer) 1
127.0.0.1:6379[2]> hget hash1 key1 // 獲取元素的value
"value1"
127.0.0.1:6379[2]> hexists hash1 key1
(integer) 1
127.0.0.1:6379[2]> hset hash1 key2 value2
(integer) 1
127.0.0.1:6379[2]> hlen hash1
(integer) 2
127.0.0.1:6379[2]> hkeys hash1 // 獲取hash1的所有key
1) "key1"
2) "key2"
127.0.0.1:6379[2]> hvals hash1 // 獲取hash1的所有value
1) "value1"
2) "value2"
127.0.0.1:6379[2]> hmget hash1 key1 key2 // 獲取元素
1) "value1"
2) "value2"
127.0.0.1:6379[2]> hgetall hash1 // 獲取key/value
1) "key1"
2) "value1"
3) "key2"
4) "value2"
127.0.0.1:6379[2]> hset hash1 key3 10
(integer) 1
127.0.0.1:6379[2]> hincrby hash1 key3 5 // 將key3的value增加15(僅限整數)
(integer) 15
127.0.0.1:6379[2]> hmset hash1 key4 value4 key5 value5 // 批量新增元素
OK

擴充套件操作

dbsize 檢視所有key的數目
flushdb 刪除當前選擇資料庫中的所有key
flushall 刪除所有資料庫中的所有key
save: 將資料同步儲存到磁碟
bgsave: 非同步儲存
lastsave: 上次成功儲存到磁碟的Unix時間戳
info: 查詢server資訊
config: 配置server
slaveof: 改變複製策略設定

publish-subscribe

redis的釋出/訂閱機制使用非常簡便, 如下圖:

subscribe chatchannel 訂閱該chatchannel頻道, 則會實時接收到該頻道的訊息;
publish chatchannel ‘hello’ 向chatchannel頻道釋出訊息, 所有訂閱者都能收到.
這種機制, 可以非常方便地使用在類似於聊天室的場景中.

redis持久化

redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Append Only File）。
RDB，簡而言之，就是在不同的時間點，將redis儲存的資料生成快照並存儲到磁碟等介質上；
AOF，則是換了一個角度來實現持久化，那就是將redis執行過的所有寫指令記錄下來，在下次redis重新啟動時，只要把這些寫指令從前到後再重複執行一遍，就可以實現資料恢復了。
其實RDB和AOF兩種方式也可以同時使用，在這種情況下，如果redis重啟的話，則會優先採用AOF方式來進行資料恢復，這是因為AOF方式的資料恢復完整度更高。
如果你沒有資料持久化的需求，也完全可以關閉RDB和AOF方式，這樣的話，redis將變成一個純記憶體資料庫，就像memcache一樣。

RDB

RDB方式，是將redis某一時刻的資料持久化到磁碟中，是一種快照式的持久化方法。
redis在進行資料持久化的過程中，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，才會用這個臨時檔案替換上次持久化好的檔案。正是這種特性，讓我們可以隨時來進行備份，因為快照檔案總是完整可用的。
對於RDB方式，redis會單獨建立（fork）一個子程序來進行持久化，而主程序是不會進行任何IO操作的，這樣就確保了redis極高的效能。
如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
雖然RDB有不少優點，但它的缺點也是不容忽視的。如果你對資料的完整性非常敏感，那麼RDB方式就不太適合你，因為即使你每5分鐘都持久化一次，當redis故障時，仍然會有近5分鐘的資料丟失。所以，redis還提供了另一種持久化方式，那就是AOF。

AOF

AOF，英文是Append Only File，即只允許追加不允許改寫的檔案。
如前面介紹的，AOF方式是將執行過的寫指令記錄下來，在資料恢復時按照從前到後的順序再將指令都執行一遍，就這麼簡單。
我們通過配置redis.conf中的appendonly yes就可以開啟AOF功能。如果有寫操作（如SET等），redis就會被追加到AOF檔案的末尾。
預設的AOF持久化策略是每秒鐘fsync一次（fsync是指把快取中的寫指令記錄到磁碟中），因為在這種情況下，redis仍然可以保持很好的處理效能，即使redis故障，也只會丟失最近1秒鐘的資料。
如果在追加日誌時，恰好遇到磁碟空間滿、inode滿或斷電等情況導致日誌寫入不完整，也沒有關係，redis提供了redis-check-aof工具，可以用來進行日誌修復。
因為採用了追加方式，如果不做任何處理的話，AOF檔案會變得越來越大，為此，redis提供了AOF檔案重寫（rewrite）機制，即當AOF檔案的大小超過所設定的閾值時，redis就會啟動AOF檔案的內容壓縮，只保留可以恢復資料的最小指令集。舉個例子或許更形象，假如我們呼叫了100次INCR指令，在AOF檔案中就要儲存100條指令，但這明顯是很低效的，完全可以把這100條指令合併成一條SET指令，這就是重寫機制的原理。
在進行AOF重寫時，仍然是採用先寫臨時檔案，全部完成後再替換的流程，所以斷電、磁碟滿等問題都不會影響AOF檔案的可用性，這點大家可以放心。
AOF方式的另一個好處，我們通過一個“場景再現”來說明。某同學在操作redis時，不小心執行了FLUSHALL，導致redis記憶體中的資料全部被清空了，這是很悲劇的事情。不過這也不是世界末日，只要redis配置了AOF持久化方式，且AOF檔案還沒有被重寫（rewrite），我們就可以用最快的速度暫停redis並編輯AOF檔案，將最後一行的FLUSHALL命令刪除，然後重啟redis，就可以恢復redis的所有資料到FLUSHALL之前的狀態了。是不是很神奇，這就是AOF持久化方式的好處之一。但是如果AOF檔案已經被重寫了，那就無法通過這種方法來恢復資料了。
雖然優點多多，但AOF方式也同樣存在缺陷，比如在同樣資料規模的情況下，AOF檔案要比RDB檔案的體積大。而且，AOF方式的恢復速度也要慢於RDB方式。
如果你直接執行BGREWRITEAOF命令，那麼redis會生成一個全新的AOF檔案，其中便包括了可以恢復現有資料的最少的命令集。
如果運氣比較差，AOF檔案出現了被寫壞的情況，也不必過分擔憂，redis並不會貿然載入這個有問題的AOF檔案，而是報錯退出。這時可以通過以下步驟來修復出錯的檔案：
1. 備份被寫壞的AOF檔案
2. 執行redis-check-aof –fix進行修復
3. 用diff -u來看下兩個檔案的差異，確認問題點
4. 重啟redis，載入修復後的AOF檔案

AOF重寫

AOF重寫的內部執行原理，我們有必要了解一下。
在重寫即將開始之際，redis會建立（fork）一個“重寫子程序”，這個子程序會首先讀取現有的AOF檔案，並將其包含的指令進行分析壓縮並寫入到一個臨時檔案中。
與此同時，主工作程序會將新接收到的寫指令一邊累積到記憶體緩衝區中，一邊繼續寫入到原有的AOF檔案中，這樣做是保證原有的AOF檔案的可用性，避免在重寫過程中出現意外。
當“重寫子程序”完成重寫工作後，它會給父程序發一個訊號，父程序收到訊號後就會將記憶體中快取的寫指令追加到新AOF檔案中。
當追加結束後，redis就會用新AOF檔案來代替舊AOF檔案，之後再有新的寫指令，就都會追加到新的AOF檔案中了。

主從(master-slave)

像MySQL一樣，redis是支援主從同步的，而且也支援一主多從以及多級從結構。
主從結構，一是為了純粹的冗餘備份，二是為了提升讀效能，比如很消耗效能的SORT就可以由從伺服器來承擔。
redis的主從同步是非同步進行的，這意味著主從同步不會影響主邏輯，也不會降低redis的處理效能。
主從架構中，可以考慮關閉主伺服器的資料持久化功能，只讓從伺服器進行持久化，這樣可以提高主伺服器的處理效能。
在主從架構中，從伺服器通常被設定為只讀模式，這樣可以避免從伺服器的資料被誤修改。但是從伺服器仍然可以接受CONFIG等指令，所以還是不應該將從伺服器直接暴露到不安全的網路環境中。如果必須如此，那可以考慮給重要指令進行重新命名，來避免命令被外人誤執行。

同步原理

從伺服器會向主伺服器發出SYNC指令，當主伺服器接到此命令後，就會呼叫BGSAVE指令來建立一個子程序專門進行資料持久化工作，也就是將主伺服器的資料寫入RDB檔案中。在資料持久化期間，主伺服器將執行的寫指令都快取在記憶體中。
在BGSAVE指令執行完成後，主伺服器會將持久化好的RDB檔案傳送給從伺服器，從伺服器接到此檔案後會將其儲存到磁碟上，然後再將其讀取到記憶體中。這個動作完成後，主伺服器會將這段時間快取的寫指令再以redis協議的格式傳送給從伺服器。
另外，要說的一點是，即使有多個從伺服器同時發來SYNC指令，主伺服器也只會執行一次BGSAVE，然後把持久化好的RDB檔案發給多個下游。在redis2.8版本之前，如果從伺服器與主伺服器因某些原因斷開連線的話，都會進行一次主從之間的全量的資料同步；而在2.8版本之後，redis支援了效率更高的增量同步策略，這大大降低了連線斷開的恢復成本。
主伺服器會在記憶體中維護一個緩衝區，緩衝區中儲存著將要發給從伺服器的內容。從伺服器在與主伺服器出現網路瞬斷之後，從伺服器會嘗試再次與主伺服器連線，一旦連線成功，從伺服器就會把“希望同步的主伺服器ID”和“希望請求的資料的偏移位置（replication offset）”傳送出去。主伺服器接收到這樣的同步請求後，首先會驗證主伺服器ID是否和自己的ID匹配，其次會檢查“請求的偏移位置”是否存在於自己的緩衝區中，如果兩者都滿足的話，主伺服器就會向從伺服器傳送增量內容。
增量同步功能，需要伺服器端支援全新的PSYNC指令。這個指令，只有在redis-2.8之後才具有。

其他部分

事物處理, redis配置的部分, 請參考博文超強、超詳細Redis資料庫入門教程.

參考原文：https://blog.csdn.net/icetime17/article/details/45767559 https://www.cnblogs.com/sunzhiqi/p/10869638.html