Redis02-Redis高性能与epoll _Redis

redis为何如此之快

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

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

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

【Redis02-Redis高性能与epoll】可能很多人认为要想系统处理速度快不是应该使用多线程技术。但其实Redis的数据都是放在内存中，查询存储都延时都非常小，是纳秒级别的，所以如果使用多线程，就需要加锁，系统资源还需要耗费在线程之间上下文切换上面，反而会影响性能。单进程、单线程天生就保证了请求的顺序执行，不需要加锁，也没有了不必要的上下文切换，因此可以将硬件的性能发挥到极致
这3个条件不是相互独立的，特别是第一条，如果请求都是耗时的，采用单线程吞吐量及性能可想而知了。应该说Redis为特殊的场景选择了合适的技术方案。

文章插图

Epoll的高性能如何成就RedisI/O模型 BIO、NIO、多路复用I/O、AIO1. 阻塞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是水平触发，一个表示只有在变化的边际触发，一个表示在某个阶段都会触发