有相关数据库开发经验的朋友都知道，随着数据量的增长,MySQL 已经满足不了大型互联网类应用的需求了， 在种情况下，redis以它基于内存存储数据的独特性能成为程序员们选择的数据库也不奇怪了，下面就来看看通常使用redis的一些场景，顺便了解一下redis的优缺点都体现在哪?

一般来说，redis适用的使用场景有以下一些：

缓存。对于热点数据，缓存以后可能读取数十万次，因此，对于热点数据，缓存的价值非常大。例如，分类栏目更新频率不高，但是绝大多数的页面都需要访问这个数据，因此读取频率相当高，可以考虑基于 Redis 实现缓存。

会话缓存。此外，还可以考虑使用 Redis 进行会话缓存。例如，将 web session 存放在 Redis 中。

时效性。例如验证码只有60秒有效期，超过时间无法使用，或者基于 Oauth2 的 Token 只能在 5 分钟内使用一次，超过时间也无法使用。

访问频率。出于减轻服务器的压力或防止恶意的洪水攻击的考虑，需要控制访问频率，例如限制 IP 在一段时间的最大访问量。

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

社交列表。社交属性相关的列表信息，例如，用户点赞列表、用户分享列表、用户收藏列表、用户关注列表、用户粉丝列表等，使用 Hash 类型数据结构是个不错的选择。

记录用户判定信息。记录用户判定信息的需求也非常普遍，可以知道一个用户是否进行了某个操作。例如，用户是否点赞、用户是否收藏、用户是否分享等。

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

热门列表与排行榜。按照得分进行排序，例如，展示最热、点击率最高、活跃度最高等条件的排名列表。

最新动态。按照时间顺序排列的最新动态，也是一个很好的应用，可以使用 Sorted Set 类型的分数权重存储 Unix 时间戳进行排序。

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

redis的优点分析如下：

1、支持多种数据类型 包括set,zset,list,hash,string这五种数据类型，操作非常方便。比如，如果你在做好友系统，查看自己的好友关系，如果采用其他的key-value系统，则必须把对应的好友拼接成字符串，然后在提取好友时，再把value进行解析，而redis则相对简单，直接支持list的存储(采用双向链表或者压缩链表的存储方式)。

2、 持久化存储 作为一个内存数据库，最担心的，就是万一机器死机，数据会消失掉。redi使用rdb和aof做数据的持久化存储。主从数据同时，生成rdb文件，并利用缓冲区添加新的数据更新操作做对应的同步。

3、丰富的特性 pub/sub，key过期策略，事务，支持多个DB等。

4、性能很好 由于是全内存操作，所以读写性能很好，可以达到10w/s的频率。公司有项目使用redis，目前的访问频率是80w/s，通过适当的部署，线上运行一切o

当然redis也是它的不足之处的：

1、由于 Redis 是内存数据库，所以，单台机器，存储的数据量，跟机器本身的内存大小。虽然 Redis 本身有 Key 过期策略，但是还是需要提前预估和节约内存。如果内存增长过快，需要定期删除数据。

2、redis是单线程的，单台服务器无法充分利用多核服务器的CPU。

以上就是对redi使用场景的相关内容的了解了，希望能对大家都所帮助，关注本站可以了解更多相关信息哦。