企业官网建设流程全解析

这些年写网络服务，我自己的感受是：只要是处理大量并发连接，最终都会撞到同一个坎上——你在用户态写的那些轮询逻辑，撑到几千连接就开始吃力，到几万连接直接把你CPU烧满。我在做某个长连接推送服务时就被poll坑过一回：连接数爬到一万二，进程的CPU狂奔到百分之百，但吞吐量反而往下掉。后来把核心模块改成epoll，同样的机器，同样的连接数，CPU占用掉到百分之二十几。这篇文章就把那次重构里学到的epoll多路转接细节整理出来，包括它为什么快、LT和ET该怎么选、线程模型怎么搭、内核参数怎么调，以及我后来踩过的几个真实坑。

如果你正在写高并发服务、网关、推送系统、聊天程序，或者只是面试前想把epoll彻底搞懂，这篇应该都能帮上忙。我会尽量把原理讲清楚，也会把可以直接抄的代码片段和参数放出来。

1. 为什么说select/poll的O(N)扫描慢在骨子里

1.1 每次调用都把整个fd集合从用户态拷进内核

先回忆一下select和poll的工作方式。它们本质上干的是同一件事：你把一堆文件描述符交给内核，告诉它“帮我盯着这些fd，哪个有读事件、哪个有写事件，你告诉我”。内核拿到这堆fd之后，逐个去检查每个fd对应的设备或socket是否有事件发生。

这里有个开销很容易被忽略：每一次select或poll调用，你都得把这上千上万个fd的描述信息从用户态内存拷贝到内核态内存。连接少的时候无所谓，连接一旦上万，就算每次拷贝只有几百微秒，在事件密集的网络交互里累积起来也非常可观。而且这个拷贝和事件数量没关系，哪怕这一轮只有一个连接可读，你也得把所有fd全部拷一遍。

更麻烦的是，select的fd集合是用位图表示的，并且有上限，你为了支持更多连接还得自己维护fd编号的稀疏情况。poll虽然改用数组突破了上限，但它依然是“把所有fd全部塞给内核，内核再全部扫一遍”，本质没有变。

1.2 poll真正的瓶颈不在循环，而在无效唤醒

很多文章说select/poll是O(N)复杂度，所以慢。其实单看“扫描N个fd”的循环，在千万级CPU频率下没那么可怕，一万个fd扫一轮也就几十微秒。真正的痛点是另一个——内核扫描完通常只告诉你有事件，但没告诉你是哪几个fd。于是你拿到一个“有事件发生”的总体标记后，还得自己在用户态再遍历一遍那一万个fd，逐一调用类似revents的判断逻辑，才能知道谁的socket可读了。

这一步就是典型的“无效唤醒”：可能这一轮真正有数据的只有3个socket，但你为了找到这3个，把一万个fd全部重新检查了一遍。我在那次推送系统压测时观察过，poll的CPU大头全耗在这种“白跑一趟”的检查上，而不是真正的业务处理。fd越多，浪费越严重，这就是O(N)模型最伤人的地方。

1.3 一张对比表看清三兄弟的差异

把select、poll、epoll放在一起看会更直观：

你从表里就能看出，epoll和select/poll最大的分水岭不是“谁快谁慢”，而是“要不要每次重复做无用功”。select/poll每次调用都在重复全量检查和全量拷贝，epoll则在连接注册之后就不管了，内核通过回调机制主动把就绪事件扔给你。这个架构差异，决定了它们在大规模连接下的命运完全不同。

2. epoll背后那棵红黑树，解决了什么

2.1 epoll_create其实建了一张“关注清单”

我第一次看epoll源码的时候挺好奇：epoll_create到底干了啥？它返回的那个epoll fd到底是啥东西？后来理解了，它在内核里创建了一个独立的事件表结构，这个结构最核心的成员就是一棵红黑树。

红黑树在无锁并发场景下不是最快的容器，但它对“插入、删除、查找”兼顾得很好，最坏情况也是O(logN)。epoll绝大部分时间干的事情就是add、mod、del三种操作——把fd加进关注表、修改关注事件、把fd移出关注表，红黑树恰好每一项都很合适。你在用户态看到的epoll fd，其实就是指向这张“关注清单”的句柄，后续所有操作都通过它来定位。

顺带说一句，现在epoll_create的参数size其实被忽略了，内核会动态扩容，但你传一个合理值也没坏处。别被老文章带偏去纠结size应该设多少，真正的关键在epoll_ctl和epoll_wait上。

2.2 epoll_ctl的add/mod/del在干嘛

