关于redis:redis五种数据类型的应用

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 更节俭存储空间

毛病

• 不适宜在集群架构下大规模应用(集群数据都是分片解决的，目标是让数据分段平均的存储，比方把 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

关注我的技术公众号，每周都有优质技术文章推送。
微信扫一扫下方二维码即可关注：