服务器LT模式选型指南：高并发场景下的ET与LT性能对比
『服务器LT模式选型指南：高并发场景下的ET与LT性能对比』
你是否在搭建服务器时纠结 LT（Level Triggered）与ET（Edge Triggered）模式？这两种I/O多路复用机制的设计差异，直接决定了服务器的并发性能与稳定性。尤其在处理百万级连接时，选错模式可能导致 数据漏读、响应延迟甚至服务崩溃！今天从实战角度拆解两者的本质区别，并给出选型决策树。
? 一、LT与ET的核心差异：从“快递员送包裹”说起
LT模式（水平触发）：
像“耐心快递员”：只要缓冲区有数据（包裹未取完），持续通知程序处理。
✅ 优势：编程简单，允许分批次读取数据，避免阻塞风险。
❌ 劣势：频繁通知增加系统调用开销，低活跃连接时效率低。
ET模式（边缘触发）：
像“一次性通知快递员”：仅当数据从无到有时通知一次，后续需程序自行处理完。
✅ 优势：减少无效通知，高并发场景下性能提升30%+。
❌ 劣势：必须搭配非阻塞IO+循环读写，否则导致数据遗漏。
对比表格：
特性 | LT模式 | ET模式 |
|---|---|---|
触发条件 | 状态持续高电平 | 状态从低到高跳变 |
数据读取 | 可分批 | 必须一次性读完 |
适用场景 | 低并发、通用服务 | 高并发、实时系统 |
⚡ 二、ET模式高效的本质：TCP滑动窗口的隐形推手
为什么ET能提升性能？核心在于它强制程序快速清空缓冲区，从而：
更快更新TCP窗口大小，触发延迟应答机制，减少网络往返次数；
避免发送端因窗口饱和而等待，提升全链路吞吐量。
? 个人观点：ET的高效并非源于通知次数少，而是通过倒逼开发者优化数据读写逻辑，间接激活TCP的流控优化机制！
?️ 三、实战：非阻塞IO的代码实现关键
无论LT/ET，非阻塞IO是基础前提。以下是ET模式的必须操作：
避坑指南：
❗ LT模式：未读完数据时，下次
epoll_wait仍会通知，但建议单次读尽避免频繁触发；❗ ET模式：若未循环读到
EAGAIN， *** 留数据将永远丢失。
? 四、选型决策树：什么场景用LT？什么用ET？
根据百万QPS测试经验，推荐：
选LT若：
连接数<1万，且业务逻辑复杂（如数据库中间件）；
需兼容
select/poll的旧系统。
选ET若：
实时游戏/交易所等超低延迟场景；
长连接推送服务（如WebSocket网关）。
? 独家建议：Nginx、Redis等顶级项目均采用LT模式！并非ET绝对更好，而是LT在稳定性和开发效率上更平衡。
? 五、常见误区：ET模式的“饥饿问题”与解决方案
误区：ET需注册可写事件才能发送数据？
真相：
首次可直接
write，仅当返回EAGAIN（发送缓冲区满）时，才需注册EPOLLOUT事件；发送完成后必须立即注销可写事件，否则CPU空转。
案例：某量化交易系统因未注销EPOLLOUT，导致CPU占用100%！
? 六、架构师决策清单
非阻塞IO是铁律，否则ET模式会阻塞线程；
ET必须配循环读写，LT建议单次读尽；
高并发+可控延迟选ET，通用服务选LT；
监控
epoll_wait调用频次，超过1k/s需优化通知逻辑。
? 终极结论：没有银弹模式！理解业务流量特征，比盲目追ET更重要。