03-Redis 凭什么这么快

875 阅读13分钟

大家好,我是飓风。

前两篇文章我们认识了redis 的数据结构,今天我们聊聊redis 快的原因是什么?以及我们在使用的时候应该注意的点有哪些?

网上的说法,大多数都是redis 是单线程,是基于内存,是io多路复用,但是只是都说了表面,比如为啥单线程就快,redis 单线程都干了什么?什么是io 多路复用,redis 怎么和io多路复用进行结合的等等都没有说清楚。

为什么采用单线程来实现?

如果采用多线程,那么势必就会有多线程上线文的开销。

如果采用多线程,对同一个key 的操作,必然就会有线程安全的问题,什么是线程安全?当有多个端或者线程去竞争一个公共的资源的时候,此时就会有线程安全的问题,那么要解决这个问题必然就会加锁,如果加锁就会带来锁竞争的消耗,同时也会增加redis 的负杂性。

如果你做过性能测试,你应该知道,随着你线程数量的增多,你应用的吞吐量是会增加,可是在随着线程的增加,你的应用的吞吐量就会持平,慢慢的就会下降。我想redis 也是因为考虑了着点,如果能让你配置线程的参数,可能会出现性能下降的问题。

还有按照官网的说法就是redis 基于内存操作,速度很快,cpu 不是它的瓶颈。

所以redis 并没有采用多线程的方式,一个是会增加锁的竞争和 线程的切换消耗,同时也会增加redis 的复杂性。

redis 采用io多路复用模型

在介绍io 多路复用之前 我们先看下scoket 模型 有哪几种模型。

最基本的阻塞 socket

要想客户端和服务器能在网络中通信,那必须得使用 Socket 编程,它是进程间通信里比较特别的方式,特别之处在于它是可以跨主机间通信。
建 Socket 的时候,可以指定网络层使用的是 IPv4 还是 IPv6,传输层使用的是 TCP 还是 UDP。
服务端首先调用 socket() 函数,创建网络协议为 IPv4,以及传输协议为 TCP 的 Socket ,接着调用 bind() 函数,给这个 Socket 绑定一个 IP 地址和端口。

绑定端口的目的:当内核收到 TCP 报文,通过 TCP 头里面的端口号,来找到我们的应用程序,然后把数据传递给我们。
绑定 IP 地址的目的:一台机器是可以有多个网卡的,每个网卡都有对应的 IP 地址,当绑定一个网卡时,内核在收到该网卡上的包,才会发给我们。

绑定完 IP 地址和端口后,就可以调用 listen() 函数进行监听,此时对应 TCP 状态图中的 listen。

服务端进入了监听状态后,通过调用 accept() 函数,来从内核获取客户端的连接,如果没有客户端连接,则会阻塞等待客户端连接的到来。

那客户端是怎么发起连接的呢?客户端在创建好 Socket 后,调用 connect()函数发起连接,该函数的参数要指明服务端的 IP 地址和端口号。

在 TCP 连接的过程中,服务器的内核实际上为每个 Socket 维护了两个队列:

  • 一个是还没完全建立连接的队列,称为 TCP 半连接队列,这个队列都是没有完成三次握手的连接,此时服务端处于 syn_rcvd 的状态;

  • 一个是一件建立连接的队列,称为 TCP 全连接队列,这个队列都是完成了三次握手的连接,此时服务端处于 established 状态;

当 TCP 全连接队列不为空后,服务端的 accept()函数,就会从内核中的 TCP 全连接队列里拿出一个已经完成连接的 Socket 返回应用程序,后续数据传输都用这个 Socket。

监听的 Socket 和真正用来传数据的 Socket 是两个:

  • 一个叫作监听 Socket;
  • 一个叫作已连接 Socket;

这个模型是最基本的io模型,是一个同步阻塞的方式,服务每次只能处理一个客户端的io请求,读写发生阻塞的时候,其他客户端是不能够和服务端进行连接的。

accept() 当去没有客户端请求链接的时候,会阻塞。
read() 当没有可读的数据时候,会阻塞。
write() 当没有可写的时候,会阻塞。

image.png

基于多进程的socket模型

前面提到最基本的socket 模型,属于一对一通信,那么你应用的并发量可想而知,同一时刻只能服务一个客户端,机器资源也会很浪费,那么我需要改进我们的socket 模型,以支持更多的客户端进行连接和读写操作。
可以使用多进程来解决这个问题,每来一个客户端的链接时候,就分配一个进行进行读写操作。

