Redis快的秘密，高性能设计epoll和IO多路复用探究
Redis快的原因，高性能设计epoll和IO多路复用探究
1、多路复用需要解决的问题
并发多客户端连接，在多路复用之前最简单和典型的方案：同步阻塞网络IO模型
这种模式的特点就是用一个进程来处理一个网络连接（即一个用户请求）
比如下面一段代码：
直接调用recv函数从一个socket上读取数据
int main()
{
...
recv(sock,...)//从用户角度看非常简单，一个recv，要接收的数据就到手了
}
这种方式的优缺点
- 优点：这种方式很直接，很容易理解，写起代码很自然，符合人的直线型思维；
- 缺点也很明显：就是新能差，每个用户的请求都得占一个进程来处理，来一个就请求分配一个进程处理，这样就很慢了，进程很笨重的，一台服务器创建不了太多的进程，这种方式很吃性能。
进程在Linu 上是一个开销不小的东西，先不说创建了，光是上下文切换一次就得几个微秒。所以为了高效地对海量用户提供服务，必须得让一个进程同时能处理多个TCP连接请求才可以。
**IO多路复用所要解决的痛点：**如果一个进程保持了一万条连接，那么怎么知道哪条连接上有数据可读了?哪条连接上可写数据了？
我们当然可以采用循环遍历的方式来发现IO事件（挨个问），但这种方式太低级了。我们希望有一种更高效的机制，在很多连接中的某条上有IO事件发生的时候直接快速把它找出来（让它主动报告）
其实这个事情Linux操作系统已经替我们都做好了，它就是我们所熟知的IO多路复用机制。这里的复用指的就是对进程的复用
2、IO多路复用模型
2.1、是什么
- IO：网络I/O
- 多路：多个客户端连接（连接就是套接字描述符，即socket或者channle），指的是多个TCP连接；
- 复用：用一个进程来处理多条的连接，使用单进程就能实现同时处理多个客户端的连接；
- 一句话：
- 实现了用一个进程来处理大量的客户连接；
- IO多路复用类似一个规范和接口，落地实现；
- 可以分为select->poll->epoll三个阶段来描述
2.2、Redis单线程如何处理那么多并发客户端连接，为什么单线程，为什么快？
Redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，一次放到文件事件分派器，事件分派器将事件分发给事件处理器。
Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以I/O操作在一般情况下往往不能直接返回，这会导致某一文件的I/O阻塞导致整个进程无法对其它客户提供服务，而I/O多路复用就是为了解决这个问题而出现。
所谓1/O多路复用机制，就是说通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或写就绪），能够通知程序进行相应的读写操作。这种机制的使用需要 select、poll 、 epoll来配合。多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。
Redis服务采用Reactor的方式来实现文件事件处理器（每一个网络连接其实都对应一个文件描述符)Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。
它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。
因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。
2.3、Unix网络编程中的五种IO模型
- Blocking IO 阻塞IO；
- NoneBlocking IO 非阻塞IO；
- IO nultiplexing-IO多路复用；
- aignal driven IO 信号驱动IO
- asynchronous IO 异步IO
2.4、同步与异步的理解AND阻塞和非阻塞
-
同步：调用者要一直等待调用结果的通知后才能进行后续的执行，现在就要，我可以等，等出结果为止
-
异步：指被调用方先返回应答让调用者先回去，然后再计算调用结果，计算完最终结果后再通知并返回给调用方异步调用要想获得结果一般通过回调。
-
同步、异步的讨论对象是被调用者(服务提供者)，重点在于获得调用结果的消息通知方式上
-
阻塞：调用方一直在等待而且别的事情什么都不做，当前进/线程会被挂起，啥都不干；
-
非阻塞：调用在发出去后，调用方先去忙别的事情，不会阻塞当前进/线程，而会立即返回；
-
阻塞和非阻塞的理解：阻塞、非阻塞的讨论对象是调用者(服务请求者)，重点在于等消息时候的行为，调用者是否能干其它事
小结：
两两组合，举例子
- 同步阻塞：服务员说快到你了，先别离开我后台看一眼马上通知你。客户在前台干等着，啥都不干。
- 同步非阻塞：服务员说快到你了，先别离开。客户在前台边刷抖音边等着叫号。
- 异步阻塞:服务员说还要再等等，你先去逛逛，一会儿通知你。客户怕过号在前台拿着排号小票啥都不干，一直等着店员通知。
- 异步非阻塞:服务员说还要再等等，你先去逛逛，一会儿通知你。拿着排号小票+刷着抖音，等着店员通知；
3、阻塞IO–>BIO(Blocking IO )解析
当用户进程调用了recvfrom这个系统调用，kernel(内核)就开始了IO的第一个阶段:准备数据（对于网络IO来说，很多时候数据在一开始还没有到达。比如，还没有收到一个完整的UDP包。这个时候kernel就要等待足够的数据到来）。这个过程需要等待，也就是说数据被拷贝到操作系统内核的缓冲区中是需要一个过程的。而在用户进程这边，整个进程会被阻塞（当然，是进程自己选择的阻塞）。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。所以，BIO的特点就是在IO执行的两个阶段都被block 了.
这里要说一个函数，在C语言中的recvform()函数，它用于从已连接套接口(socket)上接收数据，并捕获数据发送源的地址,简单说：接收一个数据并保存它的源地址。
3.1、先演示accept
accept监听，第一步会先卡在这里阻塞
使用Java程序模拟一个服务端和两个客户端
RedisServer.java
public class RedisServer {
public static void main(String[] args) throws IOException {
ServerSocket serverSocket = new ServerSocket(6379);
while (true){
System.out.println("模拟RedisServer启动-----等待连接。。。。。");
Socket socket = serverSocket.accept();
System.out.println("-----连接成功-----"+ UUID.randomUUID()+"\n");
}
}
}
RedisClient1.java
public class RedisClient1 {
public static void main(String[] args) throws IOException {
System.out.println("----redisClint1连接启动");
Socket socket = new Socket("127.0.0.1", 6379);
System.out.println("----redisClint1连接结束");
}
}
RedisClient2.java
public class RedisClient2 {
public static void main(String[] args) throws IOException {
System.out.println("----redisClint2连接启动");
Socket socket = new Socket("127.0.0.1", 6379);
System.out.println("----redisClint2连接结束");
}
}
先启动RedisServer再启动模拟客户端程序
然后启动redisClient1
查看服务程序输出信息
可以看到接到一个请求然后返回一个uuid后又继续监听，此时启动第二个模拟客户端程序
查看服务程序输出
一个accept监听示例结束
3.2、演示read
服务端模拟程序一直监听，客户端连接到服务端，在客户端输入什么内容客户端就将其打印出来直到客户端输入quit跳出程序。
3.2.1、第一种情况
RedisServerBIO.java
public class RedisServerBIO {
public static void main(String[] args) throws IOException {
ServerSocket serverSocket = new ServerSocket(6379);
while (true){
System.out.println("等待连接-----");
Socket socket = serverSocket.accept();//阻塞1，等待客户端连接
System.out.println("连接成功-----");
InputStream inputStream = socket.getInputStream();
int length = -1;
byte[] bytes = new byte[1024];
System.out.println("等待读取----");
//阻塞2，等待客户端发送数据
while ((length = inputStream.read(bytes)) != -1){
System.out.println("====读取成功---->"+new String(bytes,0,length));
System.out.println("=========="+"\t"+ IdUtil.simpleUUID());
System.out.println();
}
inputStream.close();
socket.close();
}
}
}
RedisClient01.java
public class RedisClient01 {
public static void main(String[] args) throws IOException {
Socket socket = new Socket("127.0.0.1", 6379);//客户端连接套接字
OutputStream outputStream = socket.getOutputStream();//输出流写入数据用
while (true){
Scanner scanner = new Scanner(System.in);
String string = scanner.next();
//如果输入了quit，本次连接就break，中断
if (string.equalsIgnoreCase("quit")){
break;
}
socket.getOutputStream().write(string.getBytes());
System.out.println("----RedisClient01 输入quit键完成----");
}
outputStream.close();
socket.close();
}
}
RedisClient02.java
public class RedisClient02 {
public static void main(String[] args) throws IOException {
Socket socket = new Socket("127.0.0.1", 6379);//客户端连接套接字
OutputStream outputStream = socket.getOutputStream();//输出流写入数据用
while (true){
Scanner scanner = new Scanner(System.in);
String string = scanner.next();
//如果输入了quit，本次连接就break，中断
if (string.equalsIgnoreCase("quit")){
break;
}
socket.getOutputStream().write(string.getBytes());
System.out.println("----RedisClient02 输入quit键完成----");
}
outputStream.close();
socket.close();
}
}
我们先启动服务端模拟程序，此时没有人连接，处于accept监听状态，进行等待连接。
我们启动RedisClient01程序，输入一个信息。
到服务端看输出内容
然后在客户端RedisClient01再输入第二次
客户端查看
一切看上去很正常，这个时候启动第二个客户端，又来一个人排队买奶茶，在第二个客户端输入信息。
这个时候到服务端查看有没有消息输出呢？
答案是，没有，因为1号没走没退出，服务端此时的状态一直都是读取1号的消息状态，2号连连接都没有连上，这个时候分别在1号和2号再来一次。
到服务端查看，它还是只读了1号的，2号的没打印。
然后我们将1号程序退出
再去到服务端看看
我们发现，这个时候2号的连接才被响应，而2号写入的两次内容被合并成了一个，变成一次订单。
如果这个连接的客户端迟迟不发数据，进程就会一直堵塞在read()方法上，这样其他客户端也不能进行连接，也就是一次只能处理一个客户端，对客户很不友好。所以说，这种机制还是很低效的，第一个客户端必须退出才能处理第二个请求，效率很低。
3.2.2、第二种情况
多线程模式，一个不够多开几个。
利用多线程方法，只要连接了一个socket，操作系统分配一个线程来处理，这样read()方法就堵塞在每个具体的线程上而不堵塞主线程。就能操作多个socket了，哪个线程中的socket有数据，就读取哪个socket，各取所需，灵活统一。
程序服务端只负责监听是否有客户端连接，使用accept()阻塞
客户端1连接服务端，就开辟一个线程（thread1）来执行read()方法，程序服务端继续监听…
客户端2连接服务端，就开辟一个线程（thread2）来执行read()方法，程序服务端继续监听…
客户端3连接服务端，就开辟一个线程（thread3）来执行read()方法，程序服务端继续监听…
任何一个线程上的socket有数据发送过来，read()就能马上读到，CPU就能进行处理。
RedisServerBIOMultiThread.java
public class RedisServerBIOMultiThread {
public static void main(String[] args) throws IOException {
ServerSocket serverSocket = new ServerSocket(6379);
while (true){
System.out.println("等待连接-----");
Socket socket = serverSocket.accept();//阻塞1，等待客户端连接
System.out.println("连接成功-----");
//这里new一个线程来处理连接，每来一个连接都是独立的，新new的
new Thread(() -> {
try{
InputStream inputStream = socket.getInputStream();
int length = -1;
byte[] bytes = new byte[1024];
System.out.println("等待读取流水号："+IdUtil.simpleUUID());
//阻塞2，等待客户端发送数据
while ((length = inputStream.read(bytes)) != -1){
System.out.println("====读取成功---->"+new String(bytes,0,length));
System.out.println("==========id->"+"\t"+ IdUtil.simpleUUID());
System.out.println();
}
inputStream.close();
socket.close();
}catch (IOException e){
e.printStackTrace();
}
},Thread.currentThread().getName()).start();
}
}
}
RedisClient01和RedisClient02内容和上面第一种情况演示的一样，不再赘述。
现在启动服务端，还没有客户端连接。
现在启动客户端01
查看客户端输出
在客户端输入内容，到服务端查看
很正常，再输入几个
客户端
此时启动客户端2号查看服务端，直接就能连接上，新创建了一个线程来为2号客户端服务
客户端2号写入数据，1号和2号都写入查看服务端
可以看到1号和2号客户端的业务就互不影响了。
这种方式看上去很好，但是，这种方式数据量小的时候用用就算了，大量数据是不能这样的。
所以，对于多线程的模型，每来一个客户端，就要开辟一个线程，如果来1万个客户端，那就要开辟1万个线程。在操作系统中用户态不能直接开辟线程，需要调用内核来创建的一个线程，这其中还涉及到用户状态的切换（上下文的切换），十分耗资源。
解决方法：
-
一：使用线程池
这个在客户端连接少的情况下使用，但是用户量大的情况下，我们不知道线程池需要多大，太大会内存不够；
-
二：NIO非阻塞IO方式
因为read()方法堵塞了，所以要开辟多个线程，有什么方法能使read()方法不阻塞，就不用开辟新线程了，需要使用非阻塞IO了；
tomcat7之前就是用BIO多线程来解决多连接的
3.2.3、小总结
在阻塞式I/O模型中，应用程序在从调用recvfrom开始到它返回有数据报准备好这段时间是阻塞的，recvfrom返回成功后，应用进程才能开始处理数据报。
每个线程分配一个连接，必然会产生多个，既然是多个socket链接必然需要放入进容器，纳入统一管理
4、非阻塞IO–>NIO(NoneBlocking IO )解析
当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个errori时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。
所以，NIO特点是用户进程需要不断的主动询问内核数据准备好了吗? 一句话，用轮询替代阻塞!（有点类似自旋）
在NIO模型中，一切都是非阻塞的：
accept()方法是非阻塞的，如果没有客户端连接，就返回无连接标识；
read()方法是非阻塞的，如果read()方法读取不到数据就返回空闲中标识，如果读取到数据时只阻塞read()方法读数据的时间；
在NIO模式中，只有一个线程：当一个客户端与服务端进行连接，这个socket就会加入到一个数组中，隔一段时间遍历一次，看这个socket的read()方法能否读到数据，这样一个线程就能处理多个客户端的连接和读取了；
4.1、示例
RedisServerNIO.java
public class RedisServerNIO {
//这个数组相对于一个容器，将连接对象放到这里，循环遍历实现轮询。
static ArrayList<SocketChannel> socketList = new ArrayList<>();
static ByteBuffer byteBuffer = ByteBuffer.allocate(1024);//申请了1024字节
public static void main(String[] args) throws IOException {
System.out.println("-----RedisServerNIO启动中-----");
ServerSocketChannel open = ServerSocketChannel.open();
open.bind(new InetSocketAddress("127.0.0.1",6379));
open.configureBlocking(false);//设置为非阻塞模式
while (true){
for (SocketChannel element : socketList){//循环遍历，谁有数据读取谁
int read = element.read(byteBuffer);
if (read > 0){
System.out.println("----读取数据---->"+read);//获取字节大小
byteBuffer.flip();
byte[] bytes = new byte[read];
byteBuffer.get(bytes);
System.out.println(new String(bytes));
byteBuffer.clear();
}
}
SocketChannel socketChannel = open.accept();
if (socketChannel != null){
System.out.println("----连接成功----");
socketChannel.configureBlocking(false);//设置为非阻塞模式
socketList.add(socketChannel);
System.out.println("----socketList size："+socketList.size());
}
}
}
}
解释：
-
创建服务器SocketChannel：ServerSocketChannel.open()创建一个新的ServerSocketChannel对象，然后通过bind()方法将其绑定到本地地址和端口（在这个例子中是127.0.0.1:6379）。然后，configureBlocking(false)将这个ServerSocketChannel设置为非阻塞模式。
-
处理连接：在无限循环中，服务器首先遍历所有已连接的SocketChannel（存储在socketList中）。对于每个SocketChannel，它尝试从该通道读取数据到byteBuffer中。如果读取到的数据长度大于0，那么它将打印出读取到的字节数，然后将缓冲区翻转（flip()），从缓冲区中获取数据并打印出来，最后清空缓冲区。
-
添加新的连接：在处理完所有已连接的SocketChannel后，服务器尝试接受新的连接。如果有新的连接，它将打印出连接成功的消息，将新的SocketChannel设置为非阻塞模式，然后将其添加到socketList中。
启动服务端模拟程序，并启动1号客户端
1号客户端写入数据
启动2号客户端
1号客户端和2号客户端互不影响
4.2、存在的问题
NIO成功的解决了BIO需要开启多线程的问题，NIO中一个线程就能解决多个socket，但是还存在2个问题。
- 问题一：如果有1万个连接其中只有10个连接中是有数据的，仍然还会遍历1万次，做了很多无用功，浪费系统资源。
- 问题二：而且这个遍历过程是在用户态进行的，用户态判断socket是否有数据还是调用内核的read()方法实现的，这就涉及到用户态和内核态的切换，每遍历一个就要切换一次，开销很大因为这些问题的存在。
优点：
- 不会阻塞在内核的等待数据过程，每次发起的I/O请求可以立即返回，不用阻塞等待，实时性较好。
缺点：
- 轮询将会不断地询问内核，这将占用大量的CPU时间，系统资源利用率较低，所以一般Web服务器不使用这种I/О模型。
结论：让Linux内核搞定上述需求，我们将一批文件描述符通过一次系统调用传给内核由内核层去遍历，才能真正解决这个问题。IO多路复用应运而生，也即将上述工作直接放进Linux内核，不再两态转换而是直接从内核获得结果，因为内核是非阻塞的。
5、IO Multiplexing(IO多路复用)
5.1、是什么
I/O多路复用在英文中叫I/O multiplexing
多个Sock复用一根网线这个功能是在内核＋驱动层实现的
I/o multiplexing 这里面的 multiplexing 指的其实是在单个线程通过记录跟踪每一个Sock(I/O流)的状态来同时管理多个I/O流.目的是尽量多的提高服务器的吞吐能力。
I0 multiplexing就是我们说的select.poll, epoll，有些技术书籍也称这种IO方式为event driven IO事件驱动IO。就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪〉，能够通知程序进行相应的读写操作。可以基于一个阻塞对象并同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程，每次new一个线程)，这样可以大大节省系统资源。所以，I/0多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态, select,poll， epoll等函数就可以返回。
简单来讲：
将用户socket对应的fd注册进epoll，然后epoll帮你监听哪些socket上有消息到达、这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。这样，整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor反应模式。
select 其实就是把NIO中用户态要遍历的fd数组(我们的每一个socket链接，安装进ArrayList里面的那个)拷贝到了内核态，让内核态来遍历，因为用户态判断socket是否有数据还是要调用内核态的，所有拷贝到内核态后，
这样遍历判断的时候就不用一直用户态和内核态频繁切换了。
举个例子，nginx使用epolI接收请求，ngnix会有很多链接进来, epoll会把他们都监视起来，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。redis类似同理
FileDescriptor
文件描述符（File descriptor)是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。
5.2、Reactor设计模式
基于I/0复用模型:
多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。
Reactor模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor模式也叫 Dispatcher模式。即I/O多了复用统一监听事件.收到事件后分发(Dispatch给某进程)，是编写高性能网络服务器的必备技术。
Reactor模式中有2个关键组成：
- Reactor: Reactor在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对IO事件做出反应。它就像公司的电话接线员它接听来自客户的电话并将线路转移到适当的联系人;
- Handlers:处理程序执行I/О事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际办理人。Reactor通过调度适当的处理程序来响应I/O事件I处理程序执行非阻塞操作。
每一个网络连接其实都对应一个文件描述符
Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。
它的组成结构为4部分:多个套接字、IO多路复用程序、文件事件分派器、事件处理器。
5.3、select方法简介
先看源码关于select的结构体定义
int select(
int nfds, //nfds:监控的文件描述符集里最大文件描述符加1
fd_set *readfds, //readfds:监控有读数据到达文件描述符集合，传入传出参数
fd_set *writefds,//writefds:监控有写数据到达文件描述符集合，传入传出参数
fd_set *exceptfds, //监控异常情况发生到达文件描述符集合，传入传出参数
struct timeval *timeout);//timout：定时阻塞监控时间，有3种情况：1、NULL，永远等下去2、设置timeval，等待固定时间，3、设置设置timeval为0，检查描述字后立即返回，也就是轮询
select函数监视的文件描述符分3类，分别是readfds、writefds和exceptfds，将用户传入的数组拷贝到内核空间
调用后select函数会阻塞，直到有描述符就绪（有数据可读、可写、或者有except)或超时（timeout指定等待时间，如果立即返回设为mull.可），函数返回。
当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。l
分析select函数的执行流程：
- select是—个阻塞函数，当没有数据时，会一直阻塞在select那一行；
- 当有数据时会将rset中对应的那─位置为1；
- selecti函数返回，不再阻塞；
- 遍历文件描述符数组，判断哪个fd被置位了5.读取数据，然后处理；
select函数的缺点：
- bitmap默认大小为1024，虽然可以调整但还是有限度的；
- rset每次循环都必须重新置位为0，不可重复使用；
- 尽管将rset从用户态拷贝到内核态由内核态判断是否有数据，但是还是有拷贝的开销；
- 当有数据时select就会返回，但是select函数并不知道哪个文件描述符有数据了，后面还需要再次对文件描述符数组进行遍历。效率比较低；
小结：
select方式，既做到了一个线程处理多个客户端连接（文件描述符）,又减少了系统调用的开销（多个文件描述符只有一次 select的系统调用＋N次就绪状态的文件描述符的read系统调用。
5.4、poll方法简介
还是先看代码
int poll(
struct pollfd *fds,
nfds_t nfds,
int timeout);
struct pollfd{
int fd; //文件描述符
short events;//关系的事件，读事件或者写事件
short revents;//如果该文件描述符有事件发生置1
}
poll的执行流程：
- 将五个fd从用户态拷贝到内核态；
- poll为阻塞方法，执行poll方法，如果有数据会将fd对应的revents置为POLLIN；
- poll方法返回；
- 循环遍历，查找哪个fd被置位为POLLIN了；
- 将revents重置为0便于复用；
- 对置位的fd进行读取和处理；
相比于select解决的问题：
1.解决了bitmap大小限制；
2.解决了rset不可重用的情况后面由于二者原理相同，所以没能解决；
优点：
1、poll使用polfd数组来代替select中的bitmap，数组没有1024的限制，可以一次管理更多的client。它和select的主要区别就是，去掉了select只能监听1024个文件描述符的限制。
2、当pollfds数组中有事件发生，相应的revents置位为1，遍历的时候又置位回零，实现了pollfd数组的重用
5.5、epoll方法简介
epoll操作过程需要三个接口，分别是以下三个
-
int epoll_create(int size); //创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大参数size并不是限制了epoll所能监听的描述符最大个数，只是对内核初始分配内部数据结构的一个建议
-
int epoll_ctl( int epfd,//是epoll_create()的返回值 int op,//表示op操作，用三个宏来表示：添加：EPOLL_CTL_ADD,删除：EPOLL_CTL_DEL，修改：EPOLL_CTL_MOD，三个操作对fd监听 int fd,//fd是需要监听的对象（文件描述符） struct epoll_event *event//epoll_event告诉内核要监听什么事，其实就是读写操作 ); struct epoll_event{ _uint32_t events;//要监听的事件 epoll_data_t data;//具体数据 //events可以是以下几个宏的集合： EPOLLIN：表示对应的文件描述符可以读（包括对端SOCKET正常关闭） EPOLLOUT：表示对应的文件描述符可以写； } -
int epoll_wait( int epfd, struct epoll_event *events,//最大事件接收器 int maxevents, int timeout );等待epfd上的io事件，最多返回maxevents个事件。参数events用来从内核得到事件的集合，maxevents告之内核这个events有多大。
epoll是非阻塞的
epoll的执行流程：
- 当有数据的时候，会把相应的文件描述符“置位”，但是epool没有revent标志位，所以并不是真正的置位。这时候会把有数据的文件描述符放到队首。
- epoll会返回有数据的文件描述符的个数。
- 根据返回的个数读取前N个文件描述符即可。
- 读取、处理。
多路复用快的原因在于，操作系统提供了这样的系统调用，使得原来的 while循环里多次系统调用，变成了一次系统调用＋内核层遍历这些文件描述符。
epoll是现在最先进的IO多路复用器，Redis、Nginx，linux中的Java NIO都使用的是epoll。这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。
1、一个socket的生命周期中只有一次从用户态拷贝到内核态的过程，开销小。
2、使用event事件通知机制，每次socket中有数据会主动通知内核，并加入到就绪链表中，不需要遍历所有的socket。
在多路复用IO模型中，会有一个内核线程不断地去轮询多个socket 的状态，只有当真正读写事件发送时，才真正调用实际的IO读写操作。因为在多路复用IO模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有真正有读写事件进行时，才会使用IO资源，所以它大大减少来资源占用。多路I/O复用模型是利用 select. poll、epoll可以同时监察多个流的I/0事件的能力，在空闲时，会把当前线程阻塞掉，当有一个或多个流有IO事件时，就会从阻塞中唤醒，于是程序就会轮询一遍那些真正发生事件的流，没有发出读写操作的不会在轮询列表中，只依次顺序的处理就绪的流，这种做法避免了大量的无用操作。采用多路IO复用技术可以让单个进程高效的处理多个连接请求（尽量少的减少IO的时间消耗），且Redis在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈。
select、poll、epoll三个方法的对比
| select | poll | epoll | |
|---|---|---|---|
| 操作方法 | 遍历 | 遍历 | 回调 |
| 数据结构 | bitmap | 数组 | 红黑树 |
| 最大连接数 | 1024(X86)或2048(X64) | 无上限 | 无上限 |
| 最大支持文件描述符数 | 一般有最大值限制 | 65535 | 65535 |
| fd拷贝 | 每次调用select，都需要把fd集合从用户态拷贝到内核态 | 每次调用poll，都需要把fd集合从用户态拷贝到内核态 | fd首次需要调用epoll_ctl拷贝，每次调用epoll_wait不拷贝 |
| 工作效率 | 每次调用都进行线性遍历，时间复杂度为O(n) | 每次调用都进行线性遍历，时间复杂度为O(n) | 事件通知方式，每当fd就绪，系统注册的回调函数就会被调用，将就绪fd放到readyList里面，时间复杂度O(1) |
多路复用快的原因在于，操作系统提供了这样的系统调用，使得原来的 while循环里多次系统调用，变成了一次系统调用＋内核层遍历这些文件描述符。