Redis IO多路复用模型使用指南

来源：互联网 2026-07-07 09:14:05

面试中常常被问到这样一个问题：Redis单线程是如何处理那么多并发客户端连接的？为什么单线？为什么那么快？答案的核心在于：IO多路复用。具体来说，Redis利用epoll来实现IO多路复用。它的工作流程是：将连接信息和事件先放到一个队列里，然后一次性的交给文件事件分派器，由分派器根据事件类型，分

面试中常常被问到这样一个问题：Redis单线程是如何处理那么多并发客户端连接的？为什么单线？为什么那么快？

答案的核心在于：IO多路复用。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

具体来说，Redis利用epoll来实现IO多路复用。它的工作流程是：将连接信息和事件先放到一个队列里，然后一次性的交给文件事件分派器，由分派器根据事件类型，分发给对应的事件处理器去处理。

如果在面试中这么回答，基本能过关。但如果我们想更深一步——到底什么是IO多路复用模型？epoll又是什么东西？那就得先回到最基础的地方：UNIX网络编程的五种IO模型。

UNIX网络编程的五种IO模型

先列个大框架：

1、Blocking IO：阻塞IO；
2、NoneBlocking IO：非阻塞IO；
3、IO multiplexing：IO多路复用；
4、signal driven IO：信号驱动IO（略）；
5、asynchronous IO：异步IO（略）。

Redis IO多路复用模型使用指南

同步和异步

同步：调用者要一直等待调用结果的通知后才能进行后续的执行。简单说就是：现在就要，我可以等，等到结果出来为止。

异步：被调用方先返回一个应答让调用者先回去，然后自己去计算，算完了再把最终结果通知给调用方。异步调用想要获取结果，一般得靠回调。

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

阻塞和非阻塞

阻塞：调用方一直在那里等着，别的事情什么都不做。当前线/进程会被挂起，啥也不干。

非阻塞：调用发出去后，调用方先去做别的事情，不会阻塞当前线/进程，会立刻返回。

阻塞和非阻塞，讨论的对象是调用者（服务请求者），重点在于等消息时候的行为——调用者能不能干其他事。

4种组合方式

同步阻塞、同步非阻塞、异步阻塞、异步非阻塞。

同步阻塞：服务员说“快到你了，先别离开，我后台看一眼马上通知你”。客户就在海底捞前台干等，啥也不干。

同步非阻塞：服务员说“快到你了，先别离开”。客户在海底捞前台边刷抖音边等叫号。

异步阻塞：服务员说“还需要等位，你先去逛逛，一会通知你”。客户怕过号，就拿着排号小票啥也不干，就在那儿等着店员通知。

异步非阻塞：服务员说“还需要等位，你先去逛逛，一会通知你”。拿着排号小票，刷着抖音，等着店员通知。

理解了这四个组合，再去看后面的IO模型，就顺多了。

BIO

在阻塞式I/O模型中，应用程序从调用recvfrom开始，到它返回有数据报准备好这段时间，一直是阻塞的。recvfrom返回成功后，应用进程才能开始处理数据报。Tomcat 7之前就是用BIO多线程来解决多连接的。

accept监听

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);
        System.out.println("------RedisClient01 connection over");
    }
}

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);
        System.out.println("------RedisClient02 connection over");
    }
}

public class RedisServer{
    public static void main(String[] args) throws IOException
    {
        ServerSocket serverSocket = new ServerSocket(6379);
        while(true)
        {
            System.out.println("模拟RedisServer启动-----111 等待连接");
            Socket socket = serverSocket.accept();
            System.out.println("-----222 成功连接:  "+ IdUtil.simpleUUID());
            System.out.println();
        }
    }
}

启动RedisServer，再启动RedisClient01和RedisClient02。

Redis IO多路复用模型使用指南

read读取

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

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

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("===================="+"t"+ IdUtil.simpleUUID());
                System.out.println();
            }
            inputStream.close();
            socket.close();
        }
    }
}

启动RedisServerBIO，再启动RedisClient01发送消息。

Redis IO多路复用模型使用指南

成功读取了1号连接发来的消息。接着启动RedisClient02发送消息。

Redis IO多路复用模型使用指南

发现并没有接收到2号连接发送的消息。这时退出1号连接。

Redis IO多路复用模型使用指南

