Redis的单线程为什么快？（网络IO模型）

写这篇Redis单线程为什么快,Redis6.x已经发布快一年了，但是绝大公司还是在使用Redis5.x版本，因为Redis5.x已经足够给中小型企业提供支持了，甚至有些大型公司还在使用单线程Redis。

Redis真的是单线程的吗？

首先，在此说明，Redis6.0以前真的是单线程吗？这里分为两个方面：

• Redis的单线程指的是再网络IO连接到读写的处理是一个线程进行工作的；
• 而Redis的持久化、异步删除、集群都是多线程的。

反正问题一个接一个

Redis为什么是单线程？

Redis作者曾经说过，不想让Redis变得更加复杂，也就是说采用多线程必须要有良好的设计，就算是多线程访问，还要维护共享资源的问题，已经加锁，随着线程变多，锁也就成为了瓶颈，因为要等待锁释放，到最后也就会成为串行化。

Redis单线程为什么也会如此之快？

Redis快可以从三个方面切入：

• Redis操作都是再内存中完成；
• Redis的快也可以却决于它的数据结构；
• 非常重点的是Redis的IO模型，多路复用机制。

需要说明的是等待就绪的阻塞是不使用CPU的，是在“空等”；而真正的读写操作的阻塞是使用CPU的，真正在”干活”，而且这个过程非常快，属于memory copy，带宽通常在1GB/s级别以上，可以理解为基本不耗时。

阻塞I/O

这些方面都是以socket来说，一个socket只有保证了四元组唯一就可以建立一个连接，每个连接就会对应一个fd，建立后内核就会维护一个buffer，这个buffer大小应该是MTU的大小，发送的数据都会在这个buffer里。

阻塞就代表了应用程序向服务端读取数据时，内核的这个buffer是空的，就会一直等着内核把数据准备好，有数据了就从内核copy到用户空间。整个过程是同步阻塞的。

阻塞点发生再accept() 和 recv()这两个系统调用。从Redis角度来说，当 Redis 监听到一个客户端有连接请求，但一直未能成功建立起连接时，会阻塞在 accept() 函数这里，导致其他客户端无法和 Redis 建立连接。同样的，当 Redis 通过 recv() 从一个客户端读取数据时，如果数据一直没有到达，Redis 也会一直阻塞在 recv()。

非阻塞I/O

socket中也可以设置非阻塞模式，也就是说accept()指向后有连接建立就放回一个fd，若是没有返回-1，同理recv也是的。
这样的如果是Redis再非阻塞的情况下，就可以有空闲时间去处理别的事情，同时还是会一直监听连接的到达的。

这样才能保证 Redis 线程，既不会像基本 IO 模型中一直在阻塞点等待，也不会导致 Redis 无法处理实际到达的连接请求或数据。

多路复用

最后就是多路复用了，多路复用器一次性可以处理多个fd。以Redis的epoll为例，当有建立好连接后有fd4时,epoll会调用epoll_create函数创建红黑树返回epfd5(fd自增的)，再调用epoll_ctl(“epfd5”,操作符比如add添加，新的fd3)，就会把fd3放到了红黑树中，再触发一个中断，中断就会延申，把有状态的fd放到一个链表中（这样就避免了select/poll的遍历了），再调用epoll_wait告诉Redis可读可写的fd，Redis再recv()。（只要是程序直接读写，它就是同步模型）

即便程序不调用内核，内核也会随着中断的发生完成有fd的状态设置，Redis只需要调用wait取走有状态的fd的结果集进行对应的操作。

这样Redis 无需一直轮询是否有请求实际发生，这就可以避免造成 CPU 资源浪费。