Redis--为什么这么快？

Redis作为一个基于key-value的NoSQL数据库，最显著的特点存取速度非常快，官方说可以达到10W OPS，但是Redis为何这么快？

1、开发语言

Redis使用C语言进行编写的，而Unix系统也是C语言实现，所以C语言是非常贴近操作系统的语言

2、基于内存读写

基于内存读写是Redis速度快的主要原因，不进行数据同步的情况下，不从磁盘读取数据，没有IO。内存响应时间大约100ns

3、单线程

　　1).单线程避免了线程上下文切换以及同步加锁、解锁带来的消耗。

　　2).单线程简化算法的实现

　　3).单线程也带来一个问题，阻塞，对于一个长命令来说，会阻塞很多命令的执行响应

这里的单线程，不包含fork()产生的子进程。除了Redis之外，Node.js、Nginx都是单线程，都属于高性能的组件框架

4、多路I/O复用模型

　　由于Redis是单线程的，所有的操作都是串行执行，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，

这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的。

Redis的I/O模型基于epoll实现，也提供select和kqueue的实现，默认epoll

epoll相对于其他多路复用技术，具有的优点：

　　1. epoll没有最大并发连接的限制，上限是最大可以打开文件的数目，这个数字一般远大于 2048

　　2. 效率提升，epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中， epoll的效率就会远远高于select和poll

　　3. 内存拷贝，epoll在这点上使用了“共享内存 ”，这个内存拷贝也省略了。

epoll与select/poll的区别：select，poll，epoll都是IO多路复用的机制。

I/O多路复用：

　　通过一种机制，可以监视多个描述符（File Descriptor，简称fd），一旦某个描述符就绪，能够通知程序进行相应的操作。

select：

　　本质是采用32个整数的32位，即32*32= 1024来标识，fd值为1-1024。当fd的值超过1024限制时，就必须修改FD_SETSIZE的大小。这个时候就可以标识32*max值范围的fd。

poll：

　　poll与select不同，通过一个pollfd数组向内核传递需要关注的事件，故没有描述符个数的限制，pollfd中的events字段和revents分别用于标示关注的事件和发生的事件，

故pollfd数组只需要被初始化一次。

　　epoll还是poll的一种优化，返回后不需要对所有的fd进行遍历，在内核中维持了fd的列表。select和poll是将这个内核列表维持在用户态，然后传递到内核中。

与poll/select不同，epoll不再是一个单独的系统调用，而是由epoll_create/epoll_ctl/epoll_wait三个系统调用组成，后面将会看到这样做的好处。epoll在2.6以后的内核才支持。

select/poll的几大缺点：

　　1、每次调用select/poll，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大

　　2、同时每次调用select/poll都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大

　　3、针对select支持的文件描述符数量太小了，默认是1024

　　4.select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；

　　5.select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。

相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。

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

　　由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。

　　epoll没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右

　　设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？

　　在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，

轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。

　　如果没有I/O事件产生，我们的程序就会阻塞在select处。但是依然有个问题，我们从select那里仅仅知道了，有I/O事件发生了，但却并不知道是那几个流（可能有一个，多个，甚至全部），

　　我们只能无差别轮询所有流，找出能读出数据，或者写入数据的流，对他们进行操作。

　　但是使用select，我们有O(n)的无差别轮询复杂度，同时处理的流越多，每一次无差别轮询时间就越长

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

　　1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)

　　2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字

　　3）调用epoll_wait收集发生的事件的连接

　　如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，

因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

epoll内容原文地址：https://blog.csdn.net/wxy941011/article/details/80274233

原文：https://www.cnblogs.com/huigelaile/p/10900652.html