Redis 核心面试题归纳

文章目录

- Redis
- - AOF 相关
  - - 1. redis AOF 文件备份时，是使用的 write ahead log 的方式吗
    - 2. redis 开启AOF后的写入步骤
    - 3. redis AOF文件重写过程
    - 4.AOF 持久化策略
  - RDB 相关
  - - 1.RDB 写入过程
    - rdb 过程中，复制的页表是什么
  - Redis 主从同步
  - - 1.PSYNC 和 SYNC 的区别
    - 2.replication_buffer 和 replication_backlog_buffer
  - Redis 数据结构
  - - 1.基本数据结构
  - 网络模型
  - - 1.阻塞式IO
    - 2.非阻塞式IO
    - 3.IO多路复用（select poll epoll）
    - 4.信号驱动IO
    - 5.异步IO

Redis

AOF 相关

1. redis AOF 文件备份时，是使用的 write ahead log 的方式吗

Redis的AOF备份不是使用的Write-Ahead Logging（WAL）方式。Redis的AOF（Append-Only File）备份实际上是一种写后日志（Write-After Logging）的方式。在Redis中，数据首先会被写入内存，然后再将相关的操作命令记录到AOF日志文件中。这种方式的主要好处是可以避免记录错误的命令，因为只有当命令成功执行后，它才会被写入日志文件。

与此相反，Write-Ahead Logging（WAL）是一种在数据实际写入之前，先将修改的数据记录到日志文件中的机制。这种机制在数据库系统（如MySQL）中很常见，用于确保在发生故障时能够恢复数据。

因此，虽然Redis和某些数据库系统都使用了日志来确保数据的持久性和可恢复性，但它们采用的日志机制和方式是不同的。Redis的AOF备份使用的是写后日志的方式，而不是Write-Ahead Logging的方式。

2. redis 开启AOF后的写入步骤

在Redis中，当使用AOF（Append-Only File）持久化时，写入操作并不是直接写入到AOF文件后立即返回写入成功。实际上，Redis的写入操作遵循以下步骤：

写入内存：当客户端发送一个写命令（如SET、ADD等）到Redis服务器时，Redis首先会在内存中执行该命令，更新相应的数据结构。
写入AOF缓冲区：然后，Redis会将这个写命令追加到一个内部的AOF缓冲区中。这个缓冲区是一个内存中的队列，用于暂存待写入AOF文件的命令。
异步写入AOF文件：Redis会在一个后台线程中，将AOF缓冲区中的命令异步地写入到AOF文件中。这个过程是异步的，意味着它不会阻塞主线程对客户端的响应。
返回写入成功：一旦写命令在内存中执行成功，并且已经被追加到AOF缓冲区中，Redis就会向客户端返回写入成功的响应。此时，即使AOF文件还未将命令写入磁盘，客户端也会认为写入操作已经完成。
持久化到磁盘：后台线程会在适当的时候（比如AOF缓冲区积累了一定数量的命令，或者达到了特定的时间间隔）将AOF缓冲区中的命令持久化到磁盘上的AOF文件中。这个过程是后台进行的，不会阻塞主线程。

因此，虽然Redis在写入命令到AOF文件之前就已经向客户端返回了写入成功的响应，但命令最终会被持久化到AOF文件中，保证了数据的持久性。这种设计使得Redis可以同时保证高性能和数据的安全性。在Redis的配置中，可以通过调整AOF相关的参数（如appendfsync）来控制AOF文件同步到磁盘的策略，以平衡性能和持久性之间的需求。

3. redis AOF文件重写过程

AOF（Append-Only File）重写是Redis持久化机制中的一个重要环节，它用于优化AOF文件的大小和性能。当AOF文件增长到一定大小时，Redis会触发AOF重写过程，创建一个新的AOF文件，其中包含了能够重建当前数据集的最小命令集合。这个过程可以显著减少AOF文件的大小，因为它只包含必要的命令，而不是所有原始的操作日志。

AOF重写的过程大致如下：

