推薦學習:
Redis資料型別及使用場景
Redis相比其它的KV資料庫,其一大特點是支援豐富的資料型別。它一共支援5種資料型別,下面逐一介紹這5種資料型別及其使用場景和內部實現方式。
string
簡介: string 型別是 Redis 中最基本的資料型別,最常用的資料型別,甚至被很多玩家當成 redis 唯一的資料型別去使用。string 型別在 redis 中是二進位制安全(binary safe)的,這意味著 string 值關心二進位制的字串,不關心具體格式,你可以用它儲存 json 格式或 JPEG 圖片格式的字串。
獲取字串長度
往字串append內容
設定和獲取字串的某一段內容
設定及獲取字串的某一位(bit)
批次設定一系列字串的內容
常用命令: set,get,decr,incr,mget 等。
應用場景:
(1) 儲存 MySQL 中某個欄位的值
把 key 設計為 表名:主鍵名:主鍵值:欄位名
(2) 儲存物件
string 型別支援任何格式的字串,應用最多的就是儲存 json 或其他物件格式化的字串。(這種場景下推薦使用 hash 資料型別)
set user:id:1 '[{"id":1,"name":"zj","email":"[email protected]"},{"id":1,"name":"zj","email":"[email protected]"}]'
(3) 生成自增 id
當 redis 的 string 型別的值為整數形式時,redis 可以把它當做是整數一樣進行自增(incr)自減(decr)操作。由於 redis 所有的操作都是原子性的,所以不必擔心多使用者端連線時可能出現的事務問題。
常用命令:hget,hset,hgetall 等。
應用場景:
存放結構化資料,比如使用者資訊。在Memcached或CKV中,對於使用者資訊比如使用者的暱稱、年齡、性別、積分等,我們需要先序列化後儲存為一個字串的值,這時候在需要修改其中某一項時,通常需要將所有值取出反序列化後,修改某一項的值,再序列化儲存回去。這樣不僅增大了開銷,也不適用於一些可能並行操作的場合(比如兩個並行的操作都需要修改積分)。而Redis的Hash結構可以使你像在資料庫中Update一個屬性一樣只修改某一項屬性值。如下圖:
Key是使用者ID, value是一個Map,這個Map的key是成員的屬性名,value是屬性值,這樣對資料的修改和存取都可以直接通過其內部Map的Key(Redis裡稱內部Map的key為field), 也就是通過key(使用者ID) + field(屬性標籤) 就可以操作對應屬性資料了,既不需要重複儲存資料,也不會帶來序列化和並行修改控制的問題。
不過這裡需要注意,Redis提供了介面(hgetall)可以直接取到全部的屬性資料,但是如果內部Map的成員很多,那麼涉及到遍歷整個內部Map的操作,由於Redis單執行緒模型的緣故,這個遍歷操作可能會比較耗時,而對其它使用者端的請求完全不響應,這點需要格外注意。
可用來建索引。比如User物件,除了id有時還要按name來查詢,可以建一個Key為user:name:id的Hash,在插入User物件時(set user:101{「id」:101,「name」:「calvin」}), 順便往這個hash插入一條(hset user:name:id calvin 101),這時calvin作為hash裡的一個key,值為101。按name查詢的時候,用hgetuser:name:id calvin 就能從名為calvin的key裡取出id。假如需要使用多種索引來查詢某條資料時可以使用,一個hash key搞定,避免使用多個string key存放索引值。
HINCRBY同樣可用於實現idmaker。相對string型別的idmaker每一個型別需要一個key,hash型別的用一個key即可。
hash資料型別在儲存上述型別的資料時具有比 string 型別更靈活、更快的優勢,具體的說,使用 string 型別儲存,必然需要轉換和解析 json 格式的字串,即便不需要轉換,在記憶體開銷方面,還是 hash 佔優勢。
實現方式:
Redis Hash對應Value內部實際就是一個HashMap,這裡會有2種不同實現,這個Hash的成員比較少時Redis為了節省記憶體會採用類似一維陣列的方式來緊湊儲存,而不會採用真正的HashMap結構,對應的value redisObject的encoding為zipmap,當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht。
簡介:
list 是按照插入順序排序的字串連結串列,可以在頭部和尾部插入新的元素(雙向連結串列實現,兩端新增元素的時間複雜度為 O(1))。插入元素時,如果 key 不存在,redis 會為該 key 建立一個新的連結串列,如果連結串列中所有的元素都被移除,該 key 也會從 redis 中移除。
常用命令:lpush,rpush,lpop,rpop,lrange等。
應用場景:
各種列表,比如twitter的關注列表、粉絲列表等,最新訊息排行、每篇文章的評論等也可以用Redis的list結構來實現。
訊息佇列,可以利用Lists的PUSH操作,將任務存在Lists中,然後工作執行緒再用POP操作將任務取出執行。這裡的訊息佇列並沒有ack機制,如果消費者把任務給Pop走了又沒處理完就宕機了怎麼辦?解決方法之一是加多一個sorted set,分發的時候同時發到list與sorted set,以分發時間為score,使用者把任務做完了之後要用ZREM消掉sorted set裡的job,並且定時從sorted set中取出超時沒有完成的任務,重新放回list。另一個做法是為每個worker多加一個的list,彈出任務時改用RPopLPush,將job同時放到worker自己的list中,完成時用LREM消掉。如果叢集管理(如zookeeper)發現worker已經掛掉,就將worker的list內容重新放回主list。
利用LRANGE可以很方便的實現list內容分頁的功能。
取最新N個資料的操作:LPUSH用來插入一個內容ID,作為關鍵字儲存在列表頭部。LTRIM用來限制列表中的專案數最多為5000。如果使用者需要的檢索的資料量超越這個快取容量,這時才需要把請求傳送到資料庫。
實現方式:
Redis list的實現為一個雙向連結串列,即可以支援反向查詢和遍歷,更方便操作,不過帶來了部分額外的記憶體開銷,Redis內部的很多實現,包括傳送緩衝佇列等也都是用的這個資料結構。
簡介:是一種無序的集合,集合中的元素沒有先後順序,不重複。將重複的元素放入Set會自動去重。
常用命令:
sadd,spop,smembers,sunion等。
應用場景:
某些需要去重的列表,並且set提供了判斷某個成員是否在一個set集合內的重要介面,這個也是list所不能提供的。
可以儲存一些集合性的資料,比如在微博應用中,可以將一個使用者所有的關注人存在一個集合中,將其所有粉絲存在一個集合。Redis還為集合提供了求交集、並集、差集等操作,可以非常方便的實現如共同關注、共同喜好、二度好友等功能,對上面的所有集合操作,你還可以使用不同的命令選擇將結果返回給使用者端還是存集到一個新的集合中。又比如QQ有一個社交功能叫做「好友標籤」,大家可以給你的好友貼標籤,比如「大美女」、「土豪」、「歐巴」等等,這裡也可以把每一個使用者的標籤都儲存在一個集合之中。
想要知道某些特定的註冊使用者或IP地址,他們到底有多少存取了某個頁面,可以這樣實現:SADD page:day1:<page_id> <user_id> 。想知道特定使用者的數量,使用SCARD page:day1:<page_id>。 需要測試某個特定使用者是否存取了這個頁面?SISMEMBER page:day1:<page_id>。
實現方式:
set 的內部實現是一個 value永遠為null的HashMap,實際就是通過計算hash的方式來快速排重的,這也是set能提供判斷一個成員是否在集合內的原因。
簡介:有序集合,相比set,元素放入集合時還要提供該元素的分數,可根據分數自動排序。
常用命令:
zadd,zrange,zrem,zcard等
使用場景:
存放一個有序的並且不重複的集合列表,比如twitter 的public timeline可以以發表時間作為score來儲存,這樣獲取時就是自動按時間排好序的。
可以做帶權重的佇列,比如普通訊息的score為1,重要訊息的score為2,然後工作執行緒可以選擇按score的倒序來獲取工作任務。讓重要的任務優先執行。
過期專案處理:使用unix時間作為關鍵字,用來保持列表能夠按時間排序。對current_time和time_to_live進行檢索,完成查詢過期專案的艱鉅任務。另一項後臺任務使用ZRANGE…WITHSCORES進行查詢,刪除過期的條目。
實現方式:
Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證資料的儲存和有序,HashMap裡放的是成員到score的對映,而跳躍表裡存放的是所有的成員,排序依據是HashMap裡存的score,使用跳躍表的結構可以獲得比較高的查詢效率,並且在實現上比較簡單。
推薦學習:
以上就是歸納概括Redis資料型別及使用場景的詳細內容,更多請關注TW511.COM其它相關文章!