epoll_ctl是唯一能改“关注清单”的入口，三个操作对应三种意图：

• EPOLL_CTL_ADD：把一个fd和一个epoll_event结构体绑定，注册进红黑树。内核会为这个fd建立一个epitem节点，节点里保存着你关心的事件类型（EPOLLIN、EPOLLOUT等）以及一个回调函数指针。
• EPOLL_CTL_MOD：修改已注册fd关心的事件。比如你一开始只关心可读，后来处理写事件时把EPOLLOUT也加进去，就用MOD。
• EPOLL_CTL_DEL：从红黑树移除这个fd。注意，一旦连接关闭，内核会自动清理对应节点，但你主动调用DEL更保险，能避免一些fd被误复用后的事件错乱。

我当时犯过一个错误：每次循环都调用ADD而不是先MOD，结果EPERM报得一头雾水。后来才意识到，同一个fd重复ADD会被内核拒绝，而只想改事件时必须用MOD。这个点可以说是最基础也最容易翻车的。

2.3 就绪列表让复杂度从O(N)降到O(1)

红黑树管的是“关注状态”，而真正让你epoll_wait快速返回的是另一条链表——就绪链表。当网卡收到数据、socket状态变成可读时，设备驱动触发回调函数，内核被回调函数把对应的epitem直接塞进就绪链表。注意，这个“塞”的行为发生在事件发生的时机，而不是你调epoll_wait的时机。

所以epoll_wait在用户态看起来就是：内核直接拿出就绪链表里的节点，把对应fd和事件拷贝到用户态的events数组里，然后清空链表。整个过程不用扫描所有fd，复杂度只和实际就绪的连接数量有关。这就像老师在课堂上点名，平时把每个人的答题卡收上来放好，考试时只批改主动举手的那几份，而不是把全班的卡再翻一遍。

理解了这个数据结构，你就能明白为什么epoll适合那些“连接多、但同一时刻活跃连接少”的场景。如果一万个连接大部分时间都没数据，那epoll几乎零开销；而select/poll依然每次跑全量检查，这就是量级上的差距。

3. LT和ET这层窗户纸，捅破没那么玄

3.1 LT模式：只要有剩余就反复告诉你

LT（水平触发）是epoll默认模式，也是select/poll一直以来的语义。在LT模式下，只要fd对应的socket缓冲区里还有没读完的数据，每次调用epoll_wait都会把这个fd放进就绪列表返回给你。哪怕你这次只读了1个字节，剩下的数据下次还会继续通知。

这个模式的优点很直接：不容易丢事件，代码写起来也简单。你读完想读的数据，没读完也没关系，下一轮再读。但它也有代价——你可能被反复唤醒。假如一个异常连接一直有半包数据躺那里，LT模式会让你每次epoll_wait都立刻返回，程序被频繁唤醒去处理一个根本处理不动的连接，CPU就这样被白白消耗。

我自己的看法是：LT模式适合业务逻辑复杂、读多读少控制不好的场景。比如你在一个框架里接了很多人的代码，别人可能读一半就不读了，LT至少保证事件不会凭空消失。新手上来先用LT，系统运转起来再谈优化。

3.2 ET模式：只在状态变化时通知一次

ET（边缘触发）模式就完全不同了：它只在socket状态发生“从无数据到有数据”“从不可写到可写”这类跳变时通知一次。用大白话说，它按“边沿”触发，而不是按“电平”触发。如果这一轮你只读了一半数据，下一轮没有新数据进来，内核就不会再通知你，剩余数据会一直躺在缓冲区里没人管。这时候你只能自己保证“读就读干净，写就写到完”。

所以ET模式下你必须用while循环读socket，直到read返回-1并且errno等于EAGAIN，才算把当前所有数据全部取完。写数据时同理，要循环write直到写完或返回EAGAIN，否则数据没发完你也等不到下一次通知。这个while循环和EAGAIN判断是ET模式里最核心的套路，漏掉任何一个，程序就可能在低流量时一切正常，高流量时突然丢数据或卡死。

3.3 按业务场景选型，别为了ET而ET

要不要用ET，我的建议是：看你能否控制好每个连接的读写逻辑。我自己在推送服务里用的是ET，因为长连接数据到达频率不高，每次到达就希望一次处理完全部数据，减少无谓的唤醒次数。用ET之后，epoll_wait返回的次数明显下降，CPU占用也降了一些。

