Redis數據結構及簡單操作指令

1.Redis數據結構及簡單操作指令

String、list、set、hash、zset（有序set）

總體來說redis都是通過Key-Value的形式來存儲數據的。只是不用數據類型Value的形式不同。

String：最簡單數據結構，比如我們將一個對象轉成json串來存儲

set key value 存放數據

get key 獲取數據

exists key 查看數據是否存在，存在返回1否則0

del key 刪除數據 返回操作成功的條數

mset key1 value1 key2 value2 key3 value3...存放多組數據

mget key1 ke2y key3... 獲取多個key的數據，返回一個集合，類似Map的values方法

expire key second 設置key 過去時間，單位秒

setex key second value設置key 過去時間，單位秒(等價于先set，再expire)

setnx key value 如果key不存在就set 返回1.如果存在返回0（可以基于此實現分布式鎖）

List：并不是java里面的list，redis的list更像一個鏈表或者說隊列/棧的結構。這就意味著它的刪除插入快，但是通過索引定位就比較慢了。當列表彈出了最后一個元素之后，該數據結構自動被刪除，內存被回收。

Redis 的列表結構常用來做異步隊列使用。將需要延后處理的任務塞進 Redis 的列表，另一個線程從這個列表中輪詢數據進行處理。

rpush key value1 value2 value3...  插入list數據

llen key     查看長度

lpop key    按加入順序獲取（先進先出，類似隊列）

rpop key   后進先出，有點類似棧

列表取數據，取完后整個列表都被回收了，就是說只能取一次數據。

Hash：類似java的hashMap，和字符串相比，我們存儲數據的時候可以只存儲對象的部分屬性，而字符串則需要完整將整個對象轉換。當然hash存儲結構的消耗肯定是高于字符串的

hset redisKey hashKey1 value1

 　  hset redisKey hashKey2 value2  插入數據

hgetall redisKey  獲取數據，key value間隔出現

hlen redisKey  查看hash長度

hget redisKey hashKey 獲取hashKey 對應的value

hmset redisKey hashKey1 value1 hashKey2 value2 hashKey2 value3 批量插入值

Set : 類似HashSet,但是list類似，最后一個數據取完之后，該結構會被清理，無法再次獲取數據

sadd key value         

sadd key value1 value2   批量添加

smembers key    查看所有

sismember key value  查詢某個值是否存在，存在返回1

scard  key   查看大小

spop key    獲取一個元素

原子計數操作

如果value是整數的話還可以實現自增操作（也可以用于實現分布式鎖，該增長有限，最大到long max，超過該值會直接報錯）

incr key 自增 如果key不存在默認從0自增1

incrby key step 設置增加步長step

2.redis持久化

雖然說redis都是內存級別的操作，其實也是有持久化的。

一種是基于RDB快照，

Redis 將內存數據庫快照保存在名字為 dump.rdb 的二進制文件中。

可以對 Redis 進行設置， 讓它在N 秒內數據集至少有 M 個改動這一條件被滿足時， 自動保存一次數據集。

另一種是AOF（append-only file）

快照并不可靠，上次快照之后，還未到達下一次快照條件時，這時候服務出現了問題，那么這期間的數據是無法保存到快照版本中的。這個時候就需要AOF了，它將每一條指令都記錄進文件，當redis重啟的時候，重新執(zhí)行這個文件里面指令，就可以恢復所有的數據到內存中了。

可以通過配置appendonly yes 來開啟AOF，默認是關閉的

AOF也有三種同步數據的策略，

每次有操作都去刷新文件，很慢，但安全

每秒同步刷新一次：可能會丟失一秒內的數據

從不同步同步刷新：讓操作系統(tǒng)在需要的時候刷新數據，不安全

默認的是每秒刷一次 

混合持久化：

RDB快照數據恢復速度快，但是可能會有大量數據丟失，所以通?；謴蛿祿€是用的AOF日志重放，但是AOF相對來說速度會很慢，尤其是在數據量大的時候。因此在4.0的時候帶來了混合持久化，也就是AOF在刷新的時候，先記錄上次的快照版本，然后記錄上次快照版本到現在的增量操作，然后合并成一個文件，覆蓋原來的appendonly.aof文件。Redis重啟的時候，先加載RDB快照的內容，在重放AOF日志中增量操作的內容就可以了。

開啟混合持久化：aof-use-rdb-preamble yes

混合持久化中appendonly.aof內容格式，一部分是RDB文件內容格式，另外的才是AOF文件的內容格式。

3.緩存淘汰策略：

當 Redis 內存超出物理內存限制時，內存的數據會開始和磁盤產生頻繁的交換 。會讓 Redis 的性能急劇下降，對于訪問量比較頻繁的 Redis 來說，這樣存取效率基本上等于不可用。

在生產環(huán)境中我們是不允許 Redis 出現交換行為的，為了限制最大使用內存，Redis 提供了配置參數 maxmemory 來限制內存超出期望大小。

當實際內存超出 maxmemory 時，Redis 提供了幾種可選策略 (maxmemory-policy) 來讓用戶自己決定該如何騰出新的空間以繼續(xù)提供讀寫服務。

noeviction 不會繼續(xù)處理寫請求 (del,read請求可以繼續(xù)進行)。這樣可以保證不會丟失數據，但是會讓線上的寫相關的業(yè)務不能持續(xù)進行。這是默認的淘汰策略。

volatile-lru 嘗試淘汰設置了過期時間的 key，最少使用的 key 優(yōu)先被淘汰。沒有設置過期時間的 key 不會被淘汰，這樣可以保證需要持久化的數據不會突然丟失。

volatile-ttl 跟上面一樣，除了淘汰的策略不是 LRU，而是 key 的剩余壽命 ttl 的值，ttl 越小越優(yōu)先被淘汰。

volatile-random 跟上面一樣，不過淘汰的 key 是過期 key 集合中隨機的 key。

allkeys-lru 區(qū)別于 volatile-lru，這個策略要淘汰的 key 對象是全體的 key 集合，而不只是過期的 key 集合。這意味著沒有設置過期時間的 key 也會被淘汰。

allkeys-random 跟上面一樣，不過淘汰的策略是隨機的 key。

volatile-xxx 策略只會針對帶過期時間的 key 進行淘汰，allkeys-xxx 策略會對所有的 key 進行淘汰。如果你只是拿 Redis 做緩存，那應該使用 allkeys-xxx，客戶端寫緩存時不必攜帶過期時間。如果你還想同時使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，這樣可以保留沒有設置過期時間的 key，它們是永久的 key 不會被 LRU 算法淘汰。