从redis为什么单线程还那么快到epoll的设计原理

redis为什么快

Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。主要设计如下：（单线程和NIO会做详细的讲述）

• 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速
• 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的
• 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作。
• 使用多路I/O复用模型，非阻塞IO。
  

上下文切换

为了控制进程的执行，内核必须有能力挂起正在CPU上运行的进程，并恢复以前挂起的某个进程的执行。这种行为被称为进程切换（也叫调度）。因此可以说，任何进程都是在操作系统内核的支持下运行的，是与内核紧密相关的。
1.保存当前进程A的上下文 (就是内核再次唤醒当前进程时所需要的状态)
2. 切换页全局目录以安装一个新的地址空间 …
3. 恢复进程B的上下文
可以理解成一个比较耗资源的过程

为什么采用单线程

首先问这个问题，说明我们对多线程还是有一定了解的，第一映像就是多线程要快些，仔细一想是哪方面快了勒 ？很多人都能想到是计算能力，没错，我们对cpu的利用率提高了。那么我们设想下独立模式下单台redis的性能瓶颈是什么了？我们知道Redis是基于内存的操作，CPU不是Redis的瓶颈，其实Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。（毕竟采用多线程会有很多麻烦！）

redis的I/O多路复用

我们知道传统的BIO（Blocking）操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务。而 I/O 多路复用就是为了解决这个问题而出现的。
这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），Reactor的设计模式就是基于NIO。
I/O多路复用实际上就是用select, poll, epoll技术等监听多个io对象，当io对象有变化（有数据）的时候就通知用户进程。好处就是单个进程可以处理多个socket。

epoll与select/poll区别

sselect的本质是采用32个整数的32位，即3232= 1024来标识，fd值为1-1024。当fd的值超过1024限制时，就必须修改FD_SETSIZE的大小。这个时候就可以标识32max值范围的fd。
poll与select不同，通过一个pollfd数组向内核传递需要关注的事件，故没有描述符个数的限制，pollfd中的events字段和revents分别用于标示关注的事件和发生的事件，故pollfd数组只需要被初始化一次。
epoll 没有最大并发连接的限制；另外是效率提升， Epoll 最大的优点就在于它只管你“活跃”的连接 ，而跟连接总数无关；然后是内存拷贝， epoll在这点上使用了“共享内存 ”，这个内存拷贝也省略了。

select/poll的几大缺点

1、每次调用select/poll，都需要把fd集合用户态拷贝到内核态，这个开销在fd很多时会很大
2、同时每次调用select/poll都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大
3、针对select支持的文件描述符数量太小了，默认是1024
4.select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
5.select的触发方式是水平触发。（个人理解：如交易系统每笔交易会触发一次，一次就是把所有fd集合从用户态拷贝到内核态，所有表示select触发频率也很高）

用户态拷贝到内核态

操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核（kernel），保证内核的安全，操心系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。针对linux 32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）,将最高的1G字节，供内核使用，称为内核空间，而将较低的3G字节，供各个进程使用，称为用户空间。

epoll IO多路复用模型实现机制

epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：

1. 调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2. 调用epoll_ctl向epoll对象中添加这100万个连接的socket
3. 调用epoll_wait收集发生的事件的连接（添加到一个双向链表里）
   如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

epoll 优势详解

1. 不用重复传递。我们调用epoll_wait时就相当于以往调用select/poll，但是这时却不用传递socket句柄给内核，因为内核已经在epoll_ctl中拿到了要监控的句柄列表。
2. 在内核里，一切皆文件。所以，epoll向内核注册了一个文件系统，用于存储上述的被监控socket。当你调用epoll_create时，就会在这个虚拟的epoll文件系统里创建一个file结点。当然这个file不是普通文件，它只服务于epoll。
   epoll在被内核初始化时（操作系统启动），同时会开辟出epoll自己的内核高速cache区，用于安置每一个我们想监控的socket，这些socket会以红黑树的形式保存在内核cache里，以支持快速的查找、插入、删除。这个内核高速cache区，就是建立连续的物理内存页，然后在之上建立slab层，简单的说，就是物理上分配好你想要的size的内存对象，每次使用时都是使用空闲的已分配好的对象。
   3.这是由于我们在调用epoll_create时，内核除了帮我们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket外，还会再建立一个list链表，用于存储准备就绪的事件，当epoll_wait调用时，仅仅观察这个list链表里有没有数据即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。所以，epoll_wait非常高效。

底层实现

当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：

每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。
而所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。
在epoll中，对于每一个事件，都会建立一个epitem结构体

当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。
如此，一颗红黑树，一张准备就绪句柄链表，少量的内核cache，就帮我们解决了大并发下的socket处理问题。执行epoll_create时，创建了红黑树和就绪链表，执行epoll_ctl时，如果增加socket句柄，则检查在红黑树中是否存在，存在立即返回，不存在则添加到树干上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据。执行epoll_wait时立刻返回准备就绪链表里的数据即可。

总结

理解底层设计更有利用我们的工具的使用和维护，同时也能提升自身的系统设计水平。就像那么多牛逼的工程是基于nio设计实现的，要学习还有很多。

参考以下内容：
https://blog.csdn.net/wxy941011/article/details/80274233
https://www.cnblogs.com/zingp/p/6863170.html
https://blog.csdn.net/chenyao1994/article/details/79491337
https://blog.csdn.net/skiof007/article/details/52873421