觉得对你有益的小伙伴记得点个赞+关注

后续完整内容持续更新中

希望一起交流的欢迎发邮件至javalyhn@163.com

Reids为什么这么快？这和它极好的高性能设计息息相关。

Reids的网络模型设计的十分优秀，epoll和IO多路复用被Reids设计到了极致，下面我们来详细探究一下。

0. 文件描述符

文件描述符（File Descriptor）：简称FD，是一个从0 开始的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字（Socket）。

1. 《Redis设计与实现》原话

Reactor 模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。后面会详解，暂且浅看一下。

这些文字总结下来就是说，Redis 6.0 将网络数据读写、请求协议解析通过多个IO线程的来处理，对于真正的命令执行来说，仍然使用主线程操作。

2. Redis是单线程如何处理那么多并发客户端连接，为什么这么快？

Redis的IO多路复用

Reids利用epoll（O多路复用器），将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。

Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现。

所谓 I/O 多路复用机制，就是说通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或写就绪），能够通知程序进行相应的读写操作。这种机制的使用需要 select 、 poll 、 epoll 来配合。多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。

Redis 服务采用 Reactor 的方式来实现文件事件处理器（每一个网络连接其实都对应一个文件描述符）。

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分：多个套接字、 IO多路复用程序、文件事件分派器、事件处理器。 因为文件事件派发器队列的消费是单线程的，所以Redis才叫单线程模型

3. IO多路复用逐词拆解

3.1 IO

IO就是指网络IO

3.2 多路

多个客户端连接（连接就是套接字描述符，即 socket 或者 channel）

3.3 复用

复用一个或几个线程。也就是说一个或一组线程处理多个 TCP 连接,使用单进程就能够实现同时处理多个客户端的连接

3.4 总结

一个服务端进程可以同时处理多个套接字描述符（其发展可以分select->poll->epoll三个阶段来描述）。

4. 同步与异步

4.1 同步

调用者要一直等待被调用者调用结果的通知后才能进行后续的执行，现在就要，我可以等，等出结果为止

4.2 异步

指被调用者先返回应答让调用者先回去，然后再计算调用结果，计算完最终结果后再通知并返回给调用方

4.3 同步与异步的理解

同步、异步的讨论对象是被调用者(服务提供者)，重点在于获得调用结果的消息通知方式上

5. 阻塞与非阻塞

5.1 阻塞

调用者一直在等待而且别的事情什么都不做，当前进/线程会被挂起，啥都不干

5.2 非阻塞

调用在发出去后，调用方先去忙别的事情，不会阻塞当前进/线程，而会立即返回

5.3 阻塞与非阻塞的理解

阻塞、非阻塞的讨论对象是调用者(服务请求者)，重点在于等消息时候的行为，调用者是否能干其它事

6. Unix网络编程中的五种IO模型

在《UNIX网络编程》一书中，总结归纳了5种IO模型：

阻塞IO（Blocking IO）
非阻塞IO（Nonblocking IO）
IO多路复用（IO Multiplexing）
信号驱动IO（Signal Driven IO）
异步IO（Asynchronous IO）

7. BIO（阻塞IO）

7.1 过程图解

应用程序想要去读取数据，它是无法直接去读取磁盘数据的，他需要先到内核里边去等待内核操作硬件拿到数据，这个过程就是1，是需要等待的，等到内核从磁盘上把数据加载出来之后，再把这个数据写给用户的缓存区，这个过程是2，如果是阻塞IO，那么整个过程中，用户从发起读请求开始，一直到读取到数据，都是一个阻塞状态。

具体流程如下图：

用户去读取数据时，会去先发起recvform （这是一个函数用于从已连接的套接口上接收数据，并捕获数据发送源的地址）一个命令，去尝试从内核上加载数据，如果内核没有数据，那么用户就会等待，此时内核会去从硬件上读取数据，内核读取数据之后，会把数据拷贝到用户态，并且返回ok，整个过程，都是阻塞等待的，这就是阻塞IO