这才成功收到了2号连接的消息。

上面这个模型问题很大。如果客户端与服务端建立了连接，但这个客户端迟迟不发数据，线程就会一直卡在read()方法上。这样一来，其他客户端根本连不上。说白了，一次只能处理一个客户端，用户体验很差。

解决思路其实很直接——利用多线程。只要连接了一个socket，操作系统就分配一个线程来处理它。这样一来，read()方法阻塞在各自线程上，不会阻塞主线程。哪个线程的socket有数据，就读哪个socket，各取所需。

程序服务端只负责监听是否有客户端连接，使用 accept() 阻塞。客户端1连接服务端，就开辟一个线程（thread1）来执行 read() 方法，程序服务端继续监听。客户端2连接服务端，就开辟一个线程（thread2）来执行 read() 方法。客户端3来了也一样。

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

改造后的代码：

public class RedisServerBIOMultiThread{
    public static void main(String[] args) throws IOException
    {
        ServerSocket serverSocket = new ServerSocket(6379);
        while(true)
        {
            System.out.println("-----RedisServerBIOMultiThread 111 等待连接");
            Socket socket = serverSocket.accept();//阻塞1 ,等待客户端连接
            System.out.println("-----RedisServerBIOMultiThread 222 成功连接");
            new Thread(() -> {
                try {
                    InputStream inputStream = socket.getInputStream();
                    int length = -1;
                    byte[] bytes = new byte[1024];
                    System.out.println("-----333 等待读取"+ IdUtil.simpleUUID());
                    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();
            new Thread().start();
        }
    }
}

启动RedisServerBIOMultiThread，再启动RedisClient01和RedisClient02发送消息。

Redis IO多路复用模型使用指南

成功接收了1号和2号连接的消息。那么现在的BIO多线程模型还有什么问题吗？

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

解决思路有两个：

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

第二个办法：NIO（非阻塞式IO）。因为read()方法堵塞了，所以要开辟多个线程。如果能找到一种方法让read()方法不阻塞，那就不用开这么多线程了。这就引出了NIO模型。

NIO

在NIO模式中，一切都是非阻塞的：

accept()方法是非阻塞的，如果没有客户端连接，就返回无连接标识。read()方法也是非阻塞的，如果读取不到数据就返回“空闲中”标识，只有实际读到数据时才阻塞读数据的时间。

在NIO模式中，只有一个线程：当一个客户端与服务端连接，这个socket会被加入到一个数组中。程序隔一段时间遍历一次，看看这个socket的read()方法能否读到数据。这样一来，一个线程就能处理多个客户端的连接和读取了。

public class RedisServerNIO{
    static ArrayList 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());
            }
        }
    }
}

启动RedisServerNIO，再启动RedisClient01和RedisClient02发送消息。

Redis IO多路复用模型使用指南

成功接收了1号和2号连接的消息。但这里还有一个核心问题：如何用单线程处理大量的连接？

这时候，IO多路复用模型就登场了。

IO多路复用模型

I/O多路复用在英文中其实叫I/O multiplexing。多个Socket复用一根网线这个功能是在内核+驱动层实现的。I/O multiplexing中的multiplexing，指的就是在单个线程中，通过记录跟踪每一个Socket（I/O流）的状态来同时管理多个I/O流，目的是尽量提高服务器的吞吐能力。

大家都用过Nginx，Nginx使用epoll接收请求。Nginx会有很多链接进来，epoll会把它们都监视起来，然后像拨开关一样——谁有数据就拨向谁，然后调用相应的代码处理。Redis也是如此。

I/O：网络I/O。
多路：多个客户端连接（连接就是套接字描述符，即socket或者channel），指的是多条TCP连接。
复用：用一个进程来处理多条连接。使用单进程就能同时处理多个客户端的连接。

Redis IO多路复用模型使用指南

IO multiplexing就是我们常说的select、poll、epoll。有些技术书籍也称之为event driven IO（事件驱动IO）。它的核心机制是：通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），就能通知程序进行相应的读写操作。

它可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程（每个文件描述符一个线程，每次都new一个线程），大大节省了系统资源。

所以，I/O多路复用的特点是：通过一种机制，一个进程能同时等待多个文件描述符，而这些文件描述符（套接字描述符）中任意一个进入读就绪状态，select、poll、epoll等函数就可以返回。

