ET模式与非阻塞IO：高并发编程的关键组合

1. 从一次线上事故说起：ET模式的血泪教训

去年双十一大促期间，我们的订单服务集群突然出现大量连接卡死。监控显示某些Worker进程的CPU占用率飙升到100%，但请求处理量却降为零。紧急回滚代码后发现问题出在新引入的epoll边沿触发（ET）模式——开发同学在切换ET模式时，忘记将对应的socket设置为非阻塞（O_NONBLOCK），导致read()调用在数据未到达时永久阻塞。

这个价值数百万的教训让我意识到：ET模式与非阻塞IO是DNA双螺旋结构般的共生关系。本文将用7个核心问题，带你穿透这个看似简单实则暗藏杀机的技术组合。

关键结论前置：ET模式下必须使用非阻塞IO的根本原因，在于其"通知一次不保证数据量"的工作机制。若使用阻塞IO，当最后一次read()时恰好没有数据，线程将永久阻塞，造成服务雪崩。

2. ET模式的核心特征与底层机制

2.1 水平触发 vs 边沿触发：电子电路中的灵感

epoll的两种模式命名源自数字电路中的电平触发（Level-Triggered）和边沿触发（Edge-Triggered）：

• 水平触发（LT）：只要socket缓冲区有数据，就会持续通知
• 边沿触发（ET）：仅在缓冲区状态变化时通知（空→非空，或非空→更满）

用快递柜类比：

• LT模式：只要柜子里有包裹，每隔5分钟就短信提醒你一次
• ET模式：仅在放入新包裹时发一次短信，取不取、取多少随你

2.2 ET的通知特性带来的编程约束

ET模式有三个致命特性：

1. 单次通知：数据到达后只提醒一次，不管你是否处理完
2. 状态变化驱动：只有从空到非空才会触发，数据变多不触发
3. 饥饿风险：如果一次没读完，剩余数据可能永远无法被处理

这直接导致一个关键结论：必须一次性读完所有数据。而要实现这点，非阻塞IO是唯一选择。

3. 为什么非阻塞IO是ET的救命稻草

3.1 阻塞IO的致命缺陷

假设我们使用阻塞IO+ET模式：

c复制// 错误示范！
int n = read(fd, buf, sizeof(buf)); 

当执行流程如下时：

1. 客户端发送100字节数据，触发EPOLLIN事件
2. 服务端第一次read()读取80字节
3. 服务端第二次read()时，缓冲区只剩20字节但线程想要读100字节
4. 线程阻塞，永远等待那80个不存在的字节

3.2 非阻塞IO的完美配合

正确的做法是设置O_NONBLOCK标志：

c复制fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_NONBLOCK);

配合循环读取：

c复制while((n = read(fd, buf, sizeof(buf))) > 0) {
    // 处理数据
}
if (n == -1 && errno != EAGAIN) {
    // 真实错误处理
}

这种组合能确保：

1. 读到EAGAIN错误时停止，避免阻塞
2. 一次性耗尽缓冲区数据
3. 即使数据分多次到达也能正确处理

4. ET模式的正确打开方式

4.1 标准事件处理模板

一个健壮的ET模式处理流程应包含：

c复制static void handle_event(int fd, uint32_t events) {
    if (events & EPOLLIN) {
        while (1) {
            ssize_t n = read(fd, buf, sizeof(buf));
            if (n > 0) {
                process_data(buf, n);
            } else if (n == 0) {
                close(fd); // 对端关闭连接
                break;
            } else {
                if (errno == EAGAIN || errno == EWOULDBLOCK) {
                    break; // 数据读完
                }
                handle_error(); // 真实错误
                break;
            }
        }
    }
    // 类似处理EPOLLOUT...
}

4.2 必须配套的工程化措施

1. 连接管理：使用非阻塞connect() + EPOLLOUT检测连接完成
2. 写缓冲区：当write()返回EAGAIN时，需要自己维护发送队列
3. 异常处理：对ECONNRESET、EPIPE等错误码要有降级策略
4. 性能监控：统计EAGAIN出现频率，评估缓冲区大小是否合理

5. 深度对比：ET vs LT的性能真相

5.1 性能测试数据对比

我们在同一台机器上测试（8核CPU，10K并发连接）：

5.2 适用场景建议

• 选择ET模式：

  • 高并发短连接（如HTTP API）
  • 需要精确控制事件触发时机
  • 愿意承担更复杂的代码逻辑

• 选择LT模式：

  • 长连接推送服务（如WebSocket）
  • 对开发效率要求高于性能
  • 业务逻辑本身需要多次读取

6. 那些年我们踩过的ET大坑

6.1 经典坑位1：EPOLLONESHOT的误用

有些同学试图用EPOLLONESHOT来解决ET问题：

c复制epoll_ctl(epfd, EPOLL_CTL_MOD, fd, &ev); // 错误！

这会导致事件丢失。正确做法是先重新注册：

c复制epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev);

6.2 经典坑位2：accept()的惊群效应

即使使用EPOLLEXCLUSIVE，ET模式下accept()也可能被多个线程同时调用。必须配合互斥锁：

c复制pthread_mutex_lock(&accept_mutex);
while ((conn_fd = accept4(fd, NULL, NULL, SOCK_NONBLOCK)) > 0) {
    // 处理新连接
}
pthread_mutex_unlock(&accept_mutex);

7. 终极解决方案：更现代的io_uring

虽然epoll+ET性能优异，但Linux 5.1引入的io_uring提供了更好的选择：

1. 真正的异步IO接口，无需维护就绪队列
2. 批处理系统调用，减少上下文切换
3. 支持buffer池和固定文件描述符等高级特性

示例代码片段：

c复制struct io_uring ring;
io_uring_queue_init(32, &ring, 0);

struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
io_uring_prep_read(sqe, fd, buf, len, 0);
io_uring_submit(&ring);

struct io_uring_cqe *cqe;
io_uring_wait_cqe(&ring, &cqe);
// 处理完成事件

不过io_uring的学习曲线更陡峭，对于大多数场景，正确使用epoll ET模式仍是性价比最高的方案。理解"ET必须配非阻塞IO"这一铁律，就是避免灾难的第一步。