所以阻塞IO阻塞了以下两个阶段

阶段一：

用户进程尝试读取数据（比如网卡数据）
此时数据尚未到达，内核需要等待数据
此时用户进程也处于阻塞状态

阶段二：

数据到达并拷贝到内核缓冲区，代表已就绪
将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据

7.2 accept代码演示

准备一个ReidsServer和两个RedisClient

Server端开始监听

public class RedisServer
{
    public static void main(String[] args) throws IOException
    {
        byte[] bytes = new byte[1024];

        ServerSocket serverSocket = new ServerSocket(6379);

        while(true)
        {
            System.out.println("-----111 等待连接");
            Socket socket = serverSocket.accept();
            System.out.println("-----222 成功连接");
        }
    }
}

开始1号Client端

public class RedisClient01
{
    public static void main(String[] args) throws IOException
    {
        System.out.println("------RedisClient01 start");
        Socket socket = new Socket("127.0.0.1", 6379);
    }
}

我们发现client连接完就结束了，server端继续请求着连接

7.3 read代码演示

RedisServerBIO

public class RedisServerBIO
{
    public static void main(String[] args) throws IOException
    {

        ServerSocket serverSocket = new ServerSocket(6379);

        while(true)
        {
            System.out.println("-----111 等待连接");
            Socket socket = serverSocket.accept();//阻塞1 ,等待客户端连接
            System.out.println("-----222 成功连接");

            InputStream inputStream = socket.getInputStream();
            int length = -1;
            byte[] bytes = new byte[1024];
            System.out.println("-----333 等待读取");
            while((length = inputStream.read(bytes)) != -1)//阻塞2 ,等待客户端发送数据
            {
                System.out.println("-----444 成功读取"+new String(bytes,0,length));
                System.out.println("====================");
                System.out.println();
            }
            inputStream.close();
            socket.close();
        }
    }
}

RedisClient01

public class RedisClient01
{
    public static void main(String[] args) throws IOException
    {
        Socket socket = new Socket("127.0.0.1",6379);
        OutputStream outputStream = socket.getOutputStream();

        //socket.getOutputStream().write("RedisClient01".getBytes());

        while(true)
        {
            Scanner scanner = new Scanner(System.in);
            String string = scanner.next();
            if (string.equalsIgnoreCase("quit")) {
                break;
            }
            socket.getOutputStream().write(string.getBytes());
            System.out.println("------input quit keyword to finish......");
        }
        outputStream.close();
        socket.close();
    }
}

RedisClient02

public class RedisClient02
{
    public static void main(String[] args) throws IOException
    {
        Socket socket = new Socket("127.0.0.1",6379);
        OutputStream outputStream = socket.getOutputStream();

        //socket.getOutputStream().write("RedisClient01".getBytes());

        while(true)
        {
            Scanner scanner = new Scanner(System.in);
            String string = scanner.next();
            if (string.equalsIgnoreCase("quit")) {
                break;
            }
            socket.getOutputStream().write(string.getBytes());
            System.out.println("------input quit keyword to finish......");
        }
        outputStream.close();
        socket.close();
    }
}

我们先启动server再启动client1和client2

由于client2先连上客户端，接着server一直阻塞在read方法，因此并未与client1建立连接，我们通过client2发送消息

可见消息发送成功，但是server仍未域client1建立连接，而且一直阻塞在read方法等待client2发送消息

因此存在的问题是：如果客户端与服务端建立了连接，如果这个连接的客户端迟迟不发数据，程就会一直堵塞在read()方法上，这样其他客户端也不能进行连接， 也就是一次只能处理一个客户端，对客户很不友好

知道问题所在了，请问如何解决？？

7.4 多线程解决read阻塞代码演示

基于7.3 的问题，我们可以想到用多线程来解决read阻塞问题，只要连接了一个socket，操作系统分配一个线程来处理，这样read()方法堵塞在每个具体线程上而不堵塞主线程，就能操作多个socket了，哪个线程中的socket有数据，就读哪个socket，各取所需，灵活统一。

