1. 统计文章的统计,统计多少人看了多少这篇文章
INCR article:readcount:{文章id} GET article:readcount:{文章id}
2. 批量生成系统全局系列号(使用redis批量生成序列号提升性能)
分库分表自增方式搞不定的情况下 可以使用:1.redis 2 .雪花算法
INCR orderId 1
每一张表的并发达到几千 ,就使用主键的生成使用自增表浪费Redis性能 ?
优化 可以使用批量获取INCRBY orderId 1000 .每台节点都能获取到1000个ID
放在应用内存中,在内存中获取。如果节点挂了也没事 浪费了一些ID而已~
3.介绍hash
HSET key field value //存储一个哈希表key的键值
HSETNX key field value //存储一个不存在的哈希表key的键值
HMSET key field value [field value ...] //在一个哈希表key中存储多个键值对
HGET key field //获取哈希表key对应的field键值
HMGET key field [field ...] //批量获取哈希表key中多个field键值
HDEL key field [field ...] //删除哈希表key中的field键值
HLEN key //返回哈希表key中field的数量
HGETALL key //返回哈希表key中所有的键值
HINCRBY key field increment //为哈希表key中field键的值加上增量increment
电商购物车
- 以用户ID为key
- 商品ID为field
- 数量为value
购物车操作
- 添加购物车:hset cart:1001 10088 1
- 删除购物车商品:hdel cart:1001 10088
- 增加数量:hincrby cart:1001 10088 2
- 获取购物车列表:hgetall cart:1001
- 商品总数:hlen cart:1001
hash结构的优点:
- 同类数据归类整合存储,方便数据管理
- 使用hash散列既可以减少创建键的数量又可以避免键名冲突。
- 使用hash散列比使用字符串键更节约内存。因为在数据库中创建key都有数据库附加的管理信息(比如键的类型,最后一次访问时间等等),所以keys越多,服务器在存储附加管理信息方面消耗的内存就越多,同时花在管理数据库中key的cpu也会越多。而且redis本事也会对hash的存储做一些底层的优化,内存消耗更少。
hash的缺点
- 过期功能不是使用在field,只能使用在key上
- Redis集群架构下不适合大规模使用,因为无法进行数据分片存储,会导致数据过于集中,从而导致单节点压力过大
4.介绍List
LPUSH key value [value ...] //将一个或多个值value插入到key列表的表头(最左边)
RPUSH key value [value ...] //将一个或多个值value插入到key列表的表尾(最右边)
LPOP key //移除并返回key列表的头元素
RPOP key //移除并返回key列表的尾元素
LRANGE key start stop //返回列表key中指定区间内的元素,区间以偏移量start和stop指定
BLPOP key [key ...] timeout //从key列表表头弹出一个元素,若列表中没有元素,阻塞等待 timeout秒,如果timeout=0,一直阻塞等待
BRPOP key [key ...] timeout //从key列表表尾弹出一个元素,若列表中没有元素,阻塞等待 timeout秒,如果timeout=0,一直阻塞等待
常用数据结构
Stack(栈) = LPUSH + LPOP FILO
Queue(队列)= LPUSH + RPOP
Blocking MQ(阻塞队列)= LPUSH + BRPOP
场景:公众号或者微博首页消息推送
上海去哪吃发了一个微博或者消息,后台会有个定时任务 ,往每个粉丝都会放一个这样的消息10018,每个人都有一个自己的专属的消息列表。如果需要查询的话就非常easy~,直接LRANGE msg:{wangzx-ID} 0 5 就可以查询出5条。
如果使用数据库会非常麻烦,用List来实现就非常简单 ,数据库的性能绝对扛不住的
1)上海美食攻略发微博,消息ID为10018
LPUSH msg:{wangzx-ID} 10018
2)上海去哪吃发微博,消息ID为10086
LPUSH msg:{wangzx-ID} 10086
3)查看最新微博消息
LRANGE msg:{wangzx-ID} 0 5
5:SET
Set基本操作
SADD key member [member ...] //往集合key中存入元素,元素存在则忽略,若key不存在则新建
SREM key member [member ...] //从集合key中删除元素
SMEMBERS key //获取集合key中所有元素
SCARD key //获取集合key的元素个数
SISMEMBER key member //判断member元素是否存在于集合key中
SRANDMEMBER key [count] //从集合key中选出count个元素,元素不从key中删除
SPOP key [count] //从集合key中选出count个元素,元素从key中删除
场景:抽奖
1.将参与者都放入(不会重复添加):SADD key(活动ID) {userlD}
2.查看参与抽奖所有用户 :SMEMBERS key(活动ID)
3.抽取参与者:SRANDMEMBER key [count]/SPOP key [count]
没有删除参与者
参与过的人不能再次参与
场景2:微博点赞,朋友圈点赞
- 点赞:SADD like:{消息ID} {用户ID}:
- 取消点赞:SREM like:{消息ID} {用户ID}
- 检查用户是否点过赞:SISMEMBER like:{消息ID} {用户ID}
- 获取点赞的用户列表:SMEMBERS like:{消息ID}
- 获取点赞用户数 :SCARD like:{消息ID}
Set运算操作
SINTER key [key ...] //交集运算
SINTERSTORE destination key [key ..] //将交集结果存入新集合destination中
SUNION key [key ..] //并集运算
SUNIONSTORE destination key [key ...] //将并集结果存入新集合destination中
SDIFF key [key ...] //差集运算
SDIFFSTORE destination key [key ...] //将差集结果存入新集合destination中
交集:SINTER set1 set2 set3 -> { c }
并集:SUNION set1 set2 set3 -> { a,b,c,d,e }
差集 (第一个减去 第二个集合 和第三个集合): SDIFF set1 set2 set3 -> { a }
场景:集合操作实现微博微信关注模型
wangzx关注的人:{zhangbin,zhangsan,zhangru,lisi}
zhangbing关注的人:{zhangru,zhangsan,wangwu,chailiu}
zhangru关注的人 :{chailiu,zhangsan}
wangzx和zhangbing共同关注的人:SINTER set1 set2
我可能认识的人(朋友的人减去我们共同认识的人):sdiff sdiff zhangbing wangzx
集合操作实现电商商品筛选
SADD brand:huawei P30
SADD brand:xiaomi mi-6X
SADD brand:iPhone iphone8
SADD os:android P30 mi-6X
SADD cpu:brand:intel P30 mi-6X
SADD ram:8G P30 mi-6X iphone8
SINTER os:android cpu:brand:intel ram:8G {P30,mi-6X}
6.ZSET
ZSet常用操作
ZADD key score member [[score member]…] //往有序集合key中加入带分值元素
ZREM key member [member …] //从有序集合key中删除元素
ZSCORE key member //返回有序集合key中元素member的分值
ZINCRBY key increment member //为有序集合key中元素member的分值加上increment
ZCARD key //返回有序集合key中元素个数
ZRANGE key start stop [WITHSCORES] //正序获取有序集合key从start下标到stop下标的元素
ZREVRANGE key start stop [WITHSCORES] //倒序获取有序集合key从start下标到stop下标的元素
Zset集合操作
ZUNIONSTORE destkey numkeys key [key ...] //并集计算
ZINTERSTORE destkey numkeys key [key …] //交集计算
场景:微博热搜
1)点击新闻
ZINCRBY hotNews:20190819 1 守护香港
2)展示当日排行前十
ZREVRANGE hotNews:20190819 0 10 WITHSCORES
3)七日搜索榜单计算
ZUNIONSTORE hotNews:20190813-20190819 7
hotNews:20190813 hotNews:20190814... hotNews:20190819
4)展示七日排行前十
ZREVRANGE hotNews:20190813-20190819 0 10 WITHSCORES