触发重写：当AOF文件的大小超过配置的auto-aof-rewrite-min-size参数（默认为64MB）和auto-aof-rewrite-percentage参数（默认为100，表示AOF文件大小是上一次重写后大小的两倍）时，Redis会触发AOF重写。
创建临时文件：Redis会创建一个新的临时AOF文件，用于存储重写后的命令。
遍历数据集：Redis会遍历当前内存中的数据集，而不是读取原始的AOF文件。对于每个key，Redis会生成一个或多个命令来重建这个key。
写入临时文件：生成的重建命令会被写入到临时AOF文件中。这个过程中，Redis会跳过那些不必要的命令，例如过期键的删除命令，以及那些被后续命令覆盖的命令。
替换旧文件：当临时AOF文件写入完成后，Redis会将这个临时文件重命名为原来的AOF文件，从而替换掉旧的AOF文件。在重命名过程中，如果有写操作发生，Redis会先将这些写操作写入到一个新的临时文件中，等重命名操作完成后，再将这个临时文件的内容追加到新的AOF文件中。
更新统计信息：完成AOF重写后，Redis会更新统计信息，例如最后一次AOF重写的时间和文件大小等。

需要注意的是，在AOF重写过程中，Redis会同时向旧的AOF文件和新的临时文件写入命令。这是为了保证在重写过程中，如果发生故障，Redis仍然可以从旧的AOF文件中恢复数据。只有当临时文件写入完成，并且成功重命名为新的AOF文件后，旧的AOF文件才会被删除。

AOF重写是一个资源密集型的操作，因为它需要遍历整个数据集。因此，Redis会在后台异步地执行这个过程，以避免阻塞正常的写操作。重写过程中，Redis的性能可能会有所下降，因此建议在生产环境中，根据实际的负载情况，合理地配置AOF重写相关的参数。

4.AOF 持久化策略

AOF 持久化策略：这个持久化策略和MySQL中的 redo 日志的持久化策略很相似

always：每次写入缓存区都要同步到AOF文件中，硬盘的操作比较慢，限制了Redis高并发，不建议配置。
no：每次写入缓存区后不进行同步，同步到AOF文件的操作由操作系统负责，每次同步AOF文件的周期不可控，而且增大了每次同步的硬盘的数据量。
eversec：每次写入缓存区后，由专门的线程每秒钟同步一次，做到了兼顾性能和数据安全。是建议的同步策略，也是默认的策略。

RDB 相关

1.RDB 写入过程

RDB（Redis DataBase）文件是Redis用于持久化数据的一种方式，它会在指定的时间间隔内，将内存中的数据集快照写入到磁盘上的RDB文件中。RDB文件的写入过程大致如下：

触发RDB持久化：RDB持久化可以在多种情况下被触发，例如执行SAVE或BGSAVE命令、配置文件中指定的时间间隔达到、或者Redis服务器接收到SHUTDOWN命令等。其中，SAVE命令会阻塞Redis服务器直到持久化完成，而BGSAVE命令则会在后台异步执行持久化。
创建子进程：当触发RDB持久化时，Redis会创建一个子进程来执行持久化操作。这个子进程是Redis主进程的副本，它会共享主进程的内存空间。由于子进程是在主进程的内存空间上创建的，因此它可以直接访问内存中的数据。
生成RDB文件：子进程会遍历Redis内存中的所有数据，并将这些数据以紧凑的格式写入到一个临时RDB文件中。这个过程包括了将键值对转换为RDB文件格式，并写入到临时文件中。在生成RDB文件的过程中，Redis会使用写时复制（Copy-On-Write）机制来避免对主进程的影响。
替换旧RDB文件：当临时RDB文件生成完成后，子进程会用这个临时文件替换旧的RDB文件。替换操作是原子性的，即在整个替换过程中，Redis会保证只有一个RDB文件存在。替换完成后，旧的RDB文件会被删除，新的RDB文件成为当前的持久化文件。
完成持久化：当新的RDB文件替换旧文件后，RDB持久化操作就完成了。此时，Redis服务器会释放与持久化相关的资源，并继续处理客户端的请求。

需要注意的是，在RDB持久化过程中，Redis的主进程会继续处理客户端的请求，并且不会被阻塞。这是因为持久化操作是在子进程中执行的，与主进程是并发执行的。这种设计使得Redis可以在保证数据持久性的同时，保持高性能的响应能力。

RDB持久化适合用于大规模数据恢复的场景，因为RDB文件包含了某个时间点的完整数据集快照，可以快速地恢复数据。但是，RDB持久化也存在一些缺点，比如无法实时持久化最新的数据（只有在触发持久化操作时才会生成RDB文件），以及在持久化过程中可能会占用较多的磁盘空间和I/O资源。因此，在使用RDB持久化时需要根据实际场景进行权衡和配置。