程序服务端只负责监听是否有客户端连接，使用 accept() 阻塞

客户端1连接服务端，就开辟一个线程（thread1）来执行 read() 方法，程序服务端继续监听

客户端2连接服务端，也开辟一个线程（thread2）来执行 read() 方法，程序服务端继续监听

客户端3连接服务端，也开辟一个线程（thread3）来执行 read() 方法，程序服务端继续监听。。。。。。

任何一个线程上的socket有数据发送过来，read()就能立马读到，cpu就能进行处理。

RedisServerBIOMultiThread

public class RedisServerBIOMultiThread
{
    public static void main(String[] args) throws IOException
    {
        ServerSocket serverSocket = new ServerSocket(6379);

        while(true)
        {
            //System.out.println("-----111 等待连接");
            Socket socket = serverSocket.accept();//阻塞1 ,等待客户端连接
            //System.out.println("-----222 成功连接");

            new Thread(() -> {
                try {
                    InputStream inputStream = socket.getInputStream();
                    int length = -1;
                    byte[] bytes = new byte[1024];
                    System.out.println("-----333 等待读取");
                    while((length = inputStream.read(bytes)) != -1)//阻塞2 ,等待客户端发送数据
                    {
                        System.out.println("-----444 成功读取"+new String(bytes,0,length));
                        System.out.println("====================");
                        System.out.println();
                    }
                    inputStream.close();
                    socket.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            },Thread.currentThread().getName()).start();

            System.out.println(Thread.currentThread().getName());

        }
    }
}

RedisClient01

public class RedisClient01
{
    public static void main(String[] args) throws IOException
    {
        Socket socket = new Socket("127.0.0.1",6379);
        OutputStream outputStream = socket.getOutputStream();

        //socket.getOutputStream().write("RedisClient01".getBytes());

        while(true)
        {
            Scanner scanner = new Scanner(System.in);
            String string = scanner.next();
            if (string.equalsIgnoreCase("quit")) {
                break;
            }
            socket.getOutputStream().write(string.getBytes());
            System.out.println("------input quit keyword to finish......");
        }
        outputStream.close();
        socket.close();
    }
}

RedisClient02

public class RedisClient02
{
    public static void main(String[] args) throws IOException
    {
        Socket socket = new Socket("127.0.0.1",6379);
        OutputStream outputStream = socket.getOutputStream();

        //socket.getOutputStream().write("RedisClient01".getBytes());

        while(true)
        {
            Scanner scanner = new Scanner(System.in);
            String string = scanner.next();
            if (string.equalsIgnoreCase("quit")) {
                break;
            }
            socket.getOutputStream().write(string.getBytes());
            System.out.println("------input quit keyword to finish......");
        }
        outputStream.close();
        socket.close();
    }
}

可见client1和client2都能与server连接，并且发送消息，read不会阻塞

那么这个方式会有什么问题呢

多线程模型

每来一个客户端，就要开辟一个线程，如果来1万个客户端，那就要开辟1万个线程。在操作系统中用户态不能直接开辟线程，需要调用内核来创建的一个线程，这其中还涉及到用户状态的切换（上下文的切换），十分耗资源。

知道问题所在了，请问如何解决？？

第一个办法：使用线程池

这个在客户端连接少的情况下可以使用，但是用户量大的情况下，你不知道线程池要多大，太大了内存可能不够，也不可行。

第二个办法：NIO（非阻塞式IO）方式 因为read()方法堵塞了，所有要开辟多个线程，如果什么方法能使read()方法不堵塞，这样就不用开辟多个线程了，这就用到了另一个IO模型，NIO（非阻塞式IO）

tomcat7之前就是用BIO多线程来解决多连接

8. NIO

8.1 NIO图解

当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。所以，NIO特点是用户进程需要不断的主动询问内核数据准备好了吗？

在非阻塞式 I/O 模型中，应用程序把一个套接口设置为非阻塞，就是告诉内核，当所请求的I/O操作无法完成时，不要将进程睡眠而是返回一个“错误”，应用程序基于 I/O 操作函数将不断的轮询数据是否已经准备好，如果没有准备好，继续轮询，直到数据准备好为止。

NIO分为以下两个阶段

阶段一：

用户进程尝试读取数据（比如网卡数据）
此时数据尚未到达，内核需要等待数据
返回异常给用户进程
用户进程拿到error后，再次尝试读取
循环往复，直到数据就绪

阶段二：

将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据
可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

8.2 代码演示

RedisServerNIO

public class RedisServerNIO
{
    static ArrayList<SocketChannel> socketList = new ArrayList<>();
    static ByteBuffer byteBuffer = ByteBuffer.allocate(1024);