文件描述符

文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。它在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。这个概念主要适用于UNIX、Linux这样的操作系统。

举例描述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反应模式。

所谓I/O多路复用机制，说白了就是：通过一种考试监考机制，一个老师可以监视多个考生，一旦某个考生举手想要交卷，就能通知监考老师进行相应的收卷或批改操作。所以这种机制需要调用班主任（select/poll/epoll）来配合。多个考生被同一个班主任监考，收完一个考生的卷子再处理其他人，无需等待所有考生——谁先举手就响应谁。

Reactor设计模式

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

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

Reactor模式中有2个关键组成：

1）Reactor：在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对IO事件做出反应。它就像公司的电话接线员，接听来自客户的电话并将线路转移到适当的联系人。
2）Handlers：处理程序执行I/O事件要完成的实际任务，类似于客户想要与之交谈的公司中的实际办理人。Reactor通过调度适当的处理程序来响应I/O事件，处理程序执行非阻塞操作。

Redis IO多路复用模型使用指南

那么，现在再来看一下Redis单线程是如何处理那么多并发客户端连接的？为什么单线？为什么那么快？

Redis是跑在单线程中的，所有操作都是按照顺序线性执行的。但是，由于读写操作等待用户输入或输出时是阻塞的，所以I/O操作一般情况下往往不能直接返回，这会导致某一文件的I/O阻塞导致整个进程无法对其它客户提供服务。而I/O多路复用就是为了解决这个问题而出现的。所谓I/O多路复用机制，就是通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或写就绪），就能通知程序进行相应的读写操作。这种机制需要select、poll、epoll来配合。

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

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

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

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

Redis IO多路复用模型使用指南

IO多路复用的具体实现：select、poll、epoll

select

select其实就是把NIO中用户态要遍历的fd数组（我们的每一个socket链接，安装进ArrayList里面的那个）拷贝到了内核态，让内核态来遍历。因为用户态判断socket是否有数据，还是要调用内核态的，所以拷贝到内核态后，遍历判断时就不用一直进行用户态和内核态的频繁切换了。select方式既做到了一个线程处理多个客户端连接（文件描述符），又减少了系统调用的开销（多个文件描述符只需要一次select的系统调用 + N次就绪状态的文件描述符的read系统调用）。

select函数的执行流程：

1、select是一个阻塞函数，当没有数据时，会一直阻塞在select那一行。
2、当有数据时会将rset中对应的那一位置为1。
3、select函数返回，不再阻塞。
4、遍历文件描述符数组，判断哪个fd被置位了。
5、读取数据，然后处理。

优点：select系统调用后，返回了一个置位后的&rset，用户态只需进行很简单的二进制比较，就能很快知道哪些socket需要read数据，有效提高了效率。

缺点：

1、bitmap最大1024位，一个进程最多只能处理1024个客户端。
2、&rset不可重用，每次socket有数据就会将相应的位置位。
3、文件描述符数组拷贝到了内核态（虽然无系统调用切换上下文的开销，但拷贝仍然有开销）。select调用需要传入fd数组，需要拷贝一份到内核，高并发场景下这种拷贝消耗的资源是惊人的。
4、select并没有通知用户态哪一个socket有数据，仍然需要O(n)的遍历。select仅仅返回可读文件描述符的个数，具体哪个可读还是要用户自己遍历。

poll

poll的执行流程：

1、将五个fd从用户态拷贝到内核态。
2、poll为阻塞方法，执行poll方法，如果有数据会将fd对应的revents置为POLLIN。
3、poll方法返回。
4、循环遍历，查找哪个fd被置位为POLLIN了。
5、将revents重置为0便于复用。
6、对置位的fd进行读取和处理。

优点：

1、poll使用pollfd数组来代替select中的bitmap，数组没有1024的限制，可以一次管理更多的client。它和select的主要区别就是，去掉了select只能监听1024个文件描述符的限制。
2、当pollfds数组中有事件发生，相应的revents置位为1，遍历的时候又置位回零，实现了pollfd数组的重用。

缺点：

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

1、pollfds数组拷贝到了内核态，仍然有开销。
2、poll并没有通知用户态哪一个socket有数据，仍然需要O(n)的遍历。