但如果你写的是HTTP这种按行读取、分包边界复杂的协议，LT反而更省心——你可以在处理好当前数据后再继续读，不用担心读多读少影响后续通知。当然，ET也能处理这种场景，但代码要格外小心，每一次边缘事件都要对应一次完整的应用层处理流程。说实话，很多人把ET当性能标签来追，我觉得没必要。一个事件通知机制不会因为你选了ET就快一个量级，真正的性能大头在业务处理和非阻塞IO的使用上。

4. 多路转接之后的线程模型怎么搭

4.1 单线程Reactor先跑通再说

epoll本身是事件驱动机制，它不负责并发，真正把“多路转接”撑起来的是它外面那层线程模型。最简单也最经典的，是单线程Reactor：一个线程里跑epoll_wait循环，拿到就绪事件后，直接在当前线程里执行对应的读写和业务处理逻辑。

这个模型的优势在于代码简单，没有锁竞争，不会有死锁问题。如果业务逻辑很轻量、每个连接的数据包不大，单线程其实能扛住很不错的QPS。我的经验是：如果是纯转发、纯心跳、纯短消息这类简单业务，单线程Reactor可以扛好几万连接，瓶颈往往在网络带宽或者对方的处理速度上。它的天花板不在epoll，而在单线程内连续处理大量计算密集型任务时，事件响应会被拖慢。

4.2 主线程listen，worker线程干活的经典分工

业务稍微复杂一点，比如每个消息要查库、做过滤、转码，单线程的响应延迟就会膨胀。这时我推荐的主从Reactor模型是：主线程只负责accpet新连接和处理就绪事件的分发，把真正耗时的业务操作丢给worker线程池。

worker线程池通常不是用一套epoll，而是通过一个线程安全的任务队列接收“就绪fd + 事件类型”。主线程epoll_wait到事件后，把任务塞给队列，线程池中的空闲worker取走并处理。这种模型的妙处在于：epoll循环永远不被阻塞，即使某个worker处理逻辑再慢，也只是某个连接的处理延迟变大，不会拖累所有连接的监听。

要注意的点是任务队列要有界，并做好背压。我当时用的队列上限是2万，满了之后主线程就短暂放弃分发、继续等下一轮epoll事件，相当于给下游一个喘气的机会。不然主线程无脑往里塞，内存很快会被堆积的任务打爆，那是另一种事故。

4.3 连接惊群和EPOLLEXCLUSIVE

如果你的服务是多个进程或线程各持有一个epoll实例，同时监听同一个监听fd，就会遇到惊群问题：一个连接进来，所有进程都被唤醒，但只有其中一个能accept成功，其他人白白空跑。Linux早期对accept加过锁来避免一点惊群，但多进程epoll_wait的惊群问题依然存在。

解决办法有两个方向。一是所有进程共用一个监听fd，但只有主进程调用accept，再把已连接的fd分发给worker进程。二是利用EPOLLEXCLUSIVE这个标志，在多个进程共同监听同一个fd时，内核只会唤醒其中一个等待者，从根源上减少无谓唤醒。这个标志在较新的内核版本里已经支持，使用方式就是在events里加上它。

另外还有SO_REUSEPORT思路，它允许多个进程各自bind同一个端口，连接请求由内核负载均衡分发到不同进程，每个进程只有一个epoll实例监听自己那个Socket。这种方式在极端高并发场景常见，但要注意设置之后连接并不保证均匀，编程模型也会更复杂，一般先不用动它。

5. 调优时真正值得动的几个内核参数

5.1 文件描述符上限：ulimit里的坑

很多人一上来就调fs.file-max，其实那是系统层面的总上限。单进程能打开的fd数量由ulimit -n限制，默认通常只有1024，高并发服务跑起来后没一会儿就EMFILE报错。

我当时的做法是：先在启动脚本里ulimit -n 655350，然后确认/etc/security/limits.conf也同步允许这个数值。还要留个心眼，特权的进程和普通用户进程的取值路径不完全一样，调试时最好打印一下进程实际拿到的RLIMIT_NOFILE，别只看shell里显示的值。一个服务如果fd不够用，epoll就谈不上多路转接，这是最基础的约束条件。

5.2 TCP队列参数与连接建立速度

连接建立阶段其实也有隐藏的队列瓶颈。内核为每个监听socket维护两个队列：半连接队列（SYN队列）和全连接队列（accept队列）。如果accept队列满了，内核会直接丢弃新到的连接请求，而你的程序却浑然不知，外面看起来就像“连不上”。