rdb 过程中，复制的页表是什么

在Redis的RDB持久化过程中，当执行BGSAVE命令时，Redis会通过fork()系统调用创建一个子进程。这个子进程是主进程的副本，它会共享主进程的内存空间，包括内存中的页表。

页表（Page Table）是操作系统用于实现虚拟内存到物理内存地址映射的一种数据结构。在Redis的上下文中，当主线程fork出BGSAVE子进程后，子进程会复制父进程（即主线程）的页表。这些页表中保存了主线程在执行BGSAVE命令时，所有数据块在内存中的物理地址。

子进程在生成RDB文件时，会根据这些页表读取主线程的内存数据，然后写入到磁盘中的RDB文件中。这种写时复制（Copy-On-Write）机制保证了在持久化过程中，主线程可以继续处理客户端的请求，而不会因为持久化操作而被阻塞。

如果主线程在子进程复制页表后修改了某个虚页的数据，主线程会使用写时复制机制为新数据分配一个新的物理页，并将修改后的数据写入新的物理页中。而虚页到原物理页的映射关系仍然保留在子进程中，所以子进程可以无误地将虚页的原始数据写入RDB文件。这样，RDB持久化既保证了数据的持久性，又不会影响主线程的性能。

RDB 过程

Redis 主从同步

两个概念：

Replication id：简称replid，是数据集的标记，id一致则说明是同一个数据集，每一个master 都有一个唯一的replid，slave 则会继承master节点的replid
offset：偏移量，随着记录在repl_baklog 中的数据增加而逐渐增大。slave 完成同步时会记录当前同步的offset。如果小于master 中的offset 表明需要更新

全量同步流程：

slave 节点请求增量同步
master节点判断replid，发现不一致，拒绝增量同步
master将完整内存数据生成RDB，发送RDB到slave
slave清空本地数据，加载master的RDB
master将RDB期间的命令记录在repl_bakiog，并持续将log 中的命令发送给slave中去

1.PSYNC 和 SYNC 的区别

主从复制中的PSYNC和SYNC命令的主要区别在于断线后重复制阶段处理的方式不同。

当主从同步完成后，如果此时从服务器宕机了一段时间，重新上线后需要重新同步主服务器。在这种情况下，如果使用的是SYNC命令，从服务器会重新向主服务器发起SYNC命令，主服务器会将所有数据再次重新生成RDB快照发给从服务器开始同步。这意味着，无论从服务器断线期间主服务器发生了哪些变化，从服务器都需要重新接收全部数据。

而如果使用PSYNC命令，主服务器会根据双方数据的偏差量判断是否需要进行完整重同步，还是仅将断线期间执行过的写命令发给从服务器。这种方式更加高效，因为只有在数据有偏差时才需要传输数据，而不是每次都传输全部数据。这大大减少了网络资源和磁盘IO的开销。

因此，PSYNC相比SYNC在处理主从复制时更加高效，特别是在网络不稳定或短暂中断的情况下。这也是为什么Redis在2.8版本后开始使用PSYNC进行复制的原因。

2.replication_buffer 和 replication_backlog_buffer

在 Redis 的主从复制中，当使用 PSYNC 命令时，从服务器会发送一个包含其最后接收到的复制流数据 ID 和偏移量的请求给主服务器。主服务器根据这些信息来决定是否需要进行全量同步（即生成 RDB 文件并传输给从服务器）还是进行增量同步（只传输从服务器缺失的部分数据）。

关于 replication_buffer 和 replication_backlog 的使用，这里有一些关键点需要注意：

replication_buffer：这是主服务器用于存储待发送给从服务器的写命令的缓冲区。当主服务器执行写命令时，这些命令会被添加到 replication_buffer 中，稍后发送给从服务器。这个缓冲区是暂时的，主要用于增量同步过程中。

replication_backlog：这是一个固定大小的环形缓冲区，用于存储最近执行过的写命令。它的主要目的是在主从连接断开后，能够让从服务器重新连接并继续进行增量同步。replication_backlog 保存了从服务器可能需要的写命令的历史记录。