    public static void main(String[] args) throws IOException
    {
        System.out.println("---------RedisServerNIO 启动等待中......");
        ServerSocketChannel serverSocket = ServerSocketChannel.open();
        serverSocket.bind(new InetSocketAddress("127.0.0.1",6379));
        serverSocket.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 = serverSocket.accept();
            if(socketChannel != null)
            {
                System.out.println("-----成功连接: ");
                socketChannel.configureBlocking(false);//设置为非阻塞模式
                socketList.add(socketChannel);
                System.out.println("-----socketList size: "+socketList.size());
            }
        }
    }
}

RedisClient01

public class RedisClient01
{
    public static void main(String[] args) throws IOException
    {
        System.out.println("------RedisClient01 start");
        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();
            if (string.equalsIgnoreCase("quit")) {
                break;
            }
            socket.getOutputStream().write(string.getBytes());
            System.out.println("------input quit keyword to finish......");
        }
        outputStream.close();
        socket.close();
    }
}

RedisClient02

public class RedisClient02
{
    public static void main(String[] args) throws IOException
    {
        System.out.println("------RedisClient02 start");


        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();
            if (string.equalsIgnoreCase("quit")) {
                break;
            }
            socket.getOutputStream().write(string.getBytes());
            System.out.println("------input quit keyword to finish......");
        }
        outputStream.close();
        socket.close();
    }
}

可见效果同BIO多线程实现，但是NIO不使用多线程方式，而是采用类似于CAS原理

9. NIO的优缺点

9.1 NIO的两个问题

这个模型在客户端少的时候十分好用，但是客户端如果很多，比如有1万个客户端进行连接，那么每次循环就要遍历1万个socket，如果一万个socket中只有10个socket有数据，也会遍历一万个socket，就会做很多无用功，每次遍历遇到 read 返回 -1 时仍然是一次浪费资源的系统调用。
而且这个遍历过程是在用户态进行的，用户态判断socket是否有数据还是调用内核的read()方法实现的，这就涉及到用户态和内核态的切换，每遍历一个就要切换一次，开销很大因为这些问题的存在。

9.2 优点

