一文带你快速了解Redis中的线程IO模型-Redis-PHP中文网

Redis是单线程的，但为什么那么快尼？原因之一就是redis使用非阻塞IO与多路复用处理大量的客户端连接。下面本篇文章就来带大家了解一下Redis中的线程IO模型，希望对大家有所帮助！

一文带你快速了解Redis中的线程IO模型

Redis是一个单线程的应用程序，NodeJs、Nginx都是单线程，它们都属于服务器高性能的典范。【相关推荐：Redis视频教程】

Redis之所以是单线程还能这么快的原因：

其一是因为它所有的数据都在内存当中，所有的运算都是内存级别的运算，所以使用redis时，要注意时间复杂度为O(n)的指令，因为是单线程的，如果数据量太大，会让其他指令被阻塞等待；

其二是因为redis使用非阻塞IO与多路复用处理大量的客户端连接。

非阻塞IO

当我们使用套接字的读写方法时，默认是阻塞的，

即调用read方法传递一个参数n，表示最多读取n个字节后返回，如果一个字节都没有，线程就会在read方法这里持续等待，直到有数据过来或者连接被关闭，read方法此时返回，线程才能执行下面的逻辑，

write方法一般不会阻塞，除非内核为套接字分配的写缓冲区满了，write方法才会阻塞，一直到缓存区中有空间闲出来。

下图是套接字读写的细节流程。

非阻塞IO在使用套接字时提供了一个选项Non_Blocking，当这个选项打开时，读写方法不会阻塞，而是能读多少读多少，能写多少写多少，

能读多少取决与内核为套接字分配的读缓冲区的数据字节数，能写多少取决于内核为套接字写缓冲区分配的数据字节数，

读写方法都会通过返回值告诉程序读写了多少字节数。

非阻塞IO意味着读写时，线程不必再被阻塞着，读写可以瞬间完成，线程可以继续往下做别的事情。

多路复用(事件轮询)

非阻塞IO虽然很快，但是也带来一个问题，线程读数据，读了一部分就返回了，没有读完，剩下的数据何时继续读？，写数据，缓冲区满了，没有写完，剩下的数据何时继续写？

当可以继续读或者可以继续写时，应该给应用程序一个通知，告诉应用程序可以继续读或者继续写，事件轮询API就是用来处理这个问题的。

select

操作系统提供了一个select函数给用户程序，输入是读写描述符列表 read_fds & write_fds，输出是与之对应的可读可写事件，

同时还提供了timeout参数，线程最多等待timeout的时间，在这期间有事件过来，方法立刻返回，线程往下处理，如果超过timeout时间，方法也会返回，

如果拿到事件了，线程即可挨个处理相应的事件，处理完了以后继续调用 select api 轮询，所以该线程其实是一个死循环，不停的 select，不停的处理，来回这样，这个死循环被称之为事件循环，一个循环即一个周期。

事件循环伪代码:

while True
    read_events, write_events = select(read_fds, write_fds, timeout)
    for event in read_events:
        handle_read(event.fd)
    for event in write_events:
        handle_write(event.fd)
    handle_others() # 做其他的逻辑处理，处理定时任务等等

登录后复制

通过select函数我们可以处理多个通道描述符的读写事件，所以将select这类的系统函数调用称之为多路复用API，

现代操作系统的多路复用API已经不使用select系统调用，改用epoll(linux)和kqueue(FreeBSD、macosx)，

select的性能在描述符变多时会变得很差，epoll与select使用起来略有差异，不过都可以用上面的伪代码理解，都是当描述符发生事件时，循环对描述符的事件做出处理，

serversocket对象的读操作是指调用accept接受客户端新连接，何时有连接来临，也是通过select调用的读事件通知的。

Java中的NIO技术就是事件轮询，其他语言也有这个技术。