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
關注我的技術公眾號，每周都有優質技術文章推送，
微信掃一掃下方二維碼即可關注：
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/202458.html
標籤：其它
下一篇：MySQL 之 索引