《Redis学习二之使用场景》

最新推荐文章于 2023-11-20 14:26:39 发布

Twumf_1997

最新推荐文章于 2023-11-20 14:26:39 发布

阅读量184

点赞数 1

分类专栏： redis学习 Redis学习与记录文章标签： redis 场景

本文链接：https://blog.csdn.net/qq_34579313/article/details/88816330

版权

Redis学习与记录同时被 2 个专栏收录

3 篇文章 0 订阅

订阅专栏

redis学习

2 篇文章 0 订阅

订阅专栏

文章参考来自：https://www.cnblogs.com/xiaoxi/p/7007695.html

//指定Redis数据库连接的IP和端口  
String host = "192.168.33.130";  
int port = 6379;  
Jedis jedis = new Jedis(host, port);  
  
/** 
 * 限制网站访客访问频率 一分钟之内最多访问10次 
 *  
 * @throws Exception 
 */  
@Test  
public void test3() throws Exception {  
    // 模拟用户的频繁请求  
    for (int i = 0; i < 20; i++) {  
        boolean result = testLogin("192.168.1.100");  
        if (result) {  
            System.out.println("正常访问");  
        } else {  
            System.err.println("访问受限");  
        }  
    }  
  
}  
  
/** 
 * 判断用户是否可以访问网站 
 *  
 * @param ip 
 * @return 
 */  
public boolean testLogin(String ip) {  
    String value = jedis.get(ip);  
    if (value == null) {  
        //初始化时设置IP访问次数为1  
        jedis.set(ip, "1");  
        //设置IP的生存时间为60秒，60秒内IP的访问次数由程序控制  
        jedis.expire(ip, 60);  
    } else {  
        int parseInt = Integer.parseInt(value);  
        //如果60秒内IP的访问次数超过10，返回false,实现了超过10次禁止分的功能  
        if (parseInt > 10) {  
            return false;  
        } else {  
            //如果没有10次，可以自增  
            jedis.incr(ip);  
        }  
    }  
    return true;  
}

这里有个疑问，为什么不自己自增，却使用的Redis的incr原子自增，那是因为自己做自增就要考虑多线程并发，存入缓存的次数值可能有重复的，不是很准确。

计数器（String类型）

数据统计的需求非常普遍，通过原子递增保持计数。例如，应用数、资源数、点赞数、收藏数、分享数等。

社交列表（List类型）

社交属性相关的列表信息，例如用户点赞列表、用户分享列表、用户收藏列表、用户关注列表、用户粉丝列表等。

记录前N个最新登陆的用户Id列表，超出的范围可以从数据库中获得，如下：

//把当前登录人添加到链表里
ret = r.lpush("login:last_login_times", uid)

//保持链表只有N位
ret = redis.ltrim("login:last_login_times", 0, N-1)

//获得前N个最新登陆的用户Id列表
last_login_list = r.lrange("login:last_login_times", 0, N-1)

比如sina微博：

在Redis中我们的最新微博ID使用了常驻缓存，这是一直更新的。但是我们做了限制不能超过5000个ID，因此我们的获取ID函数会一直询问Redis。只有在start/count参数超出了这个范围的时候，才需要去访问数据库。

我们的系统不会像传统方式那样“刷新”缓存，Redis实例中的信息永远是一致的。SQL数据库（或是硬盘上的其他类型数据库）只是在用户需要获取“很远”的数据时才会被触发，而主页或第一个评论页是不会麻烦到硬盘上的数据库了。

记录用户信息(Hash 类型)

我们简单举个实例来描述下Hash的应用场景，比如我们要存储一个用户信息对象数据，包含以下信息(如果key 、filed相同，是会覆盖之前的value值)：

用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储，主要有以下2种存储方式：

第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储，这种方式的缺点是，增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护，引入CAS等复杂问题。

第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户ID+对应属性的名称作为唯一标识来取得对应属性的值，虽然省去了序列化开销和并发问题，但是用户ID为重复存储，如果存在大量这样的数据，内存浪费还是非常可观的。

那么Redis提供的Hash很好的解决了这个问题，Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口，如下图：

也就是说，Key仍然是用户ID, value是一个Map，这个Map的key是成员的属性名，value是属性值，这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。很好的解决了问题。

这里同时需要注意，Redis提供了接口(hgetall)可以直接取到全部的属性数据，但是如果内部Map的成员很多，那么涉及到遍历整个内部Map的操作，由于Redis单线程模型的缘故，这个遍历操作可能会比较耗时，而另其它客户端的请求完全不响应，这点需要格外注意。

实现方式：

上面已经说到Redis Hash对应Value内部实际就是一个HashMap，实际这里会有2种不同实现，这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap，当成员数量增大时会自动转成真正的HashMap，此时encoding为ht。

交集、并集和差集（Set或者ZSet类型）

在某些场景中，例如社交场景，通过交集、并集和差集运算，可以非常方便地实现共同好友，共同关注，共同偏好等社交关系。

//book表存储book名称
set book:1:name "The Ruby Programming Language"
set book:2:name "Ruby on rail"
set book:3:name "Programming Erlang"

//tag表使用集合来存储数据，因为集合擅长求交集、并集
sadd tag:ruby 1
sadd tag:ruby 2
sadd tag:web 2
sadd tag:erlang 3

//即属于ruby又属于web的书？
 inter_list = redis.sinter("tag:web", "tag:ruby")
//即属于ruby，但不属于web的书？
 diff_list = redis.sdiff("tag:ruby", "tag:web")
//属于ruby和属于web的书的合集？
 union_list = redis.sunion("tag:ruby", "tag:web")

消息队列

Redis 能作为一个很好的消息队列来使用，依赖 List 类型利用 LPUSH 命令将数据添加到链表头部，通过 BRPOP 命令将元素从链表尾部取出。同时，市面上成熟的消息队列产品有很多，例如 RabbitMQ。因此，更加建议使用 RabbitMQ 作为消息中间件。

Twumf_1997

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
《Redis学习二之使用场景》

文章参考来自：https://www.cnblogs.com/xiaoxi/p/7007695.html目录缓存会话缓存时效性访问频率计数器社交列表记录用户判定信息交集、并集和差集热门列表与排行榜最新动态消息队列缓存对于热点数据，缓存以后可能读取数十万次，因此，对于热点数据，缓存的价值非常大。例如，分类栏目更新频率不高，但是绝大多数的页面...
复制链接

扫一扫