Redis的IO模式详解

Redis的I/O多路复用

Redis利用epoll来实现IO多路复用,将连接信息和事件放到队列中,一次放到文件事件分派器,事件分派器将事件分发给事件处理器.

• Redis是跑在单线程中的,所有的操作都是按照顺序线性执行的,但是由于读写操作等待用户输入或输出都是阻塞的,所以I/O操作在一般情况下往往不能直接返回,这会导致某一文件的I/O阻塞导致整个进程无法对其它客户提供服务,而I/O多路复用就是为了解决这个问题而出现.
• 所谓的I/O多路复用机制,就是说通过一种机制,可以监视多个描述符,一旦某个描述符就绪(一般是读就绪和写就绪),能够通知程序进行相应的读写操作.这种机制需要select,poll,epoll来配合.多个连接共用一个阻塞对象,应用程序只需要在一个阻塞对象上等待,无须阻塞等待所有的连接.当有某条连接有新的数据可以处理时,操作系统通知应用程序,线程从阻塞状态返回,开始进行业务处理.
• Redis采用Reactor的方式来实现文件事件处理器(每一个网络连接都对应一个文件描述符)
• Redis基于Reactor模式开发了网络事件处理器,这个处理器被称为文件事件处理器,他的组成分为4部分:
• 多个套接字
• IO多路复用程序
• 文件事件分派器
• 事件处理器

因为文件事件分派器队列的消费是单线程的,所以才说Redis是单线程的设计模型

概念介绍

同步

调用者要一直等待调用结果的通知后才能进行后续操作的执行

异步

指被调用方先返回应答让调用者先结束,然后在计算调用结果,计算完成后在通知并返回给调用方,异步调用要想获得结果一般通过回调通知

阻塞

调用方一直等待而且别的事情都不做,当前的进程/线程会被挂起

非阻塞

调用在发出去之后,调用方继续去忙别的事情,不会阻塞住当前的线程,而会立即返回结果

总结

分为四种情况:同步阻塞,同步非阻塞,异步阻塞,异步非阻塞

阻塞IO和非阻塞IO

BIO(阻塞IO)

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据（对于网络IO来说，很多时候数据在一开始还没有到达。比如，还没有收到一个完整的UDP包。这个时候kernel就要等待足够的数据到来）。这个过程需要等待，也就是说数据被拷贝到操作系统内核的缓冲区中是需要一个过程的。而在用户进程这边，整个进程会被阻塞（当然，是进程自己选择的阻塞）。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。所以BIO的特点就是在IO执行的两个阶段都被block了

就是在客户端连接时会阻塞,在客户端发送数据来接收的时候也会阻塞(怎么这个IO模型很不好,现在主流的设计也不再使用它了).tomcat7以前是通过BIO+多线程来解决这个堵塞问题的,效率比较低

NIO(非阻塞IO)

在NIO模式中，一切都是非阻塞的:
accept()方法是非阻塞的，如果没有客户端连接，就返回error
read()方法是非阻塞的，如果read()方法读取不到数据就返回error，如果读取到数据时只阻塞read()方法读数据的时间
在NIO模式中，只有一个线程:
当一个客户端与服务端进行连接，这个socket就会加入到一个数组中，隔一段时间遍历一次,看这个socket的read()方法能否读到数据，这样一个线程就能处理多个客户端的连接和读取了

当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。所以，NIO特点是用户进程需要轮询内核数据准备好了吗
在非阻塞IO模型中,应用程序把一个套接字设置为非阻塞,就是告诉内核,当所请求的I/O操作无法完成时,不要将线程睡眠而是返回一个"错误",应用程序基于I/O操作函数不断的轮询数据是否已经准备好,如果没有准备好,继续轮询直到好为止

NIO的优缺点

NIO成功的解决了BIO需要开启多线程的问题，NIO中一个线程就能解决多个socket，但是还存在2个问题。
问题一:
这个模型在客户端少的时候十分好用，但是客户端如果很多，比如有1万个客户端进行连接，那么每次循环就要遍历1万个socket，如果一万个socket中只有10个socket有数据，也会遍历一万个socket，就会做很多无用功，每次遍历遇到read 返回-1时仍然是一次浪费资源的系统调用。
问题二:
而且这个遍历过程是在用户态进行的，用户态判断socket是否有数据还是调用内核的read()方法实现的，这就涉及到用户态和内核态的切换，每遍历一个就要切换一次，开销很大因为这些问题的存在。
优点：不会阻塞在内核的等待数据过程，每次发起的I/O请求可以立即返回，不用阻塞等待，实时性较好。
缺点：轮询将会不断地询问内核，这将占用大量的CPU时间，系统资源利用率较低，所以一般Web服务器不使用这种I/O模型。
结论:让Linux内核搞定上述需求，我们将一批文件描述符通过一次系统调用传给内核由内核层去遍历，才能真正解决这个问题。所以IO多路复用应运而生，也即将上述工作直接放进Linux内核，不再两态转换而是直接从内核获得结果，因为内核是非阻塞的。

I/O多路复用

I/O multiplexing就是我们说的select，poll，epoll，有些地方也称这种IO方式为event driven IO(事件驱动IO)。就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程，每次new一个线程)，这样可以大大节省系统资源。所以，IO多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select()函数就可以返回

五种I/O模型总结

