Redis相關

目錄

Redis基礎命令

String操作

Hash操作

List操作

Set操作

Sorted Set操作

一致性Hash算法

Redis五大數據類型應用場景

Redis分佈式鎖

Redis集羣方案

Redis Sharding集羣:一致性hash算法

redis-cluster:哈希槽、投票容錯

Redis的持久化方案

Redis的持久化方案各自缺點


Redis基礎命令

Info:查看當前redis信息,其中#Keyspace代表當前的0-15個db的數據量

flushdb:清空當前的db

flushAll:清空所有的db

dbsize:查看當前redis存儲鍵數量

save:保存當前所有操作

quit:退出當前連接

keys *:查看當前所有鍵值

rename a b:將鍵a重命名爲b,如果當前db中有b鍵,那麼舊的b鍵對應的值會被覆蓋

renamenx a b:將鍵a重命名爲b,若b已存在,則無法生效,nx結尾的都會做一些判斷!

monitor:進入監視模式,對redis的操作都會在控制檯顯示日誌

 

String操作

set a a:創建一個String鍵值

setex a 100 a:設置一個String鍵值,過期時間爲100秒

psetex d 10000 d:設置一個String鍵值,過期時間爲10000毫秒,也就是10s

exists a:查看是否有a鍵

ttl a:time to leave查看當前key的剩餘時間,單位秒,-1永久,-2不存在此key

expire a 10:設置a的過期時間爲10秒

type a:查看鍵a的類型

randomkey:隨機查看當前db中的key

mset a1 a1 b1 b1 c1 c1:同時設置3對key-value對

mget a1 b1 c1:同時獲得3個鍵對應的值

setnx a a:當且只有a鍵不存在的時候才能成功創建,否則失敗

msetnx a a b b:只有設置的所有鍵都在db中不存在時才能成功,要麼都成功,要麼都失敗

getrange a 0 2:獲得a鍵對應的String值的0-2位

getset a aa:獲得a對應的值後再把a對應的值設置爲aa,即返回原本的值

strlen a:返回a對應的值的長度

incr a:給a對應的值+1,要求其value得是數值Integer,否則會失敗

incrby a 100:指定步長,給a對應的值+100,要求其value得是數值Integer,否則失敗

decr a:給a對應的值-1,要求其value得是數值Integer,否則會失敗

incrby a 100:指定步長,給a對應的值-100,要求其value得是數值Integer,否則失敗

append a hahaha:給a對應的值追加hahaha串

 

Hash操作

Redis中的Hashes類型可以看成具有String Key和String Value的map容器。所以該類型非常適合於存儲值對象的信息。如Username、Password和Age等。如果  Hash中包含很少的字段,那麼該類型的數據也將僅佔用很少的磁盤空間。每一個Hash  可以存儲4294967295個鍵值對。

hset map name tom:創建一個hash鍵值,鍵爲map,key爲name,對應值爲tom

hexists map name:查看是否含有hash鍵值map的name

hget map name:獲得map鍵的key=name對應的值

hgetall map:獲得map裏面含有的所有屬性和屬性對應的值

hkeys map:獲得map裏面所有的key

hvals map:獲得map裏面所有key對應的值

hlen map:查看key的個數

hmget map name age:同時獲得map裏面name和age對應的值

hmset map key1 value1 key2 value2:同時給map裏面設置key1,key2鍵值對

hdel map key1 key2:將map裏面的key1、key2鍵值對刪除

hsetnx map a b:帶有判斷地給map創建key=a對應的值爲b,若key=a存在則失敗

 

List操作

lpush list 1 2 3 4:給list添加1 2 3 4共4個值,從頭插入,最後隊頭爲4

llen list:查看當前list的長度

lrange list 0 2:取得list從0到2的範圍,共返回3個數

lset list 0 100:將list第0個元素設置爲100

lindex list 2:獲得索引爲2的元素

lpop list:將list的第一個元素彈出來

rpop list:將list的最後一個元素彈出來

 

Set操作

無序,不允許重複

sadd set a b c d:給set插入a b c d共四個值

scard set:查看集合中元素的數量

smembers set:查看set裏面的所有元素,不保證順序

sdiff set1 set2:取差集,查看set1裏面的不存在於set2中的元素

sinter set1 set2:取交集,查看set1與set2共同存在的元素

sunion set1 set2:取並集,查看set1與set2的所有元素,共同擁有的只算一次

