一为什么要使用Redis

28次阅读

共计 1704 个字符,预计需要花费 5 分钟才能阅读完成。

最近看过不少学习技术的文章,这些文章给了我不少的感触。我认为学习技术的时候不应该买一本很厚书就一头专进去。而应该按照以下方式来进行学习:

1. 先了解这些技术解决了什么样的问题,为什么这些要使用这些技术作为起始点;2. 了解了技术解决了什么问题之后?我们就可以继续深入下去了。如果我们对其中一个技术点感兴趣或者面试需要,那么我们可以
查找相关的书籍或者博客了解这个技术点是怎么实现的。3. 如果你还想继续深入学习,那么最后应该做的就是“对比性学习”了,不知道大家有没有感触:在大四的时候需要学论文,你会
参考多篇文章,这样进行对比,你对所需要学习的知识就会更加深入的理解。

这篇文章我将陈述 Redis 解决了什么问题。大部分内容都在网络上已经出现了,我只是进行简单的整理,文章的最后我会将参考文章的链接给出。

Redis 解决了什么问题?

大规模读写数据与数据库读写能力之间的矛盾
简单回顾一下 CPU 高速缓存的发展历程,为了解决 CPU 的计算速度与内存的读取速度之间的巨大差异,CPU 使用高速缓存来存放指令和数据。高速缓存从最初的主板缓存到现在的 3 级缓存,缓存大小也不断变大。来自网络的数据表明:CPU 高速缓存的命中率大约为 80%。

类比电脑发展过程中 CPU 与内存的矛盾,可以察觉到大型网站中大规模读写数据与数据库读写能力之间的矛盾与此矛盾类似。我们也可以在数据库与应用之间构建一块比数据库速度更快存储区域——缓存。大家最熟悉的也莫过于Redis用作 缓存,我们知道 Redis 的作者设计 Redis 的初衷是因为他使用关系型数据库时,无论如何优化,性能都不能达到自己的期望,于是便自己手写了一个内存数据库。
在做为缓存的情况下,我们有一下应用场景:
1. 热点数据 例如我们可以将SQL查询结果保存在内存中,也可以将用户经常查看的图片保存在内存中。

2. 排行榜 基于 Redis 提供的 zset 这种数据结构我们可以更加便捷的实现排行榜。实现排行榜的相关内容可以参考排行榜算法设计实现比较。在小规模数据的情况下,使用 Mysql 实现排行榜没有多少问题,但是一旦数据量上去了,那么持续的进行 Mysql 读写将会成为瓶颈。

3. 计数器 / 限速器 计数器的应用场景之一是统计用户的点赞数,限速器的应用场景之一是限制用户 ip 的访问次数。之所以 Redis 能用于计数器是因为 Redis 是单线程的,每次都必须前一个指令执行完,再执行下一个指令。这样就保证不会同时执行多条指令;也即不会出现并发问题。限速器的原理类似。

4. 共同好友 利用 Redis 提供的 Set 数据结构的求交集操作 sinter 可以更加便捷地求两个 Set 集合的交集;而使用数据库的连表查询将造成性能的开销很多,因为大型网站的用户数量巨大。

5. 简单消息队列 Redis 的提供的发布 / 订阅是一个极其简单的消息系统。它不像 Kafka 那样提供了分成不同的 topic 并且分成不同的分区并且提供持久化的功能。Redis的消息队列用在不需要高可靠的场景。

6. session 共享 Session 是用来记录是用户是谁。当在应用使用集群方式部署的时候,我们需要一个统一管理 session 的地方,可以使用数据库来记录 session,但是这时对数据库的性能要求较高,此外 session 通常是具有时效性的,这段逻辑我们需要在代码中实现,但是如果使用 Redis 来共享 session,那么不会出现这样的问题。

在学习 redis 的过程中,一直有一个疑问:当我们开发数据库应用程序时,可以使用 MyBatis 的一二级缓存,Guava 中的缓存模块,甚至
是 Java 自带的 Map 数据结构来达到缓存数据的目的,为什么还要使用 Redis 作为缓存呢?参考一篇博客总结如下:1. 无论 MyBatis 的缓存,还是 Guava,Map 数据结构作为缓存,它们的生命周期都是随着 JVM 的销毁而结束。在微服务或者应用程序挂掉的
时候,我们并不希望缓存也消失。2. 在多个实例的情况下,存在数据不一致。如一个微服务启动多个实例,或者多个节点上部署同一个微服务,这时不同实例内缓存的数据
不一致。

参考:
CPU 缓存
读完这篇文章,你就知道为什么生产环境大多数要用 redis 数据库!

正文完
 0