Redis 常见使用场景

最新推荐文章于 2024-04-17 00:33:46 发布

冒菜-码农

最新推荐文章于 2024-04-17 00:33:46 发布

阅读量440

点赞数

分类专栏： redis 文章标签： redis 缓存使用场景

本文链接：https://blog.csdn.net/qq_33333654/article/details/127203662

版权

redis 专栏收录该内容

20 篇文章 3 订阅

订阅专栏

常用命令说明

1.String

适合简单的key,value存储结构，类似于之前使用过的cache，memcached的存储结构。应用场景：短信验证码，配置信息等。

常用命令：

1.1 incr：自增

1.1 decr：自减

1.1 incrby：加（加上指定的值）

1.1 decrby：减（加上指定的值）

2.Hash

一般key为id或者唯一标识，value存储对应的详情信息，应用场景：个人详情，商品详情等。、

2.1 hset：添加hash数据

2.2 hget：获取hash数据

2.3 hmget：获取多个hash 中key的数据

3.List

应为list是有序的，适合存储一些格式相对固定的数据结构，应用场景：省市区，字典信息等。

常用命令：

3.1 lpush：从左边推入

3.2 rpush：从右边推入

3.3 lpop：从左边弹出

3.4 rpop：从右边弹出

3.4 llen：查看某个list集合的长度

4.Set

可以理解为ID-List 模式，set最厉害的地方是可以求两个set集合的交集，并集，差集等，应用场景：相关好友，关注列表，收藏夹等。

4.1 sadd：添加数据

4.2 scard：查看set集合中元素的个数

4.3 sismember：判断set集合中是否存在某个元素

4.4 srem：删除某个元素

4.5 smembers：返回集合中所有成员

5.Sorted Set

set的升级版，增加了一个score参数，可以根据score参数进行排序。应用场景：排行榜数据等。

5.1 zadd：添加数据

5.2 zcard：查询元素数量

5.3 zrange：对集合进行排序

补充

高版本的还有一个bit

String

缓存热点数据

热点数据缓存（例如报表、明星出轨），对象缓存、全页缓存、可以提升热点数据的访问数据，
以及我们常用的字典、树形结构数据等

数据共享(分布式下)

最常用的就是分布式session
以及一些多任务的调度服务
当然也可以当做多线程的共享数据源进行使用(这个有点偏了)

分布式锁

String 类型setnx方法，只有不存在时才能添加成功，返回true

public static boolean getLock(String key) {
    Long flag = jedis.setnx(key, "1");
    if (flag == 1) {
        jedis.expire(key, 10);
    }
    return flag == 1;
}

public static void releaseLock(String key) {
    jedis.del(key);
}

分布式锁使用redis只是一种方案，分布式情况下也可以考虑开源的seata

全局ID

使用雪花算法生成唯一ID作为全局的唯一KEY使用
当然也可以使用int类型的incrby
亦或者自己业务生成唯一ID，比如用户ID+时间戳+业务场景枚举

限速

典型应用场景：验证码接口访问频率限制，用户登陆时需要让用户输入手机验证码，从而确定是否是用户本人，但是为了短信接口不被频繁访问，会限制用户每分钟获取验证码的频率，例如一分钟不能超过5次。

位统计

String类型的bitcount（1.6.6的bitmap数据结构介绍）
字符是以8位二进制存储的

set k1 a
setbit k1 6 1
setbit k1 7 0
get k1 
/* 6 7 代表的a的二进制位的修改
a 对应的ASCII码是97，转换为二进制数据是01100001
b 对应的ASCII码是98，转换为二进制数据是01100010

因为bit非常节省空间（1 MB=8388608 bit），可以用来做大数据量的统计。
*/

例如：在线用户统计，留存用户统计

setbit onlineusers 01 
setbit onlineusers 11 
setbit onlineusers 20

支持按位与、按位或等等操作

BITOPANDdestkeykey[key...] ，对一个或多个 key 求逻辑并，并将结果保存到 destkey 。       
BITOPORdestkeykey[key...] ，对一个或多个 key 求逻辑或，并将结果保存到 destkey 。 
BITOPXORdestkeykey[key...] ，对一个或多个 key 求逻辑异或，并将结果保存到 destkey 。 
BITOPNOTdestkeykey ，对给定 key 求逻辑非，并将结果保存到 destkey 。