srandmember set1 2:返回set1中的隨機兩個元素

sismember set1 a:查看a是否爲set1中的元素

srem set1 a b:移除set1裏面 a b 兩個元素

spop set1:隨機移除set1裏面的一個元素,並返回這個元素

 

 

Sorted Set操作

元素會按照分數值從小到大進行排序

zadd set 2 a 4 b 6 c:創建一個有序集合set,第一個元素a分數爲2,第二個……

zcard set:查看集合中元素的數量

zscore set a:查看集合中a元素的分數

zcount set 0 5:查看集合中分數在0-5範圍的值的數量

zrank set a:查看a在set裏面的索引

zincrby set 10 a :給set裏面的a的分數增加10

zrange set 0 10:獲得索引0到10的元素,共11個

zrange set 0 10 withscores:獲得索引0到10的元素,並帶有分數值

 

一致性Hash算法

http://www.zsythink.net/archives/1182

問:爲什麼要使用一致性hash算法?

答:解決分佈式緩存存在的問題:

        當緩存服務器數量發生變化時,會引起緩存的雪崩,可能會引起整體系統壓力過大而奔潰(大量緩存同時失效),一致性hash就是爲了減少因服務器數量變化而受到影響的緩存

 

Redis五大數據類型應用場景

    1)參考鏈接:https://mp.weixin.qq.com/s/FE6we1KPKGwZL3NLLTefnw

    2)參考鏈接:https://mp.weixin.qq.com/s/_XjK2NhGgxuyZCwbvq-Hlw

 

Redis分佈式鎖

 

 

Redis集羣方案

Redis-Cluster(3.0、槽)、Redis Sharding(一致性hash)

參考鏈接:https://www.zhihu.com/question/21419897

Redis Sharding集羣:一致性hash算法

多Redis實例服務,比單Redis實例要複雜的多,這涉及到定位、協同、容錯、擴容等技術難題。這裏,我們介紹一種輕量級的客戶端Redis Sharding技術。

Redis Sharding可以說是Redis Cluster出來之前,業界普遍使用的多Redis實例集羣方法。其主要思想是採用哈希算法將Redis數據的key進行散列,通過hash函數,特定的key會映射到特定的Redis節點上。這樣,客戶端就知道該向哪個Redis節點操作數據。

Jedis的Redis Sharding實現具有如下特點:

1、採用一致性哈希算法(consistent hashing),將key和節點name同時hashing,然後進行映射匹配,採用的算法是MURMUR_HASH。採用一致性哈希而不是採用簡單類似哈希求模映射的主要原因是當增加或減少節點時,不會產生由於重新匹配造成的rehashing。一致性哈希隻影響相鄰節點key分配,影響量小。

2、爲了避免一致性哈希隻影響相鄰節點造成節點分配壓力,ShardedJedis會對每個Redis節點根據名字(沒有,Jedis會賦予缺省名字)會虛擬化出160個虛擬節點進行散列。根據權重weight,也可虛擬化出160倍數的虛擬節點。用虛擬節點做映射匹配,可以在增加或減少Redis節點時,key在各Redis節點移動再分配更均勻,而不是隻有相鄰節點受影響。

3、ShardedJedis支持keyTagPattern模式,即抽取key的一部分keyTag做sharding,這樣通過合理命名key,可以將一組相關聯的key放入同一個Redis節點,這在避免跨節點訪問相關數據時很重要。

 

Redis Sharding採用客戶端Sharding方式,服務端Redis還是一個個相對獨立的Redis實例節點,沒有做任何變動。同時,我們也不需要增加額外的中間處理組件,這是一種非常輕量、靈活的Redis多實例集羣方法。 

當然,Redis Sharding這種輕量靈活方式必然在集羣其它能力方面做出妥協。比如擴容,當想要增加Redis節點時,儘管採用一致性哈希,畢竟還是會有key匹配不到而丟失,這時需要鍵值遷移。 

作爲輕量級客戶端sharding,處理Redis鍵值遷移是不現實的,這就要求應用層面允許Redis中數據丟失或從後端數據庫重新加載數據。但有些時候,擊穿緩存層,直接訪問數據庫層,會對系統訪問造成很大壓力。有沒有其它手段改善這種情況?