当使用 PSYNC 时，主服务器会检查 replication_backlog 中是否有从服务器需要的数据。如果 replication_backlog 中包含了从服务器请求的数据（即数据的 ID 和偏移量在 replication_backlog 的范围内），则主服务器会从 replication_backlog 中读取这些数据，并通过网络发送给从服务器。这样，从服务器可以接收到它缺失的写命令，并将其应用到自己的数据集上，从而实现增量同步。

如果 replication_backlog 中没有从服务器请求的数据（可能是因为从服务器太长时间没有与主服务器通信，或者 replication_backlog 已经被新的写命令覆盖），则主服务器会进行全量同步，生成一个新的 RDB 文件并发送给从服务器。

因此，在使用 PSYNC 后，主服务器会根据从服务器的请求和 replication_backlog 的内容来决定是使用 replication_buffer 中的数据还是 replication_backlog 中的数据来进行增量同步。如果 replication_backlog 中有所需数据，则优先使用 replication_backlog；否则，会进行全量同步。

在 PSYNC 过程中，replication_buffer 仍然可能被使用，但这取决于具体的同步情况。让我们详细分析一下：

PSYNC 命令的主要目的是进行部分同步（partial resynchronization），这意味着主服务器会尝试只发送从服务器缺失的数据，而不是整个数据集。为了实现这一点，主服务器会检查 replication_backlog（复制积压缓冲区）来查找从服务器请求的数据。

使用 replication_backlog 中的数据：
- 当从服务器发送 PSYNC 命令时，它会附带自己的复制偏移量（last received replication offset）和主服务器的运行 ID。
- 主服务器会检查 replication_backlog 是否包含从服务器需要的数据。如果包含，主服务器会从 replication_backlog 中读取这些数据，并发送给从服务器。
- 在这种情况下，replication_buffer 不直接参与数据的传输，因为所需的数据已经在 replication_backlog 中。
使用 replication_buffer 中的数据：
- 如果 replication_backlog 中没有从服务器需要的数据（可能是因为从服务器长时间未连接，或者 replication_backlog 太小不足以保存所有数据），则主服务器需要进行全量同步。
- 在全量同步过程中，主服务器会生成一个新的 RDB 文件，并将该文件发送给从服务器。
- 当从服务器加载完 RDB 文件后，主服务器会将之后执行的写命令继续放入 replication_buffer 中，并发送给从服务器。
- 在这个阶段，replication_buffer 会被用来传输从服务器加载 RDB 文件后主服务器产生的新的写命令。

因此，PSYNC 过程中可能会使用 replication_buffer 中的数据，但这通常是在需要进行全量同步的情况下。在部分同步过程中，主服务器会优先使用 replication_backlog 中的数据来满足从服务器的请求。

Redis 数据结构

1.基本数据结构

Redis数据结构源码解析

SDS 动态字符串（C语言字符串不可更改，二进制不安全，不可直接获取到长度）
IntSet （倒叙扩容，只存储整数，唯一有序，二分查找）
Dict 字典（Dict扩容以及收缩过程，rehash 过程）
ZipList 压缩链表（双向链表，记录上一个节点和本节点长度来寻址，查询更新均存在问题）
QuickList （节点为ZipList 的双端链表，控制了ZipList大小，内存空间申请过大的问题）
SikpList 跳表（双向链表，包含多层指针，简单，效率高）
RedisObject

String
- RAW
- EMBSTRING
- INt
List
- LinkedList
- ZipList
- QuickList

在3.2版本之前，Redis采用ZipList和LinkedList来实现List，当元素数量小于512并且元素大小小于64字节时采用ZipList编码，超过则采用LinkedList编码。
在3.2版本之后，Redis统一采用QuickList来实现List：

Set
- Dict (value 统一为Null)
- IntSet（存储的数值为整数，并且数量不超过 set-max-inset-entries 时会使用）
SortSet
- Dict + SkipList

typedef struct zset {
    // Dict指针
    dict *dict;
    // SkipList指针
    zskiplist *zsl;
} zset;

ZSet

Hash
- Dict

网络模型

1.阻塞式IO

什么是阻塞IO？请解释其工作原理。

阻塞IO是指在进行IO操作时，如果IO资源没有准备好（例如，没有可读数据或写入缓冲区已满），程序会一直等待直到IO资源准备好。这种等待过程会阻塞程序的执行，使程序无法继续执行其他任务。

阻塞IO有哪些特点？它在哪些情况下可能导致性能问题？

