Redis02-Redis高性能与epoll

redis为何如此之快

• Redis基本是内存操作，所以速度很快

内存：  
1. 寻址时间：纳秒级别ns  
2. 带宽：很大  
磁盘：  
1. 寻址时间：毫秒级别ms  
2. 带宽：G/M  
磁盘比内存寻址慢了10W倍以上，所以单机Redis能支持每秒10W以上的请求

• Redis通信采用非阻塞IO， 内部实现采用epolll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时
• 单机Redis采用单进程、单线程、单实例，避免了不必要的上下文切换和竞争条件

可能很多人认为要想系统处理速度快不是应该使用多线程技术。但其实Redis的数据都是放在内存中，查询存储都延时都非常小，是纳秒级别的，所以如果使用多线程，就需要加锁，系统资源还需要耗费在线程之间上下文切换上面，反而会影响性能。单进程、单线程天生就保证了请求的顺序执行，不需要加锁，也没有了不必要的上下文切换，因此可以将硬件的性能发挥到极致

这3个条件不是相互独立的，特别是第一条，如果请求都是耗时的，采用单线程吞吐量及性能可想而知了。应该说Redis为特殊的场景选择了合适的技术方案。

Epoll的高性能如何成就Redis

I/O模型 BIO、NIO、多路复用I/O、AIO

1. 阻塞I/O（Blocking I/O BIO）

应用程序进程/线程如果发起1K个请求，则开启1K个socket文件描述符，socket在等待内核返回数据时是阻塞式的，数据未准备好就一直阻塞等待，一次只会返回一个socket结果，直到返回数据后才等待下一个socket的返回

2. 轮询非阻塞I/O（Non-Blocking I/O NIO）

应用进程如果发起1K个请求，则在用户空间不停轮询这1K个socket文件描述符，查看是否有结果返回。这种方法虽然不阻塞，但是效率太低，有大量无效的循环

3. 多路复用I/O（Multiplexing I/O）

select： 能打开的文件描述符个数有限（最多1024个），如果有1K个请求，用户进程每次都要把1K个文件描述符发送给内核，内核在内部轮询后将可读描述符返回，用户进程再依次读取。因为文件描述符（fd）相关数据需要在用户态和内核态之间拷来拷去，所以性能还是比较低

poll：可打开的文件描述符数量提高，但性能仍然不够

epoll（linux下多为该技术）：用户态和内核态之间不用文件描述符（fd）的拷贝，而是通过mmap技术开辟共享空间，所有fd用红黑树存储，有返回结果的fd放在链表中，用户进程通过链表读取返回结果，伪异步I/O，性能较高。epoll分为水平触发和边缘出发两种模式，ET是边缘触发，LT是水平触发，一个表示只有在变化的边际触发，一个表示在某个阶段都会触发

4. 异步I/O AIO

AIO：异步I/O，性能最高，但是使用非常复杂，不是很常用（windows系统中多见）