大致过程如下:

  1. 服务主进程监听客户端连接,与客户端连接成功后,accept() 函数会返回已经连接的 socket
  2. 主进程会fork() 一个子进程,会把主进程的文件描述符,内存地址空间、程序计数器、执行代码等都复制过来。
  3. 子进程直接使用已经连接的socket和客户端进行通信。

主进程只需要关心监听的socket,有连接成功的客户端就fork 子进程。
子进程只需关心已经连接的socket,进行客户端通信就可以了。

看下图,基本流程:

image.png

采用多进程来达到服务多个客户端连接的方式,当客户端数量很高的时候,你的进程数量就会很高,那么系统的负担就会加重,会占据系统大部分的资源,此外进程间的上下午切换是很重的,包含了虚拟内存、栈、全局变量等用户资源、还包含内核堆栈、寄存器等内核资源。所以在大并发量的情况下,这种方式并不是最优方案。

基于多线程的socket模型

基于多线程实现,多线程可以理解为是属于某个进程的,同进程内的线程是可以共享进程的部分资源的,比如文件描述符列表、进程空间、代码、全局数据、堆、共享库等,这些共享些资源在上下文切换时是不需要切换,而只需要切换线程的私有数据、寄存器等不共享的数据,因此同一个进程下的线程上下文切换的开销要比进程小得多。

此外线程频繁的创建和销毁是消耗资源的,开销也会很小,所以我应该利用线程池来达到线程的重用,避免线程的创建和销毁的开销。

基本流程看下图:

image.png

其实使用线程来处理连接的读写请求,还是和进程的处理连接的读写请求的问题是一样,这样会给系统带来很大的资源消耗,如果达到c10k,那么服务端就要维护1万了线程,那么此时的操作系统会是什么样子。

I/O多路复用

上面的两种方式不管是进程间的切换、还是线程间的切换,已经创建的进程的数量和线程的数量多少,都会给系统带来负担,那么能不能用一个进程程或者叫线程就可以监听多个socket呢?
那么我们今天的主角 I/O多路复用就卡咔咔咔 闪亮登场了。

那我们怎么能够通俗的理解这个玩意呢。

首先看的应为名字为 I/O multiplexing.

重要的事情再说一遍: I/O multiplexing 这里面的 multiplexing 指的其实是在单个线程通过记录跟踪每一个Sock(I/O流)的状态来同时管理多个I/O流. 发明它的原因,是尽量多的提高服务器的吞吐能力。

在同一个线程里面, 通过拨开关的方式,来同时传输多个I/O流

来来来, 看看下面的图:

image.png

I/O 多路复用三剑客

大家都应该听过select/poll/epoll ,其实它们三个就是 多路复用的三剑客,下面来介绍他们的来历和原理。

select/poll 基本流程

select 实现多路复用的方式是,将已连接的 Socket 都放到一个文件描述符集合,然后调用 select 函数将文件描述符集合拷贝到内核里,让内核来检查是否有网络事件产生,检查的方式很粗暴,就是通过遍历文件描述符集合的方式,当检查到有事件产生后,将此 Socket 标记为可读或可写, 接着再把整个文件描述符集合拷贝回用户态里,然后用户态还需要再通过遍历的方法找到可读或可写的 Socket,然后再对其处理。

所以,对于 select 这种方式,需要进行 2 次「遍历」文件描述符集合,一次是在内核态里,一个次是在用户态里 ,而且还会发生 2 次「拷贝」文件描述符集合,先从用户空间传入内核空间,由内核修改后,再传出到用户空间中。

image.png

select 使用固定长度的 BitsMap,表示文件描述符集合,而且所支持的文件描述符的个数是有限制的,在 Linux 系统中,由内核中的 FD_SETSIZE 限制, 默认最大值为 1024,只能监听 0~1023 的文件描述符。

poll 不再用 BitsMap 来存储所关注的文件描述符,取而代之用动态数组,以链表形式来组织,突破了 select 的文件描述符个数限制,当然还会受到系统文件描述符限制。

epoll

epoll 通过两个方面,很好解决了 select/poll 的问题。

第一点,epoll 在内核里使用红黑树来跟踪进程所有待检测的文件描述字,把需要监控的 socket 通过 epoll_ctl() 函数加入内核中的红黑树里,红黑树是个高效的数据结构,增删查一般时间复杂度是 O(logn),通过对这棵黑红树进行操作,这样就不需要像 select/poll 每次操作时都传入整个 socket 集合,只需要传入一个待检测的 socket,减少了内核和用户空间大量的数据拷贝和内存分配。

