redis 为什么这么快,你真的知道吗?
Posted 肥肥技术宅
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了redis 为什么这么快,你真的知道吗?相关的知识,希望对你有一定的参考价值。
前言
相信大家在面试过程中,都被面试官问到过这样一个问题,缓存中间件大名鼎鼎的 redis 速度为什么这么快呢?
针对于面试过程中的痛点问题,笔者昨晚熬夜收集资料,并且通过走访大量使用者,整理出如下的结论。我敢保证,你看了这篇文章,再问你这个问题,保准把面试官虐哭。
分析原因
这里就不卖关子了,先说结论,我们再对原因进行抽丝剥茧。
redis快的原因
- 纯内存操作(最主要条件)
- 合适的线程模型
- 优秀的数据结构
- 合理的数据编码方式
纯内存操作(最主要条件)
首先最主要的原因一定是:redis 的数据操作是基于内存的
。
众所周知,内存的访问速度是远远大于硬盘访问速度的。我们来做个对比,拿数据库(硬盘)和 redis (内存)对比,一个操作对应磁盘,一个操作对应内存。他们两个的的访问速度差了一个数量级。
可能大家对数量级没有什么该概念。那可是整整 1000 倍啊!现在大家知道了吧。
下面是我精心为大家准备的访问速度图,已经验证,方便大家食用。
有的小伙伴要问了,redis不是有数据持久化吗?
怎么会是只操作内存呢?
这位同学一看就是对 redis 理解的不够透彻,redis 持久化线程和操作内存数据的线程,并不是一个线程,我们这里说的 redis 快,只是针对操作内存的线程来说的,操作很快。因为操作是直接客户端响应时间息息相关的。
合适的线程模型
🥈单线程误区
先说一个
常见误区
,就是大家在其他的文章或者面试题中,通过一段时间的以讹传讹。
大家都认为 redis 速度快,有一个原因是单线程!!!
在这里先反驳一下这个观点,这个结论是个明显的因果颠倒,主次不分的结论!!
为什么这么说呢?
首先单线程 redis
不是纯粹的单线程,我们所知晓的 redis
单线程只有 网络请求模块
和 数据操作模块
是单线程的。
你要知道多线程的出现,本身就是为了解决多核心 CPU 利用率不足。如果单线程是快的原因的话,那么我们还要多线程干什么,小伙伴你说是吧!
那为什么不用多线程呢?
因为没有必要,我们先来想一下多线程适用场景有哪些?
在这之前,我们先了解一下计算机在运行过程中的主要操作分为以下两种:
CPU 计算操作
网络和磁盘 IO 读取操作
多线程的出现以及适用场景目的就是为了提升单线程在 cpu利用率和io利用率之间的不足
那么redis怎么不需要多线程呢?
我们从上面的计算机操作分类来说
- 从 CPU 计算来说,
redis
操作都是基于内存操作,很少有一些耗费CPU 的计算操作,对于 redis 操作来说,CPU 计算不是瓶颈,瓶颈在于 redis 操作内存的速度。 - 从网络 IO 来说,
redis
的网络 IO 接收事件
,确实是一个很需要去提升的点 因为所有客户端对 redis 的操作 最终都会由redis
的网络模块接受 ,所以对于 redis 来说 提升网络 IO 的利用率 很有必要。
结论
:redis 在 CPU 计算上不存在瓶颈,性能瓶颈只存在于网络 IO 中
但是~想要提高网络 IO 的利用率,不是只有多线程一条路。
redis
由于历史遗留原因最终没有采用多线程处理网络 IO 而是采取了 单线程 + 多路复用器处理。- 在2020年,
redis 6.0版本
已经开始做多线程处理网络 IO ,性能提升巨大。
所以说千万不要陷入 redis
是单线程所以快,现在是 CPU 多核心时代,最差的情况 CPU 一个核心绑定一个线程,不同线程之间也不处理竞态资源,也比你只用到一个核心处理快的多了吧!
我这里总结一下我的看法,redis 6.0版本
之前采用单线程处理网络 IO 原因如下:
- redis 为了保持一贯的语义,采用了单线程模型(也许是懒吧)
- 就算是单线程,也完全足够用了,在不需要超大并发的情况下,也不需要上多线程。
那为什么redis 6.0 还是采用了多线程处理网络 IO ?
不是说多路复用技术已经大大的提升了网络 IO 利用率了么,为啥还需要多线程?
主要是因为我们对 Redis 有着更高的要求。
据测算,redis
将所有数据放在内存中,内存的响应时长大约为 100 纳秒,对于小数据包,redis
服务器可以处理 80,000 到 100,000 QPS,这么高的对于 80% 的公司来说,单线程的 redis
已经足够使用了。
但随着越来越复杂的业务场景,有些公司动不动就上亿的交易量,因此需要更大的 QPS。
为了提升 QPS,很多公司的做法是部署 redis集群
,并且尽可能提升 redis
机器数。但是这种做法的资源消耗是巨大的。
而经过分析,限制 redis
的性能的主要瓶颈出现在网络IO的处理上,虽然之前采用了多路复用技术。但是我们前面也提到过,多路复用的 IO 模型本质上仍然是同步阻塞型 IO 模型。
下图是 redis
网络 IO 多线程和单线程的速度对比图,大家都来看一下
从上面可以看到 `GET/SET` 命令在 4 线程 IO 时性能相比单线程是几乎是翻倍了。
结论
:redis 6.0 多线程网络 IO 性能提升巨大,不严谨条件下几乎翻倍
🥈单线程模式下快的原因
说完了对于单线程的误区,下面我们就要说一下在单线程模式下,redis
快的原因
用四个字就可以来形容这个原因,那就是 多路复用
多路复用是啥呢?
简单理解就是 单个线程同时检测若干个网络连接(Socket)是否可以执行IO操作的能力,就是将多个进程的网络 IO Socket注册到同一个管道上。 用最少的资源,干最多的事情。
比较传统的方式是使用多线程模型,每来一个客户端连接,就分配一个线程,然后后续的读写都在对应的进程/线程,这种方式处理 100 个客户端没问题,但是当客户端增大到 10000 个时,10000 个进程/线程的调度、上下文切换以及它们占用的内存,都会成为瓶颈。
为了解决上面这个问题,就出现了 I/O 的多路复用,可以只在一个进程里处理多个文件的 I/O
所有的 io 操作 由这一个管道来和内核进行统一交互 管道中的io请求数据准备好之后 管道会将数据 拷贝到用户空间中。
在 redis
中,每当一个套接字准备好执行连接应答、写入、读取、关闭等操作时,就会产生一个文件事件。因为一个服务器通常会连接多个套接字,所以多个文件事件有可能会并发地出现。
但是出现的个数不可能有很多,这样我们用一个线程来监听这些消息,然后分派去给操作线程执行就可以。
多路复用模型显而易见的好处:
单线程,省去多个线程创建和上下文切换操作
Socket 连接不多的情况,性能甚至比多线程有可能要高
优秀的数据结构
redis 在存储数据结构的设计上还是花了一番心思的 不然这也不会成为它快的一点原因。
它拥有五种常用的数据类型,帮助我们在各种各样的场景上都能灵活应对,并且也能用对应的数据类型做出很多很有意思的事情。
redis的五种数据类型主要有:
- String 整数浮点数或者字符串
- Set 集合
- Zset 有序集合
- Hash 散列表
- List 列表
举个例子,我们都知道redis底层使用c语言写的,但是 String 实现并不是简单的用c语言的字符串实现的,而是采用一个 SDS(简单动态字符串)
的结构体来实现的。
Tips:这里给大家补充一个知识点,C语言的String是以 “\\0” 结尾的,并且计算长度是得通过遍历获取,时间复杂度是 O(n) , 而且在数据中不能有 “\\0” 出现,会导致计算错误。
redis String
的 SDS 结构体,不仅让长度的获取是 O(1) 操作,而且二进制安全,没有特殊字符的限制,可以存储视频图片的数据。
这里我想让大家知道,redis 数据结构设计考虑还是很优秀的。
数据结构的详细解析,我们在这里就不多赘述了,我们放到我们的下一篇。
欢迎小伙伴们前去围观,也欢迎批评指正。
合理的数据编码方式
怎么理解这个合理的编码方式呢?
我们还是以 redis 中的 string 结构举例子,redis为了存储不同大小的字符串,精心设计了 5 种类型。
sdshdr5、sdshdr8、sdshdr16、sdshdr32、sdshdr64
它们的不同就是,本身的数据类型不同,举个例子
sdshdr16
中的字段分配大小是uint16 2^16
sdshdr32
中的字段分配大小是uint32 2^32
结论: 通过这种能够灵活存储不同大小的字符串,有效的节省了内存。字符串大的时候分配大的内存空间,小的时候就分配小的,高效利用内存。
当然,在这里只是举个例子,想了解更多redis 底层细节的小伙伴,我们放到了后续的系列。
欢迎小伙伴们前去围观,也欢迎批评指正。
总结
至此,我们知道了这个 redis 经典面试题的答案了。
原因无他。分别是:
纯内存操作
多路复用线程模型
优秀的数据结构
合理的数据编码方式
不知道大家学会了吗? 学会的小伙伴们,再也不怕那些刁钻的面试官了,我敢保证,你看了这篇文章,再问你这个问题,保准把面试官虐哭。
以上是关于redis 为什么这么快,你真的知道吗?的主要内容,如果未能解决你的问题,请参考以下文章