计算出7天都在线的用户

BITOP "AND" "7_days_both_online_users" "day_1_online_users" "day_2_online_users" ...  "day_7_online_users"

以上摘自网络，个人觉得使用Bitmap数据结构反而更便捷，看个人吧

购物车

使用string or hash 均可以
string的话最直接的就是一个集合大json

int

计数器

int类型，incr方法

例如：文章的阅读量、微博点赞数、允许一定的延迟，先写入Redis再定时同步到数据库

限流

int类型，incr方法

以访问者的ip和其他信息作为key，访问一次增加一次计数，超过次数则返回false

hash

购物车

string也可以实现
其实效率上来讲hash是更高的

无序的数据集

一些公共的无序数据集可以使用hash

list

时间轴

之前在做医学相关系统的时候经常用到患者的病例记录或者患者的常规检测记录，这种使用时间轴是在合适不过了

消息队列

List提供了两个阻塞的弹出操作：blpop/brpop，可以设置超时时间

blpop：blpop key1 timeout 移除并获取列表的第一个元素，如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
brpop：brpop key1 timeout 移除并获取列表的最后一个元素，如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
上面的操作。其实就是java的阻塞队列。学习的东西越多。学习成本越低

队列：先进先除：rpush blpop，左头右尾，右边进入队列，左边出队列
栈：先进后出：rpush brpop

 		lpush + lpop = Stack(栈)

        lpush + rpop = Queue(队列)

        lpush + ltrim = Capped Collection(有限集合)

        lpush + brpop = Message Queue(消息队列)

一些常规的列表

比如文章列表
每个用户有属于自己的文章列表，现在需要分页展示文章列表。此时可以考虑使用列表，因为列表不但是有序的，同时支持按照索引范围获取元素。

set

点赞、签到、打卡

假如上面的微博ID是t1001，用户ID是u3001

用 like:t1001 来维护 t1001 这条微博的所有点赞用户

点赞了这条微博：sadd like:t1001 u3001
取消点赞：srem like:t1001 u3001
是否点赞：sismember like:t1001 u3001
点赞的所有用户：smembers like:t1001
点赞数：scard like:t1001
是不是比数据库简单多了。

交集、并集、差集

// 获取差集
sdiff set1 set2
// 获取交集（intersection ）
sinter set1 set2
// 获取并集
sunion set1 set2

假如：iPhone11 上市了

sadd brand:apple iPhone11

sadd brand:ios iPhone11

sad screensize:6.0-6.24 iPhone11

sad screentype:lcd iPhone 11

赛选商品，苹果的、ios的、屏幕在6.0-6.24之间的，屏幕材质是LCD屏幕

sinter brand:apple brand:ios screensize:6.0-6.24 screentype:lcd

用户关注、推荐模型

follow 关注 fans 粉丝

相互关注：

sadd 1:follow 2
sadd 2:fans 1
sadd 1:fans 2
sadd 2:follow 1
我关注的人也关注了他(取交集)：

sinter 1:follow 2:fans
可能认识的人：

用户1可能认识的人(差集)：sdiff 2:follow 1:follow
用户2可能认识的人：sdiff 1:follow 2:follow

排序-排行榜

id 为6001 的新闻点击数加1：
zincrby hotNews:20190926 1 n6001

获取今天点击最多的15条：
zrevrange hotNews:20190926 0 15 withscores

总结

  三种缓存用户信息优缺点比较：

              原生字符串类型：每个属性一个键

                   优点：简单直观，每个属性都支持更新操作。

                   缺点：占用过多的键，内存占用量较大，同时用户信息内聚性比较差，所以此种方案一般不会在生产环境使用。

             序列化字符串类型：将用户信息序列化后用一个键保存。

                  优点：简化编程，如果合理的使用序列化可以提高内存的使用效率。

                  缺点：序列化和反序列化有一定的开销，同时每次更新属性都需要把全部数据取出进行反序列化，更新后再序列化到Redis中。

             哈希类型：每个用户属性使用一对field-value，但是只用一个键保存。

                  优点：简单直观，如果使用合理可以减少内存空间的使用。

                  缺点：要控制哈希在ziplist和hashtable两种内部编码的转换，hashtable会消耗更多内存。