Redis列表类型使用场景

/ Redis / 没有评论 / 365浏览

我们了解一下Redis列表类型在实际的开发中的使用。

使用场景

一、消息队列

我们在实际的开发中如果有需要使用队列需求的话,除了使用专业的队列服务如ActiveMQ、Kafka等。我们还可以直接使用Redis的列表类型来实现简单的队列功能。并且在某些业务中使用Redis列表类型实现简单的队列功能,要比那些专业队列功能更简单。下面我们介绍一下怎么通过Redis的列表实现一个简单的队列。我们知道队列功能最简单的作用就是将消息的存储与获取。所以按照上一篇中介绍的命令一样,我们可以通过rpush命令将消息存储到列表中然后在使用lrange命令在将消息获取出来。这样就基本实现了队列的核心功能。这里说到核心功能,是因为,队列服务还有一个前提,就是必须保证消息不能被重复消费。所以,上述的实现方式会有一个问题,就是如果有多个客户端同时获取列表中的消息时,那么会导致,这个消息会同时被消费。那怎么解决呢?答案就是使用brpop命令。在上一篇中我们知道brpop命令是阻塞的命令。即使多个客户端同时获取消息,那么也会只有一个客户端成功获取消息,也就是最先调用brpop命令的客户端。这样也就保证了消息的安全性。


二、评论

我们知道,在电商网站中每个商品都有用户相应的评论,但由于电商网站中用户基数比较大,而且现在大部分网站的架构都是分布式服务的,所以网站中不同的功能,会会由不同的服务提供。就比如评论服务,如果评论服务的底层实现都从数据库中查询,那么在电商网站这种大并发的环境下,上述的底层实现是满足不了这种大并发环境的。所以大多数的网站架构会将这部分数据存储到缓存中,也就是Redis中。但如果将会部的评论数据都存储到Redis中,那么势必会导致Redis中的数据量过大,而导致Redis的性能降低。所以在实际的开发中,是不会将所有的评论数据都保存在Redis中的,而是将第一页的数据保存到Redis中,因为大部分的用户只会浏览第一页的评论,而其它的页的评论因为浏览量相比第一页较小,所以可以将这部分数据存储到数据库中,当有用户浏览时,在将这部分数据从数据库中同步到Redis中,而不是将所有页的评论都存储到Redis中,这样即解决了Redis中存储数据量过大的问题,也解决了大并发环境中的问题。


除此之外我们还可以用Redis中列表类型实现以下功能。