阻塞IO的特点是程序会一直等待IO操作完成，期间无法进行其他操作。这可能导致性能问题，特别是在高并发场景下。因为每个IO操作都需要独立的线程或进程来处理，当并发访问量较大时，可能会出现线程竞争、线程切换等问题，导致性能下降。

如何解决阻塞IO导致的性能问题？有哪些常见的解决方案？

解决阻塞IO导致的性能问题的方法之一是使用非阻塞IO模型。非阻塞IO模型允许程序在发起IO操作后继续执行其他任务，当IO操作完成后会通知程序。这样可以提高程序的并发性能和响应能力。

另一种解决方案是使用IO多路复用技术。IO多路复用允许一个进程同时处理多个IO请求，通过监听多个IO操作的状态变化，可以在一个线程中同时处理多个IO操作，从而提高了系统的并发性和效率。

阻塞IO和非阻塞IO有什么区别？请举例说明。

阻塞IO和非阻塞IO的主要区别在于程序在等待IO操作完成时的行为。在阻塞IO中，程序会一直等待IO操作完成，期间无法进行其他操作。而在非阻塞IO中，程序在发起IO操作后会立即返回，继续执行其他任务，当IO操作完成后会通知程序。

例如，在Java中，如果使用InputStream的read()方法进行读操作，当没有可读数据时，该方法将会一直阻塞线程，直到有可读数据或读操作超时。而在非阻塞IO模型中，read()方法会立即返回一个结果，即使当前没有可读数据，程序也可以继续执行其他任务。

阻塞IO适用于哪些场景？它在哪些情况下可能不是最佳选择？

阻塞IO适用于简单、低并发的场景，因为在这种场景下，程序可以等待IO操作完成而不必担心性能问题。然而，在高并发场景下，阻塞IO可能不是最佳选择。因为每个IO操作都需要独立的线程或进程来处理，当并发访问量较大时，可能会出现线程竞争、线程切换等问题，导致性能下降。在这种情况下，使用非阻塞IO或IO多路复用技术可能更为合适。

2.非阻塞式IO

什么是非阻塞式IO？请解释其工作原理。

非阻塞式IO是一种IO操作模式，与阻塞式IO相反。在非阻塞式IO中，当程序发起IO请求时，如果IO资源没有准备好，程序不会一直等待，而是立即返回一个结果，并继续执行其他任务。程序可以通过轮询或者使用其他机制来检查IO操作是否已经完成。

非阻塞式IO有哪些优点和缺点？它在哪些场景下可能不是最佳选择？

非阻塞式IO的优点包括提高了程序的并发性和响应能力，因为程序可以在等待IO操作完成时执行其他任务。此外，非阻塞式IO还可以减少线程切换和竞争的开销，从而提高了系统的性能。

然而，非阻塞式IO也有一些缺点。首先，它需要程序自行处理IO操作的轮询和状态检查，这增加了编程的复杂性。其次，如果IO操作频繁且频繁地没有准备好，可能会导致CPU占用率过高，因为程序需要不断地检查IO操作的状态。

非阻塞式IO可能不适用于需要高吞吐量的场景，因为程序需要不断地轮询IO操作的状态，这可能会导致性能下降。此外，如果IO操作之间的依赖关系复杂，非阻塞式IO也可能不是最佳选择，因为它需要程序自行处理这些依赖关系。

如何实现非阻塞式IO？有哪些常见的非阻塞式IO模型？

实现非阻塞式IO通常需要使用操作系统提供的非阻塞IO接口或者高级的IO库。在Unix/Linux系统中，可以通过设置文件描述符为非阻塞模式来实现非阻塞式IO。此外，一些高级的IO库（如Java的NIO库）也提供了非阻塞式IO的实现。

常见的非阻塞式IO模型包括Reactor模型和Proactor模型。Reactor模型是事件驱动模型，它使用一个或多个事件循环来监听文件描述符的事件，并在事件发生时调用相应的处理函数。Proactor模型则是基于完成通知的模型，它使用异步操作来执行IO操作，并在操作完成时通知程序。

非阻塞式IO如何避免CPU占用率过高的问题？

非阻塞式IO可能导致CPU占用率过高的问题，因为程序需要不断地轮询IO操作的状态。为了避免这个问题，可以采取以下几种策略：

