一、LT和ET到底有什么区别假设现在有一个 socketsocket接收缓冲区 ┌────┬────┬────┬────┬────┐ │ A │ B │ C │ D │ E │ └────┴────┴────┴────┴────┘说明这个socket当前“可读”epoll 会通知应用程序这个fd有数据了但是LT和ET通知方式不一样1. LT水平触发LTLevel Triggered 水平触发核心特点只要 fd 仍然处于就绪状态epoll_wait 就可以继续返回这个 fd。例如 socket 中有100字节第一次收到事件以后只读20字节还剩80字节那么下一次epoll_wait();这个 fd 仍然可能继续返回。过程socket中有100字节 ↓ epoll通知 ↓ 应用只读20字节 ↓ 还剩80字节 ↓ 下一次epoll_wait ↓ 再次通知也就是说只要条件一直成立 就会不断提醒这就是“水平”的意思。例如char buffer[1024]; int n read(fd, buffer, sizeof(buffer)); if (n 0) { // 处理数据 }即使一次没有全部读完也没那么危险。因为只要 socket仍然可读下一次 epoll 还会继续通知。2. ET边缘触发ETEdge Triggered 边缘触发关注的是状态发生变化的那一刻例如原来 不可读突然收到数据不可读 ↓ 可读发生了一次状态变化。这时通知一次但是如果第一次事件到来后只读取了一部分100字节 ↓ 读取20字节 ↓ 还剩80字节socket 一直处于可读状态。没有再次发生不可读 → 可读这样的边缘变化。所以可能不会再次通知这就是 ET 最大的区别。因此 ET 通常必须一次把当前数据尽可能读完一直读到EAGAIN例如while (true) { char buffer[4096]; ssize_t n read(fd, buffer, sizeof(buffer)); if (n 0) { // 保存收到的数据 } else if (n -1 errno EAGAIN) { // 当前已经没有数据可以继续读取 break; } else { // 连接关闭或者发生错误 break; } }所以可以简单记LT 有数据没处理完 ↓ 下次继续通知ET 状态变化通知一次 ↓ 这次尽量处理到EAGAIN二、为什么ET通常必须配合非阻塞IO这是 ET 一个非常重要的知识点。假设while (true) { read(fd, buffer, sizeof(buffer)); }目的就是一直读取 直到没有数据但是如果 socket 是阻塞模式可能出现第一次read ↓ 读到数据 第二次read ↓ 读到数据 第三次read ↓ 现在没数据了如果是阻塞 socket第三次read ↓ 线程直接卡在这里 ↓ 等待以后继续有数据那么整个 epoll 线程就可能被这个连接阻塞其他连接即使有事件也处理不了所以 ET 一般需要配合O_NONBLOCK把 fd 设置成非阻塞。例如int flags fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK);这时候如果没有数据read(fd, buffer, sizeof(buffer));不会一直等待。而是返回-1同时errno EAGAIN或者EWOULDBLOCK意思就是现在暂时没有数据了 你可以先去处理别的fd所以 ET 最经典的代码结构就是while (true) { ssize_t n read(fd, buffer, sizeof(buffer)); if (n 0) { // 收到数据 } else if (n 0) { // 对端关闭连接 close(fd); break; } else { if (errno EAGAIN || errno EWOULDBLOCK) { // 当前数据已经读完 break; } // 真正的错误 close(fd); break; } }整个逻辑EPOLLIN事件 ↓ 不停read ↓ 还有数据 ↓ 继续read ↓ EAGAIN ↓ 说明当前内核接收缓冲区已经处理干净 ↓ 返回事件循环因此面试问ET为什么必须使用非阻塞IO可以回答ET 通常要求一次把当前可读数据处理到EAGAIN。如果使用阻塞 socket当数据读完以后继续执行read线程可能阻塞在这个连接上导致整个 epoll 事件循环无法继续处理其他 fd。因此 ET 一般要和非阻塞 I/O 配合使用。三、ET通知少为什么不一定比LT性能更高这是非常容易误解的地方。很多人会想LT ↓ 一个fd可能反复通知 ET ↓ 只通知一次于是得到ET一定比LT性能高这个结论并不严谨。ET 确实有一个潜在优势减少重复的就绪通知例如 socket 中一直还有数据LTepoll_wait ↓ 通知 处理一部分 ↓ epoll_wait ↓ 继续通知ET发生状态变化 ↓ 通知一次 ↓ 一次尽可能处理完因此某些高并发场景中ET 可以减少epoll事件返回次数 用户态/内核态之间的交互次数 重复处理就绪事件的开销但是通知次数少 ≠ 程序一定更快因为整个网络服务器性能还取决于业务处理时间 数据量 锁竞争 内存分配 协议解析 数据库访问 磁盘I/O 线程调度例如一次网络请求epoll通知 ↓ 耗时1微秒但是后面的数据库查询耗时20毫秒这时候LT少通知几次 还是ET少通知几次对整体性能影响可能非常有限。而 ET 的程序复杂度明显更高。必须正确处理非阻塞 EAGAIN 循环读取 半包 粘包 发送缓冲区满 异常连接如果 ET 写错数据没有读干净还可能导致后面一直收不到事件所以工程上并不能简单认为ET高级 ↓ 一定使用ET有些系统宁愿选择LT因为逻辑简单 不容易漏事件 公平性更容易控制 性能已经完全够用面试如果问ET并发性能不是更高吗为什么不用ET可以回答ET 可以减少重复的事件通知在部分高并发场景下能够降低事件通知开销但它并不意味着整体性能一定高于 LT。ET 要求非阻塞 I/O并且一次事件通常需要处理到EAGAIN实现复杂度更高。如果单个连接积压大量数据还可能长时间占用事件循环影响其他连接的响应。对于业务量适中或者更关注代码可靠性和公平性的场景LT 往往已经足够。四、为什么说ET处理“大事件”可能拖慢其他连接这里其实就是你提到的ET处理大事件会阻塞。这个说法需要稍微严谨一点。正确来说不一定是 ET 的 read 被“阻塞”了而是这个 fd 可能长时间占用事件处理线程。假设 epoll 线程同时管理fd1 fd2 fd3 fd4其中fd1突然来了100MB数据同时fd2只有100字节 fd3只有50字节 fd4只有200字节如果使用 ETfd1触发EPOLLIN ↓ 进入while(read) ↓ 一直读 ↓ 一直读 ↓ 一直读 ↓ 直到EAGAIN如果 fd1 当前已经积压大量数据这个while可能执行很多次事件线程可能变成处理fd1 处理fd1 处理fd1 处理fd1 处理fd1 ...而fd2 fd3 fd4虽然已经有事件但只能等待。例如事件循环 fd1 ↓ 读4KB ↓ 读4KB ↓ 读4KB ↓ 读4KB ↓ ...... ↓ 很久以后EAGAIN ↓ 终于开始处理fd2这就是一个大连接长时间占用事件循环也可以称为事件处理不公平或者event loop starvation需要特别注意如果 socket 已经设置O_NONBLOCK那么这里通常不是read系统调用阻塞住了而是应用程序自己在while循环里持续处理同一个fd所以更加准确的说法是ET 为了避免丢失事件通常需要把数据读取到EAGAIN。如果某个 fd 一次积压了大量数据事件线程可能在该 fd 上连续执行大量 read 和数据处理从而长时间占用 event loop导致其他连接的事件得不到及时处理。这也是为什么ET吞吐量可能很好但公平性不一定更好假设一个网络服务器Connection A ↓ 持续高速发送大量数据其他连接B C D E ↓ 只是偶尔发送小请求如果一直A处理到EAGAIN小请求的响应延迟可能反而上升。所以性能不能只看每秒处理多少数据还要看吞吐量 延迟 公平性五、实际项目中LT和ET应该怎么选择如果业务是连接数量不是特别夸张 每个事件处理比较简单 更重视代码稳定性 希望逻辑容易维护使用LT完全没有问题。例如if (events[i].events EPOLLIN) { int n read(fd, buffer, sizeof(buffer)); if (n 0) { process(buffer, n); } }这次没读完下一轮epoll还会提醒代码更容易控制。如果是超高并发网络服务器 大量长连接 事件通知非常频繁 希望尽量减少重复通知可以考虑ET O_NONBLOCK但是需要保证read直到EAGAIN write直到EAGAIN 正确管理发送缓冲区 正确处理半包粘包 避免耗时业务堵塞事件线程一个比较重要的设计思想是epoll线程 ↓ 只做快速I/O而不要epoll线程 ↓ 读数据 ↓ 解析复杂协议 ↓ 查询数据库 ↓ 执行大量计算 ↓ 写文件否则即使 epoll 再快事件线程还是会被业务逻辑卡住更合理的结构往往是epoll线程 ↓ 快速读取网络数据 ↓ 用户态Buffer ↓ 任务队列 ↓ ┌─────────┼─────────┐ ↓ ↓ ↓ Worker1 Worker2 Worker3 ↓ ↓ ↓ 业务处理 业务处理 业务处理这样I/O线程主要负责接收事件 读写socket而耗时业务交给Worker线程执行。对于“大事件”还有一种思路不要在一次事件中做大量业务计算例如ET读数据 ↓ 尽快读到用户态缓冲区 ↓ 不要马上全部解析和处理 ↓ 交给后续任务处理注意这里有个细节ET 下不能只是随便读一点内核数据就直接不管了。因为如果内核缓冲区仍然保持可读却没有再次发生新的边缘变化可能不会重新通知所以常见做法是尽快把socket数据读到EAGAIN ↓ 先存在用户态buffer ↓ 复杂业务处理放到后面如果确实需要对单个连接限制每轮处理量就需要自己增加用户态ready队列 任务调度 重新调度机制而不能简单读一半就返回 然后指望ET再通知一次否则可能漏处理数据。面试官如果问LT和ET有什么区别可以回答LT 是水平触发只要 fd 仍然处于就绪状态epoll_wait就会继续返回该事件所以一次没有把数据处理完问题也不大。ET 是边缘触发只在 fd 的就绪状态发生变化时通知因此一次收到事件后通常需要使用非阻塞 I/O把数据一直处理到EAGAIN否则剩余数据可能得不到新的通知。如果继续问ET通知少并发性能不是更好吗可以回答ET 可以减少重复的事件通知因此在某些高并发场景下会降低 epoll 事件处理开销但不能简单认为 ET 整体性能一定更高。实际性能还受到业务处理、锁竞争、内存、网络和 I/O 等很多因素影响。而且 ET 实现更复杂一旦处理不完整就可能漏事件所以很多业务使用 LT 已经能够满足性能要求。如果继续问为什么有时候不采用ET可以回答一方面 LT 实现更简单可靠另一方面 ET 一次事件通常需要处理到EAGAIN。如果一个连接积压大量数据事件线程可能连续处理这个 fd 很长时间导致其他连接等待影响事件循环公平性和请求延迟。因此是否使用 ET 需要综合考虑吞吐量、延迟、业务复杂度和维护成本。如果问ET处理大事件是不是会阻塞更准确地回答如果 fd 已经设置为非阻塞ET 的 read 本身通常不会因为没有数据而阻塞它会在没有数据时返回EAGAIN。所谓“大事件阻塞”更多是指一个 fd 上积压了大量数据后程序为了读到EAGAIN长时间停留在这个 fd 的处理循环中占用 event loop使其他 fd 得不到及时处理这属于事件循环被长任务占用而不是传统意义上的阻塞 I/O。最后把整个知识链串起来epoll ↓ ┌───────────────┐ ↓ ↓ LT ET ↓ ↓ 水平触发 边缘触发 ↓ ↓ 只要还ready 状态变化通知 就继续通知 一次 ↓ ↓ 逻辑简单 通知次数少 ↓ ↓ 允许分批处理 通常处理到EAGAIN ↓ O_NONBLOCK然后 ET 的核心风险单个fd大量数据 ↓ while(read) ↓ 持续处理同一个fd ↓ 长时间占用event loop ↓ 其他fd延迟上升所以真正选择 LT 还是 ET 时不应该简单判断ET更高级 ↓ 所以一定用ET而应该考虑吞吐量 延迟 公平性 代码复杂度 业务处理时间在很多实际工程里LT 胜在简单可靠ET 胜在减少重复通知但 ET 并不是天然比 LT“并发性能更高”。0voice · GitHub
一、LT和ET到底有什么区别假设现在有一个 socketsocket接收缓冲区 ┌────┬────┬────┬────┬────┐ │ A │ B │ C │ D │ E │ └────┴────┴────┴────┴────┘说明这个socket当前“可读”epoll 会通知应用程序这个fd有数据了但是LT和ET通知方式不一样1. LT水平触发LTLevel Triggered 水平触发核心特点只要 fd 仍然处于就绪状态epoll_wait 就可以继续返回这个 fd。例如 socket 中有100字节第一次收到事件以后只读20字节还剩80字节那么下一次epoll_wait();这个 fd 仍然可能继续返回。过程socket中有100字节 ↓ epoll通知 ↓ 应用只读20字节 ↓ 还剩80字节 ↓ 下一次epoll_wait ↓ 再次通知也就是说只要条件一直成立 就会不断提醒这就是“水平”的意思。例如char buffer[1024]; int n read(fd, buffer, sizeof(buffer)); if (n 0) { // 处理数据 }即使一次没有全部读完也没那么危险。因为只要 socket仍然可读下一次 epoll 还会继续通知。2. ET边缘触发ETEdge Triggered 边缘触发关注的是状态发生变化的那一刻例如原来 不可读突然收到数据不可读 ↓ 可读发生了一次状态变化。这时通知一次但是如果第一次事件到来后只读取了一部分100字节 ↓ 读取20字节 ↓ 还剩80字节socket 一直处于可读状态。没有再次发生不可读 → 可读这样的边缘变化。所以可能不会再次通知这就是 ET 最大的区别。因此 ET 通常必须一次把当前数据尽可能读完一直读到EAGAIN例如while (true) { char buffer[4096]; ssize_t n read(fd, buffer, sizeof(buffer)); if (n 0) { // 保存收到的数据 } else if (n -1 errno EAGAIN) { // 当前已经没有数据可以继续读取 break; } else { // 连接关闭或者发生错误 break; } }所以可以简单记LT 有数据没处理完 ↓ 下次继续通知ET 状态变化通知一次 ↓ 这次尽量处理到EAGAIN二、为什么ET通常必须配合非阻塞IO这是 ET 一个非常重要的知识点。假设while (true) { read(fd, buffer, sizeof(buffer)); }目的就是一直读取 直到没有数据但是如果 socket 是阻塞模式可能出现第一次read ↓ 读到数据 第二次read ↓ 读到数据 第三次read ↓ 现在没数据了如果是阻塞 socket第三次read ↓ 线程直接卡在这里 ↓ 等待以后继续有数据那么整个 epoll 线程就可能被这个连接阻塞其他连接即使有事件也处理不了所以 ET 一般需要配合O_NONBLOCK把 fd 设置成非阻塞。例如int flags fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK);这时候如果没有数据read(fd, buffer, sizeof(buffer));不会一直等待。而是返回-1同时errno EAGAIN或者EWOULDBLOCK意思就是现在暂时没有数据了 你可以先去处理别的fd所以 ET 最经典的代码结构就是while (true) { ssize_t n read(fd, buffer, sizeof(buffer)); if (n 0) { // 收到数据 } else if (n 0) { // 对端关闭连接 close(fd); break; } else { if (errno EAGAIN || errno EWOULDBLOCK) { // 当前数据已经读完 break; } // 真正的错误 close(fd); break; } }整个逻辑EPOLLIN事件 ↓ 不停read ↓ 还有数据 ↓ 继续read ↓ EAGAIN ↓ 说明当前内核接收缓冲区已经处理干净 ↓ 返回事件循环因此面试问ET为什么必须使用非阻塞IO可以回答ET 通常要求一次把当前可读数据处理到EAGAIN。如果使用阻塞 socket当数据读完以后继续执行read线程可能阻塞在这个连接上导致整个 epoll 事件循环无法继续处理其他 fd。因此 ET 一般要和非阻塞 I/O 配合使用。三、ET通知少为什么不一定比LT性能更高这是非常容易误解的地方。很多人会想LT ↓ 一个fd可能反复通知 ET ↓ 只通知一次于是得到ET一定比LT性能高这个结论并不严谨。ET 确实有一个潜在优势减少重复的就绪通知例如 socket 中一直还有数据LTepoll_wait ↓ 通知 处理一部分 ↓ epoll_wait ↓ 继续通知ET发生状态变化 ↓ 通知一次 ↓ 一次尽可能处理完因此某些高并发场景中ET 可以减少epoll事件返回次数 用户态/内核态之间的交互次数 重复处理就绪事件的开销但是通知次数少 ≠ 程序一定更快因为整个网络服务器性能还取决于业务处理时间 数据量 锁竞争 内存分配 协议解析 数据库访问 磁盘I/O 线程调度例如一次网络请求epoll通知 ↓ 耗时1微秒但是后面的数据库查询耗时20毫秒这时候LT少通知几次 还是ET少通知几次对整体性能影响可能非常有限。而 ET 的程序复杂度明显更高。必须正确处理非阻塞 EAGAIN 循环读取 半包 粘包 发送缓冲区满 异常连接如果 ET 写错数据没有读干净还可能导致后面一直收不到事件所以工程上并不能简单认为ET高级 ↓ 一定使用ET有些系统宁愿选择LT因为逻辑简单 不容易漏事件 公平性更容易控制 性能已经完全够用面试如果问ET并发性能不是更高吗为什么不用ET可以回答ET 可以减少重复的事件通知在部分高并发场景下能够降低事件通知开销但它并不意味着整体性能一定高于 LT。ET 要求非阻塞 I/O并且一次事件通常需要处理到EAGAIN实现复杂度更高。如果单个连接积压大量数据还可能长时间占用事件循环影响其他连接的响应。对于业务量适中或者更关注代码可靠性和公平性的场景LT 往往已经足够。四、为什么说ET处理“大事件”可能拖慢其他连接这里其实就是你提到的ET处理大事件会阻塞。这个说法需要稍微严谨一点。正确来说不一定是 ET 的 read 被“阻塞”了而是这个 fd 可能长时间占用事件处理线程。假设 epoll 线程同时管理fd1 fd2 fd3 fd4其中fd1突然来了100MB数据同时fd2只有100字节 fd3只有50字节 fd4只有200字节如果使用 ETfd1触发EPOLLIN ↓ 进入while(read) ↓ 一直读 ↓ 一直读 ↓ 一直读 ↓ 直到EAGAIN如果 fd1 当前已经积压大量数据这个while可能执行很多次事件线程可能变成处理fd1 处理fd1 处理fd1 处理fd1 处理fd1 ...而fd2 fd3 fd4虽然已经有事件但只能等待。例如事件循环 fd1 ↓ 读4KB ↓ 读4KB ↓ 读4KB ↓ 读4KB ↓ ...... ↓ 很久以后EAGAIN ↓ 终于开始处理fd2这就是一个大连接长时间占用事件循环也可以称为事件处理不公平或者event loop starvation需要特别注意如果 socket 已经设置O_NONBLOCK那么这里通常不是read系统调用阻塞住了而是应用程序自己在while循环里持续处理同一个fd所以更加准确的说法是ET 为了避免丢失事件通常需要把数据读取到EAGAIN。如果某个 fd 一次积压了大量数据事件线程可能在该 fd 上连续执行大量 read 和数据处理从而长时间占用 event loop导致其他连接的事件得不到及时处理。这也是为什么ET吞吐量可能很好但公平性不一定更好假设一个网络服务器Connection A ↓ 持续高速发送大量数据其他连接B C D E ↓ 只是偶尔发送小请求如果一直A处理到EAGAIN小请求的响应延迟可能反而上升。所以性能不能只看每秒处理多少数据还要看吞吐量 延迟 公平性五、实际项目中LT和ET应该怎么选择如果业务是连接数量不是特别夸张 每个事件处理比较简单 更重视代码稳定性 希望逻辑容易维护使用LT完全没有问题。例如if (events[i].events EPOLLIN) { int n read(fd, buffer, sizeof(buffer)); if (n 0) { process(buffer, n); } }这次没读完下一轮epoll还会提醒代码更容易控制。如果是超高并发网络服务器 大量长连接 事件通知非常频繁 希望尽量减少重复通知可以考虑ET O_NONBLOCK但是需要保证read直到EAGAIN write直到EAGAIN 正确管理发送缓冲区 正确处理半包粘包 避免耗时业务堵塞事件线程一个比较重要的设计思想是epoll线程 ↓ 只做快速I/O而不要epoll线程 ↓ 读数据 ↓ 解析复杂协议 ↓ 查询数据库 ↓ 执行大量计算 ↓ 写文件否则即使 epoll 再快事件线程还是会被业务逻辑卡住更合理的结构往往是epoll线程 ↓ 快速读取网络数据 ↓ 用户态Buffer ↓ 任务队列 ↓ ┌─────────┼─────────┐ ↓ ↓ ↓ Worker1 Worker2 Worker3 ↓ ↓ ↓ 业务处理 业务处理 业务处理这样I/O线程主要负责接收事件 读写socket而耗时业务交给Worker线程执行。对于“大事件”还有一种思路不要在一次事件中做大量业务计算例如ET读数据 ↓ 尽快读到用户态缓冲区 ↓ 不要马上全部解析和处理 ↓ 交给后续任务处理注意这里有个细节ET 下不能只是随便读一点内核数据就直接不管了。因为如果内核缓冲区仍然保持可读却没有再次发生新的边缘变化可能不会重新通知所以常见做法是尽快把socket数据读到EAGAIN ↓ 先存在用户态buffer ↓ 复杂业务处理放到后面如果确实需要对单个连接限制每轮处理量就需要自己增加用户态ready队列 任务调度 重新调度机制而不能简单读一半就返回 然后指望ET再通知一次否则可能漏处理数据。面试官如果问LT和ET有什么区别可以回答LT 是水平触发只要 fd 仍然处于就绪状态epoll_wait就会继续返回该事件所以一次没有把数据处理完问题也不大。ET 是边缘触发只在 fd 的就绪状态发生变化时通知因此一次收到事件后通常需要使用非阻塞 I/O把数据一直处理到EAGAIN否则剩余数据可能得不到新的通知。如果继续问ET通知少并发性能不是更好吗可以回答ET 可以减少重复的事件通知因此在某些高并发场景下会降低 epoll 事件处理开销但不能简单认为 ET 整体性能一定更高。实际性能还受到业务处理、锁竞争、内存、网络和 I/O 等很多因素影响。而且 ET 实现更复杂一旦处理不完整就可能漏事件所以很多业务使用 LT 已经能够满足性能要求。如果继续问为什么有时候不采用ET可以回答一方面 LT 实现更简单可靠另一方面 ET 一次事件通常需要处理到EAGAIN。如果一个连接积压大量数据事件线程可能连续处理这个 fd 很长时间导致其他连接等待影响事件循环公平性和请求延迟。因此是否使用 ET 需要综合考虑吞吐量、延迟、业务复杂度和维护成本。如果问ET处理大事件是不是会阻塞更准确地回答如果 fd 已经设置为非阻塞ET 的 read 本身通常不会因为没有数据而阻塞它会在没有数据时返回EAGAIN。所谓“大事件阻塞”更多是指一个 fd 上积压了大量数据后程序为了读到EAGAIN长时间停留在这个 fd 的处理循环中占用 event loop使其他 fd 得不到及时处理这属于事件循环被长任务占用而不是传统意义上的阻塞 I/O。最后把整个知识链串起来epoll ↓ ┌───────────────┐ ↓ ↓ LT ET ↓ ↓ 水平触发 边缘触发 ↓ ↓ 只要还ready 状态变化通知 就继续通知 一次 ↓ ↓ 逻辑简单 通知次数少 ↓ ↓ 允许分批处理 通常处理到EAGAIN ↓ O_NONBLOCK然后 ET 的核心风险单个fd大量数据 ↓ while(read) ↓ 持续处理同一个fd ↓ 长时间占用event loop ↓ 其他fd延迟上升所以真正选择 LT 还是 ET 时不应该简单判断ET更高级 ↓ 所以一定用ET而应该考虑吞吐量 延迟 公平性 代码复杂度 业务处理时间在很多实际工程里LT 胜在简单可靠ET 胜在减少重复通知但 ET 并不是天然比 LT“并发性能更高”。0voice · GitHub