Redis的作者提出了一種叫做presharding的方案來解決動態擴容和數據分區的問題,實際就是在同一臺機器上部署多個Redis實例的方式,當容量不夠時將多個實例拆分到不同的機器上,這樣實際就達到了擴容的效果。Pre-Sharding方法是將每一個臺物理機上,運行多個不同端口的Redis實例,假如有三個物理機,每個物理機運行三個Redis實例,那麼我們的分片列表中實際有9個Redis實例,當我們需要擴容時,增加一臺物理機來代替9箇中的一個redis,有人說,這樣不還是9個麼,是的,但是以前服務器上面有三個redis,壓力很大的,這樣做,相當於單獨分離出來並且將數據一起copy給新的服務器。值得注意的是,還需要修改客戶端被代替的redis的IP和端口爲現在新的服務器,只要順序不變,不會影響一致性哈希分片。

 

 

redis-cluster:哈希槽、投票容錯

Redis 3正式推出了官方集羣Cluster技術,解決了多Redis實例協同服務問題。Redis Cluster可以說是服務端Sharding分片技術的體現,即將鍵值按照一定算法合理分配到各個實例分片上,同時各個實例節點協調溝通,共同對外承擔一致服務。

Redis3.0版本開始正式提供Cluster集羣,Sharding採用slot(槽)的概念,一共分成16384個槽
   

 

 

Redis-Cluster投票:容錯

架構細節:

(1)所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬.

(2)節點的fail是通過集羣中超過半數的節點檢測失效時才生效.

(3)客戶端與redis節點直連,不需要中間proxy層.客戶端不需要連接集羣所有節點,連接集羣中任何一個可用節點即可

(4)redis-cluster把所有的物理節點映射到[0-16383]slot上,cluster 負責維護node<->slot<->value

 

Redis 集羣中內置了 16384 [0-16383]個哈希槽,當需要在 Redis 集羣中放置一個 key-value 時,redis 先對 key 使用 crc16 算法算出一個結果,然後把結果對 16384 求餘數,這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽,redis 會根據節點數量大致均等地將哈希槽映射到不同的節點

每個Redis物理結點負責一部分桶的管理,當發生Redis節點的增減時,調整桶的分佈即可
       例如,假設Redis Cluster三個節點A/B/C,則
       Node A 包含桶的編號可以爲: 0 到 5500.
       Node B 包含桶的編號可以爲: 5500 到 11000.
       Node C包含桶的編號可以爲: 11001 到 16384.

       當發生Redis節點的增減時,調整桶的分佈即可。
預分桶的方案介於“硬Hash”和“一致性Hash”之間,犧牲了一定的靈活性,但相比“一致性Hash“,數據的管理成本大大降低

使用哈希槽的好處就在於可以方便的添加或移除節點。

當需要增加節點時,只需要把其他節點的某些哈希槽挪到新節點就可以了;

當需要移除節點時,只需要把移除節點上的哈希槽挪到其他節點就行了;

 

爲了增加集羣的可訪問性,官方推薦的方案是將node配置成主從結構Master-Slave,即一個master主節點,掛n個slave從節點。這時,如果主節點失效,Redis Cluster會根據選舉算法從slave節點中選擇一個上升爲主節點,整個集羣繼續對外提供服務。


一個Redis  Node包含一定量的桶,當這些桶對應的Master和Slave都掛掉時,這部分桶對應的數據不可用

 

寫redis時

Redis Cluster使用異步複製
一個完整的寫操作步驟:
1.client寫數據到master
2.master告訴client "ok"
3.master傳播更新到slave
存在數據丟失的風險:
1. 上述寫步驟1)和2)成功後,master crash,而此時數據還沒有傳播到slave
2. 由於分區導致同時存在兩個master,client向舊的master寫入了數據。
當然,由於Redis Cluster存在超時及故障恢復機制,第2個風險基本上不可能發生

 

Redis的持久化方案

Redis的所有數據都是保存到內存中的。

Rdb:快照形式,定期把內存中當前時刻的數據保存到磁盤。Redis默認支持的持久化方案。

aof形式:append only file。把所有對redis數據庫操作的命令,增刪改操作的命令。保存到文件中。數據庫恢復時把所有的命令執行一遍即可。

 

Redis的持久化方案各自缺點

(1)redis的Rdb定期(默認支持)快照不能保證數據不丟失(保存到磁盤)

(2)redis的AOF(文件保存命令)會降低效率,並且不能支持太大的數據量

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章