使用定时器或延迟机制来减少轮询的频率。
使用高效的IO多路复用技术，如epoll（在Linux中）或IOCP（在Windows中），它们可以更有效地管理多个IO操作，减少轮询的开销。
在轮询期间，如果程序没有其他任务可以执行，可以使用适当的休眠或让出CPU的方式，以减少CPU的占用率。

3.IO多路复用（select poll epoll）

系统如何监控？

当IO操作有变化时，这些函数是通过操作系统的等待队列机制来唤醒的。具体来说，当这些函数进入等待状态时，它会将自己加入到操作系统的等待队列中。这个等待队列是与被监听的IO操作相关联的。

当某个被监听的IO操作状态发生变化时（例如，有数据可读或可写），相应的设备驱动会检测到这个变化，并唤醒与该IO操作相关联的等待队列。由于这些函数之前已经将自己加入到这个等待队列中，因此它也会被唤醒。

一旦这些函数被唤醒，它会检查之前注册的事件集合，确定哪些IO操作的状态发生了变化，并返回这些变化的状态给调用者。然后，程序可以根据返回的状态对相应的IO操作进行处理。

需要注意的是，如果等待超时（即没有IO操作状态发生变化），这些函数也会返回，并报告超时事件。在这种情况下，程序可以选择重新执行这些函数继续等待IO操作状态的变化，或者进行其他处理。

总之，这些函数通过利用操作系统的等待队列机制，实现了在IO操作状态变化时能够被唤醒并通知程序的功能。这使得程序可以在一个线程中同时处理多个IO操作，提高了系统的并发性和效率。

什么是IO多路复用？为什么需要它？

IO多路复用是一种技术，它允许单个线程同时监视多个文件描述符（sockets），以查看它们中的任何一个是否准备好进行读/写操作。这是通过非阻塞IO和事件驱动机制实现的。需要IO多路复用的原因主要是为了解决传统阻塞IO在并发处理时的性能瓶颈，提高程序的并发性和响应能力。

请解释select、poll和epoll的工作原理及其优缺点。

select：select是最早的IO多路复用技术。它通过轮询所有文件描述符来查看是否有就绪的IO操作。select的缺点是当文件描述符数量很大时，轮询的开销会很大，导致性能下降。此外，select还有文件描述符数量限制。
poll：poll是select的改进版，它解决了select的文件描述符数量限制问题。poll使用链表来存储文件描述符，而不是数组，因此可以处理更多的文件描述符。然而，poll仍然采用轮询的方式，当文件描述符数量很大时，性能仍然可能受到影响。
epoll：epoll是Linux特有的IO多路复用技术，它采用了基于事件通知的机制。epoll会监听文件描述符的状态变化，并在状态发生变化时通知程序。与select和poll相比，epoll具有更高的性能，因为它避免了不必要的轮询。此外，epoll还支持水平触发和边缘触发两种模式，可以根据具体场景选择使用。

select、poll和epoll之间有什么区别？在哪些场景下，哪种技术更适合？

select、poll和epoll之间的主要区别在于性能、文件描述符数量限制以及实现机制。在选择使用哪种技术时，需要考虑具体的场景和需求。例如，在文件描述符数量较少且并发量不大的场景下，select可能是一个简单的选择。然而，在处理大量文件描述符和高并发场景时，epoll通常具有更好的性能。此外，还需要考虑操作系统的支持情况，因为epoll是Linux特有的技术。

如何在使用epoll时处理ET（边缘触发）和LT（水平触发）模式？

在使用epoll时，可以选择ET（边缘触发）或LT（水平触发）模式。这两种模式在处理IO事件时有所不同。

ET（边缘触发）模式：在ET模式下，当文件描述符的状态发生变化时，epoll会通知程序一次。这意味着即使文件描述符仍然处于就绪状态，程序也不会再次收到通知。因此，在ET模式下，程序需要负责处理所有待处理的IO操作，并在处理完所有操作后再次等待epoll的通知。
LT（水平触发）模式：在LT模式下，只要文件描述符处于就绪状态，epoll就会持续通知程序。这意味着如果程序未能及时处理所有IO操作，epoll会继续发送通知。因此，在LT模式下，程序可以按需处理IO操作，而不需要一次性处理完所有待处理的操作。

在选择使用ET模式还是LT模式时，需要根据具体的应用场景和需求来决定。一般来说，ET模式更适合处理稀疏的IO事件（即IO事件之间的时间间隔较长），而LT模式更适合处理密集的IO事件（即IO事件频繁发生）。