第二点, epoll 使用事件驱动的机制,内核里维护了一个链表来记录就绪事件,当某个 socket 有事件发生时,通过回调函数内核会将其加入到这个就绪事件列表中,当用户调用 epoll_wait() 函数时,只会返回有事件发生的文件描述符的个数,不需要像 select/poll 那样轮询扫描整个 socket 集合,大大提高了检测的效率。

Redis IO多路复用

redis利用epoll来实现IO多路复用,内核可以同时存在多个监听socket套接字和已经连接的套接字,内核会一直监听这些socket,只要有socket事件发生,就会交给redis 线程来处理,这样可以看出,一个redis线程就能处理多个io流了。

下图中redis 会利用epoll,让内核帮助它来监听socket,此时redis 并不会阻塞在某一个特定的监听或者已经连接的socket上,如果有事件过来,epoll_wait() 就会返回事件就绪的FD给redis主线程,redis主线程就会将连接信息和事件放到队列中,然后主线程会让事件分派器消费队列.大致流程看下图:

图中FD 是指 有事件就绪的socket。

连接处理器会处理 accept 事件。
命令请求处理器处理 命令请求,也就是可读的事件。
命令回复处理器 处理 命令回复 ,也就是写事件。

image.png

IO多路的单线程模型:

  1. redis启动时,向epoll注册还未使用的FD的可连接事件。
  2. 连接事件产生时,epoll机制自动将其放入自己的可连接事件队列中。
  3. redis线程调用epoll的wait,获取所有事件,拷贝存入自己用户线程的内存队列中。
  4. 遍历这些内存队列,通过事件分派器,交由对应事件处理器处理。如是可连接事件则交由对应的连接应答事件处理器处理。可读事件交给命令请求处理器,可写事件交给命令回复处理器处理。
  5. 对应处理器执行相应逻辑。执行完成时,再次向epoll注册对应事件,比如连接事件的那个FD,接下来要注册可读事件,并重新注册可连接事件。命令请求处理器执行完后,要将FD注册可写事件。命令回复处理器执行完后,需要将FD取消注册可写事件。

Redis 底层数据结构

  1. redis 哈希表,在查找key 的时候,能够做o(1) 的复杂度。
  2. 对于有序的集合,采用跳表来实现,复杂度为 o(logN)。
  3. 对于压缩列表 和整数数组 可以对短数据进行压缩,节省了内存空间。
  4. 对于压缩列表和双端链表,可以实现队列, pop 和 push 操作 的时间复杂度为 o(1)。
  5. bitmap,对于只有两种值的判断来说,既能节能内存,也能做到低延迟。
  6. 集合类中元素的个数,redis 已经算好,例如LLEN ,SCARD 复杂度都是o(1)。

redis 速度慢了

  1. 尽量使用自己单个操作的时间很短。
  2. 合理使用redis 的数据结构,每种结构都有自己的应用场景。
  3. 减少对集合的全部查询,如HMGET HGETALL SMEMBBERS LRANGE 等 范围的查找。
  4. 不要使用keys* 之类的操作。
  5. 不要存储bigkey,bigkey 再分配空间(阻塞redis主线程)和删除释放空间(可以设置为异步)、带宽都会受到影响。

总结

今天学习了redis 快的原因,节下来我们来总结下。

Redis是纯内存数据库,相对于读写磁盘,读写内存的速度就不是几倍几十倍了,一般,hash查找可以达到每秒百万次的数量级。

Redis采用了单线程的模型(io解析和读写操作由一个线程来完成),保证了每个操作的原子性,也减少了线程的上下文切换、公共资源锁的开销与竞争。

redis 采用IO多路复用 ,“多路”指的是多个网络连接,“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络IO的时间消耗)。可以直接理解为:单线程的原子操作,避免上下文切换的时间和性能消耗;加上对内存中数据的处理速度,很自然的提高redis的吞吐量。

Redis全程使用hash结构,读取速度快,还有一些特殊的数据结构,对数据存储进行了优化,如压缩表,对短数据进行压缩存储,再如,跳表,使用有序的数据结构加快读取的速度。


今天的分享就到这里了,码字画图不易,期待你的点赞、关注、转发谢谢

欢迎关注 github

微信添加: zookeeper0