不会阻塞在内核的等待`数据过程，每次发起的 I/O 请求可以立即返回，不用阻塞等待，实时性较好。

9.3 缺点

轮询将会不断地询问内核，这将占用大量的 CPU 时间，系统资源利用率较低，所以一般 Web 服务器不使用这种 I/O 模型。

9.4 总结

让Linux内核搞定上述需求，我们将一批文件描述符通过一次系统调用传给内核由内核层去遍历，才能真正解决这个问题。IO多路复用应运而生，也即将上述工作直接放进Linux内核，不再两态转换而是直接从内核获得结果，因为内核是非阻塞的。

10. IO Multiplexing（IO多路复用）

10.1 IO多路复用图解

IO multiplexing就是我们说的select，poll，epoll，有些地方也称这种IO方式为event driven IO事件驱动IO。就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程，每次new一个线程)，这样可以大大节省系统资源。所以，I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select()函数就可以返回。

通过FD，我们的网络模型可以利用一个线程监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

IO多路复用分为下面两个阶段

阶段一：

用户进程调用select，指定要监听的FD集合
核监听FD对应的多个socket
任意一个或多个socket数据就绪则返回readable
此过程中用户进程阻塞

阶段二：

用户进程找到就绪的socket
依次调用recvfrom读取数据
内核将数据拷贝到用户空间
用户进程处理数据

当用户去读取数据的时候，不再去直接调用recvfrom了，而是调用select的函数，select函数会将需要监听的数据交给内核，由内核去检查这些数据是否就绪了，如果说这个数据就绪了，就会通知应用程序数据就绪，然后来读取数据，再从内核中把数据拷贝给用户态，完成数据处理，如果N多个FD一个都没处理完，此时就进行等待。

用IO复用模式，可以确保去读数据的时候，数据是一定存在的，他的效率比原来的阻塞IO和非阻塞IO性能都要高

10.2 用易懂的话再次叙述IO多路复用

模拟一个tcp服务器处理30个客户socket。假设你是一个监考老师，让30个学生解答一道竞赛考题，然后负责验收学生答卷，你有下面几个选择：

第一种选择：按顺序逐个验收，先验收A，然后是B，之后是C、D。。。这中间如果有一个学生卡住，全班都会被耽误,你用循环挨个处理socket，根本不具有并发能力。

第二种选择：你创建30个分身线程，每个分身线程检查一个学生的答案是否正确。这种类似于为每一个用户创建一个进程或者线程处理连接。

第三种选择，你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理E和A。。。这种就是IO复用模型。Linux下的select、poll和epoll就是干这个的。

将用户socket对应的fd注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。这样，整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor反应模式。

11. Reactor设计模式

11.1 是什么

基于 I/O 复用模型：多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。

Reactor 模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor 模式也叫 Dispatcher 模式。即 I/O 多路复用统一监听事件，收到事件后分发(Dispatch 给某进程)，是编写高性能网络服务器的必备技术。

Reactor 模式中有 2 个关键组成： 1）Reactor：Reactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对 IO 事件做出反应。它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人；

2）Handlers：处理程序执行 I/O 事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际办理人。Reactor 通过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操作。

11.2 Redis为什么是单线程

Redis 服务采用 Reactor 的方式来实现文件事件处理器（每一个网络连接其实都对应一个文件描述符）

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分：多个套接字、 IO多路复用程序、文件事件分派器、事件处理器。

因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型

12. select方法

12.1 官网介绍

man7.org/linux/man-p…

select是第一个实现 (1983 左右在BSD里面实现)

select 函数监视的文件描述符分3类，分别是readfds、writefds和exceptfds，将用户传入的数组拷贝到内核空间

调用后select函数会阻塞，直到有描述符就绪（有数据可读、可写、或者有except）或超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。

当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。

12.2 C语言代码

12.3 select优点

select 其实就是把NIO中用户态要遍历的fd数组(我们的每一个socket链接，安装进ArrayList里面的那个)拷贝到了内核态，让内核态来遍历，因为用户态判断socket是否有数据还是要调用内核态的，所有拷贝到内核态后，这样遍历判断的时候就不用一直用户态和内核态频繁切换了

从代码中可以看出，select系统调用后，返回了一个置位后的&rset，这样用户态只需进行很简单的二进制比较，就能很快知道哪些socket需要read数据，有效提高了效率

12.4 select问题

1、bitmap最大1024位，一个进程最多只能处理1024个客户端

2、&rset不可重用，每次socket有数据就相应的位会被置位

3、文件描述符数组拷贝到了内核态(只不过无系统调用切换上下文的开销。（内核层可优化为异步事件通知）)，仍然有开销。select 调用需要传入 fd 数组，需要拷贝一份到内核，高并发场景下这样的拷贝消耗的资源是惊人的。（可优化为不复制）

4、select并没有通知用户态哪一个socket有数据，仍然需要O(n)的遍历。select 仅仅返回可读文件描述符的个数，具体哪个可读还是要用户自己遍历。（可优化为只返回给用户就绪的文件描述符，无需用户做无效的遍历）

我们自己模拟写的是，RedisServerNIO.java,只不过将它内核化了。

12.5 select小结论

select方式，既做到了一个线程处理多个客户端连接（文件描述符），又减少了系统调用的开销（多个文件描述符只有一次 select 的系统调用 + N次就绪状态的文件描述符的 read 系统调用）

13. poll方法

13.1 官网介绍

man7.org/linux/man-p…

1997年实现了poll

13.2 C语言代码

13.3 poll优点

1、poll使用pollfd数组来代替select中的bitmap，数组没有1024的限制，可以一次管理更多的client。它和 select 的主要区别就是，去掉了 select 只能监听 1024 个文件描述符的限制。

2、当pollfds数组中有事件发生，相应的revents置位为1，遍历的时候又置位回零，实现了pollfd数组的重用

13.4 poll问题

poll 解决了select缺点中的前两条，其本质原理还是select的方法，还存在select中原来的问题

1、pollfds数组拷贝到了内核态，仍然有开销

2、poll并没有通知用户态哪一个socket有数据，仍然需要O(n)的遍历

14. epoll方法

14.1 官网介绍

man7.org/linux/man-p…

在2002年被大神 Davide Libenzi (戴维德·利本兹)发明出来了

14.2 C语言代码

14.3 C语言代码总结

14.4 epoll三步调用

epoll_create

创建一个 epoll 句柄

epoll_ctl

向内核添加、修改或删除要监控的文件描述符

epoll_wait

类似发起了select() 调用

14.5 事件通知机制

1、当有网卡上有数据到达了，首先会放到DMA（内存中的一个buffer，网卡可以直接访问这个数据区域）中

2、网卡向cpu发起中断，让cpu先处理网卡的事

3、中断号在内存中会绑定一个回调，哪个socket中有数据，回调函数就把哪个socket放入就绪链表中

14.6 epoll结论

多路复用快的原因在于，操作系统提供了这样的系统调用，使得原来的 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/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈

15. 三个方法对比

16. 五种IO模型总结

所谓 I/O 多路复用机制，就是说通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或写就绪），能够通知程序进行相应的读写操作。这种机制的使用需要 select 、 poll 、 epoll 来配合。多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理；

17. 为什么到现在还会有这三种，直接留epoll不就好了

因为epoll只支持Linux系统，而Windows底层还是需要采用select的

那么至此Reids高级篇就到此结束了，谢谢各位小伙伴！！！！！！

Reids高级（十四）、Redis网络模型详解

0. 文件描述符

1. 《Redis设计与实现》原话

2. Redis是单线程如何处理那么多并发客户端连接，为什么这么快？

3. IO多路复用逐词拆解

3.1 IO

3.2 多路

3.3 复用

3.4 总结

4. 同步与异步

4.1 同步

4.2 异步

4.3 同步与异步的理解

5. 阻塞与非阻塞

5.1 阻塞

5.2 非阻塞

5.3 阻塞与非阻塞的理解

6. Unix网络编程中的五种IO模型

7. BIO（阻塞IO）

7.1 过程图解

7.2 accept代码演示

7.3 read代码演示

7.4 多线程解决read阻塞代码演示

8. NIO

8.1 NIO图解

8.2 代码演示

9. NIO的优缺点

9.1 NIO的两个问题

9.2 优点

9.3 缺点

9.4 总结

10. IO Multiplexing（IO多路复用）

10.1 IO多路复用图解

10.2 用易懂的话再次叙述IO多路复用

11. Reactor设计模式

11.1 是什么

11.2 Redis为什么是单线程

12. select方法

12.1 官网介绍

12.2 C语言代码

12.3 select优点

12.4 select问题

12.5 select小结论

13. poll方法

13.1 官网介绍

13.2 C语言代码

13.3 poll优点

13.4 poll问题

14. epoll方法

14.1 官网介绍

14.2 C语言代码

14.3 C语言代码总结

14.4 epoll三步调用

14.5 事件通知机制

14.6 epoll结论

15. 三个方法对比

16. 五种IO模型总结

17. 为什么到现在还会有这三种，直接留epoll不就好了