多路复用快的原因在于,操作系统提供了这样的系统调用,使得NIO模型下的轮询系统调用(用户态)变成了一次系统调用+内核态遍历这些文件描述符(所以说Linux可以说是YYDS),这时候多个连接只需要在这一个阻塞对象上进行等待,当某条连接能够有数据进行处理的时候,操作系统会反过来通知到应用程序继续后续的业务处理

文件描述符概念

文件描述符是计算机科学中的一个术语,是一个用于表达指向文件的引用的抽象化概念.文件描述符在形式上是一个非负整数.实际上,他是一个索引值,指向内核为每一个进程所维护的该进程打开文件的记录表,当程序打开一个现有文件或者创建一个新文件时,内核向进程返回一个文件描述符,在程序设计中,一些涉及底层的程序编写往往会围绕着文件描述符展开,但是文件描述符这一概念往往只适用于Unix,Linux这样的操作系统(因为对于linux来说一切皆文件,每个socket连接也是一个文件,linux进程默认最大的打开文件数就是65536)

Reactor模式

Reactor模式是指通过一个或者多个输入同时传递给服务处理器的服务请求的事件驱动处理模式.服务端程序处理传入的多路请求,并将他们同步分派给请求对应的处理线程.Reactor模式也叫Dispatcher模式.即I/O多了复用统一监听事件,收到事件后分发(Dispatch给某进程),是编写高性能网络服务器的必备技术
有两个关键的组成:

• Reactor:Reactor在单独的一个线程中运行,负载监听和分发事件,分发给适当的处理程序来对IO事件做出反应.他就像是公司的电话接线员,接听来自客户的电话并将线路转移到适当的联系人
• Handlers:处理程序执行I/O事件要完成的实际事件,类似于客户想要与之交谈的公司中的实际的办理人.Reactor通过调度适当的处理程序来响应I/O事件,处理程序执行非阻塞操作.

select方法

执行流程

• select是一个阻塞函数,当没有数据时,会一直阻塞在select那一行
• 当有数据时会将rset中对应的那一位置置为1(bitmap数据结构)
• select函数返回,不在阻塞
• 遍历文件描述符数组,判断哪个fd被置位了
• 读取数据,然后进行相关的处理
  

缺点

• bitmap默认大小为1024,虽然可以调整但是还是有限度的
• rset每次循环都必须重新置位为0,不可重复使用
• 尽管将rset从用户态拷贝到内核态来由内核态判断是否有数据,但是拷贝还是会有一定的开销
• 当有数据时select就会返回,但是select函数还是不知道哪个文件描述符有数据了,后面还需要对数组进行遍历判断,效率比较低

poll方法

执行流程

• 将fd数组列表从用户态拷贝到内核态
• poll为阻塞方法,执行poll方法,如果有数据会将fd对应的revents置为POLLIN
• poll方法返回
• 循环遍历,查找哪个fd被置为POLLIN了
• 将revents重置为0,便于复用
• 对置位的fd进行读取和处理
  

解决的问题

• 解决了bitmap大小限制的问题
• 解决了rset不可重用的问题
• 后面两个问题由于设计原理相同,所以未能解决

epoll方法

epoll的三大函数

• epoll_create:创建一个epoll句柄
• 参数size只是个初始化的建议值,不是其上限
• epoll_ctl:向内核添加,修改,删除要监控的文件描述符
• epoll_wait:类似于发起了select调用
  

执行流程

• 当有数据的时候,会把相应的文件描述符"置位",但是epoll没有标志位来做这件事,所以并不是真正的置位.他这时候会把有数据的文件描述符放到队首
• epoll会返回有数据的文件描述符的个数
• 根据返回的个数,读取前N个文件描述符即可
• 读取数据,处理

三个方法对比

	select	poll	epoll
操作方式	遍历	遍历	回调
数据结构	bitmap	数组	红黑树
最大连接数	1024或者2048	无上限	无上限
最大支持文件描述符数	一般有最大值限制	65535	65535
fd拷贝	每次调用select,都需要把fd集合从用户态拷贝到内核态	每次调用poll,都需要把fd集合从用户态拷贝到内核态	fd首次调用epoll_ctl拷贝,每次调用epoll_wait不拷贝
工作效率	每次调用需要遍历,时间复杂度O(N)	每次调用需要遍历,时间复杂度O(N)	事件通知方式,系统注册的回调函数就会被调用,将就绪的fd放到readylist里面,时间复杂度为O(1)

为什么三个函数都要保有

因为操作系统的平台差异,epoll函数只有linux系统才有,select是给windows系统作为保底手段的

Redis单线程为什么那么快

多路复用快的原因在于，操作系统提供了这样的系统调用，使得原来的while 循环里多次系统调用，
变成了一次系统调用+内核层遍历这些文件描述符。
epoll是现在最先进的10多路复用器，Redis、Nginx，linux中的Java NIO都使用的是epoll。
这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。
1、一个socket的生命周期中只有一次从用户态拷贝到内核态的过程，开销小
2、使用event事件通知机制，每次socket中有数据会主动通知内核，并加入到就绪链表中，不需要遍历所有的socket
在多路复用IO模型中，会有一个内核线程不断地去轮询多个 socket的状态，只有当真正读写事件发送时，才真正调用实际的IO读写操作。因为在多路复用IO模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有真正有读写事件进行时，才会使用1O资源，所以它大大减少来资源占用。多路l/O复用模型是利用 select、poll、epoll 可以同时监察多个流的/O事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有VO事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。采用多路I/O复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗），且Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