可以用ss -lnt查看Send-Q和Recv-Q观察这两个队列的占用状态。如果发现堆积，可以检查这几个参数：net.core.somaxconn控制全连接队列最大值，默认128太小；net.ipv4.tcp_max_syn_backlog控制半连接队列，在SYN Flood防护策略下也可能排队。同时，listen的第二个参数backlog也要传一个匹配的值，程序侧和内核侧是叠加的关系，光调一边效果有限。

5.3 epoll_wait的events数组和timeout怎么设

代码层面，epoll_wait返回的events数组大小是一项常见调参点。如果数组开得比实际就绪事件数小，内核会把剩余事件留在就绪链表里，下一轮继续返回，效率会下降。我当时扫描就绪事件的平均量之后，把events数组开到了512，接近实际峰值，多数情况下一次调用就能取完。

timeout参数也别随手写死。写-1表示永远阻塞，适合纯事件驱动模型；写0表示非阻塞轮询，适合配合游戏循环或定时器跑批；写一个有限值，适合要在同一线程里顺手做其他周期性任务。我一次线上故障就是因为把timeout设成2000毫秒，定时任务每次要等最多2秒才能被触发，表现成“延迟忽高忽低”。后来改成50毫秒，调度响应立刻正常了，CPU开销也完全可接受。

6. 从实战踩坑里总结的几条铁律

6.1 ET模式下读空导致饿死

这个坑特别典型：ET模式下，某次边缘事件触发后我用while循环读socket，但循环退出条件写成了read返回0，也就是只处理“对端关闭”的情况。结果只要对方连续发两个数据包，第一个包读完，第二个包还能读到数据，read不返回0，while就继续读，直到把已经收完的数据读完，下一次read阻塞——当时还没把socket设成非阻塞，整个线程直接卡死。排查时核心线程莫名其妙不再处理任何事件，gdb一挂上去才发现阻塞在读调用上。

正确的写法是：先设置O_NONBLOCK，然后while里read，当返回值小于0且errno为EAGAIN时退出。这个EAGAIN承载的语义很明确：内核缓冲区目前已无数据，你该把控制权还回去了。ET模式的所有读操作都得按这个模板来，没有任何例外。

6.2 EPOLLIN与EPOLLOUT同时注册的误区

我见过不少人在一个连接的events里同时加EPOLLIN和EPOLLOUT，想当然地以为这样读和写都能及时处理。但实际上，如果你一直注册EPOLLOUT，而连接对应的发送缓冲区一直是空的，内核极大概率会认为“可写事件一直存在”，结果是epoll_wait几乎每次都返回这个fd的EPOLLOUT事件。这时候程序会在一个没有写需求的连接上反复被唤醒，白白空转，严重的能把CPU消耗到接近满负载。

正确思路是：平时只注册EPOLLIN，等有数据要发给对端时，再用EPOLL_CTL_MOD临时把EPOLLOUT加进去。等写事件触发后，你往socket写入数据，写完之后再把写事件摘掉。这样EPOLLOUT只在你真正需要“能写”的时候才起作用，唤醒次数大幅下降。

6.3 accept要用while循环；EPOLLHUP和EPOLLERR必须处理

用LT模式accept时，一个很经典的低效场景是只accept一个连接就回到epoll_wait。因为LT模式下只要监听fd还有新的连接未处理，epoll_wait会立刻再次返回，如果你一次只accept一个，高并发新连接到达时就会陷入过长循环，同时还可能饿死其他事件。正确做法是while循环里反复accept直到返回EAGAIN，将当前积累的连接尽量一次处理掉。ET模式下更是必须这样写。

另外，EPOLLHUP和EPOLLERR这两个事件也经常被新手忽略。它们不是正常的读或写事件，却经常伴随异常连接出现。比如对端突然拔网线，或TCP收到了RST，你只监听EPOLLIN时这类状态不会触发读，但EPOLLHUP会被置上。我看到很多回调里只判断EPOLLIN、EPOLLOUT两种情况，导致连接状态异常后永远得不到清理，连接数越积越多。所以处理事件的代码一定要把EPOLLERR和EPOLLHUP单独列出来，并执行关闭、释放资源、打日志的动作，不然线上网关很容易出现内存缓慢上涨的“温和事故”。

最后也说个我最近的习惯：可以在epoll_event的data端放一个轻量的结构体指针，把连接上下文、上次活跃时间、协议解析状态都挂在fd上。多路转接只是帮你“发现可读写的fd”，真正的高并发服务质量，考验的是你在拿到fd之后怎么高效地管理别人的连接生命周期。这个习惯帮我省了不少事，尤其在排查连接泄漏和半包粘包问题时，关联信息随手就能拽出来，不需要再维护一长串映射表。