redis五種資料型別的應用
阿新 • • 發佈：2020-11-04
redis的五種資料型別和使用場景
string型別
string型別多用於快取
set key value(value可以為json字串)
setnx多用於分散式鎖(後面詳細整理)
計數器
incr article:{文章id}:readcount
get article:{文章id}:readcount
web叢集session共享
redis實現session共享
https://www.cnblogs.com/cxx8181602/p/9759645.html
分散式系統全域性序列號（分庫分表的主鍵可以使用此方法 批量生成id會提升效能）
incrby orderid 1000
setbit的位運算
https://www.jianshu.com/p/3a30f58ba62c
hash型別
物件儲存
mset user {user_id}:name test {user_id}:age 12
hget user {user_id}:name {user_id}:age
因為redis是單執行緒操作，有一個非常大的忌諱就是不要讓key太大，會導致執行該命令時間非常長，會阻塞執行緒，所以hash不要當作資料庫來用，只是儲存一些熱資料就行
在實際應用中，可以給hash的key來分段，有一點類似於資料庫分表那種思路，把資料儲存在不同的key中，切記，千萬不要讓一個key過大
可以用來實現購物車功能
實現方式如下圖
- 以使用者id為key
- 以商品id為field
- 商品數量為value
購物車操作流程 - 新增商品 hset cart:123 10010 1（123為user_id 10010為商品id）
- 增加數量 hincrby cart:123 10010 1
- 商品總數 hlen cart:123
- 刪除商品 hdel cart:123 10010
- 獲取購物車所有商品 hgetall cart:123
和string相比的優缺點
優點
- 同類資料歸檔，儲存比較方便
- 比string消耗的cpu更小
- 比string更節省儲存空間
缺點
- 過期功能不能用在field上，只能用在key上
- 不適合在叢集架構下大規模使用(叢集資料都是分片處理的，目的是讓資料分段均勻的儲存，比如把user表的資訊都存在hash中，就會導致那個key非常大，這樣就會導致某一個redis機器上的資料非常大，導致了資料傾斜)
list型別
可以實現常見的棧和佇列的資料結構，如下圖
阻塞佇列
Blocking MQ(阻塞佇列) = LPUSH + BRPOP（ BRPOP會一直等待）
微信，微博訊息流
博主發訊息直接發到粉絲的資訊list中，粉絲直接讀取即可，但是這種只適合粉絲比較少的情況
set型別應用場景
微信抽獎活動
- 點選參與抽獎 sadd key {user_id}
- 檢視所有抽獎使用者 smambers key
- 抽取count名中獎者 srandmember key count 或者 spop key count(spop從集合中取出資料後會刪除掉 適合不能重複抽獎的場景)
** 微信微博點讚的實現**
- msg_id為朋友圈id user_id為點贊操作的使用者的id
- 點贊： sadd like:{msg_id} {user_id}
- 取消點贊： srem like:{msg_id} {user_id}
- 檢查使用者是否點過贊 : sismember like:{msg_id} {user_id}
- 獲取點贊使用者列表: smembers like:{msg_id}
- 獲取點贊使用者數: scard like:{msg_id}
可以做一些簡單的推薦
用交集 差集等功能，做一些比較簡單的推薦
- sinter
- sunion
- sdiff
注意 交集 差集運算速度比較慢，如果使用的話 最好用單獨的例項
zset
實現新聞排行榜
- 點選新聞 zincrby news:date 1 news_id
- 展示當日排行前10 zrevrange news:date 0 9 withscores
- 展示7天排行榜
- datalist為7天的日期 逐個列舉
- zunionstore news:datelist 7 news:date1 news:date2 。。。。news:date7
- 展示7日排行前10
- ZRANGE news:datelist 0 9 WITHSCORES
關注我的技術公眾號，每週都有優質技術文章推送。
微信掃一掃下方二維碼即可關注：