从C10K到百万并发：Linux高并发Reactor网络模型实战与调优

如果你用top盯着一台流量突然上涨的服务器，最直观的感受是CPU占用一路飙升，但并发连接数可能才几千。我刚接手一个长连接网关项目时就是这个状态：客户端一多，accept就开始报EMFILE，系统日志里刷满了Too many open files，可单机内存明明还很宽裕。后来我把IO模型从“一连接一线程”改成了Reactor，才真正把连接数的水位从几万拉到几十万，也理解了为什么几乎所有高性能网络库都在讲这个模型。

这篇内容不打算堆概念，而是把一套适合Linux环境下使用的Reactor网络模型从设计、epoll细节、代码骨架，一直聊到内核参数调优和真实踩坑。它适合想搞懂高并发服务器原理的后端开发者，也适合正在做长连接网关、即时通讯、推送服务、IoT接入层的人参考。文章里的代码和配置都是我实际压测环境下用过的，你可以照着搭一份出来。

1. 为什么百万级并发最终选了Reactor

1.1 阻塞式“一连接一线程”到底卡在哪

很多人第一次写高并发服务，最直觉的方案是“每个连接开一个线程”。代码逻辑确实简单：accept到一个连接，就pthread_create启动一个线程，在线程里阻塞读socket。但真正的生产环境一旦连接数上了几千，这个方案就会开始崩。

问题不在CPU计算本身，而在线程上下文切换。一个线程被阻塞在read时，它的内核栈、用户态栈、寄存器现场都要保留；操作系统每次调度都要经历用户态到内核态再到用户态的完整路径。一次上下文切换的耗时通常在5到10微秒，看起来不夸张，但如果系统里有几千个线程在同时抢CPU，每秒切换次数会膨胀到百万甚至千万级别，CPU时间全耗在切换上，真正处理业务的比例会非常低。

更麻烦的是内存占用。线程默认栈大小通常是8MB，即使使用精简栈也要至少数百KB到1MB。算一笔账：想让单机支持10万并发连接，假设每个活跃连接都会占用一个线程，哪怕每个线程栈压到1MB，光是线程栈就是100GB，这还没算内核task_struct、thread_info和信号相关资源。所以“一连接一线程”在C10K时代就被否定了，并不是大家不爱写，是硬资源穷尽之后写不下去。

1.2 C10K到C1000K：事件驱动才是正路

行业里讨论C10K问题时，主流解法是IO多路复用，也就是让一个线程管理成千上万个socket。它的核心思路不再是“忙等某个连接的数据”，而是把socket都注册到一个内核事件表里，由内核告诉我们哪些fd可读、哪些fd可写。

这就是Reactor模型的土壤：事件驱动加上非阻塞IO。Reactor可以拆成两部分看，“反应器”负责等待事件、分发事件；“事件处理器”负责对就绪事件做具体处理。整个过程是：把关心的事件注册进去，然后阻塞等待，一旦有事件就一次性取出，分发给对应的回调。用户代码不再是“我read这个fd直到有数据”，而是“这个fd可读的时候，请调用我的onRead”。

从C10K到C1000K，不是单点性能发生了魔法式提升，而是把等待成本从线程占用量级压缩到了事件循环内部。一个进程能同时持有的文件描述符上限提高到百万级是可能的，但前提是你不能用“一个占用一个线程”的思路去管理它们。

设计选型上，异步IO模型常被拿来和Reactor对比。异步IO（比如Linux AIO）是把读写请求交给内核，完成后通知用户；Reactor是用户自己循环读取非阻塞fd。Linux平台下成熟的异步IO实现比较受限，而epoll配上非阻塞IO，性能和实现可控性都更好。所以主流网络库Muduo、Netty、libevent在Linux上基本都是基于事件驱动的Reactor思路，这不是偶然。

1.3 先认清“百万级并发”的真实含义

我接触过一些项目，把“百万级并发”等同于“百万级QPS”，这是两种完全不同的东西。百万级并发通常指系统能同时维持的连接数量，连接可能大多处于长连接空闲状态；而百万级QPS指每秒能处理的请求数量。一个连接每秒发一条应用层心跳，百万连接可能对应巨大的事件量；但如果是百万个空闲长连接，事件循环大部分时间都在等最小超时。

所以，要让系统承受“百万连接”，首先要明确到底哪些连接是活跃的、哪些是空闲的。如果连接平均每秒一个包，百万连接会带来每秒百万次的事件通知，这会进一步要求用户态处理做到轻量、低拷贝；如果只是养着连接不发数据，资源核心消耗是内存和fd表，CPU压力反而不是最大的。

Reactor能撑住高并发，不是因为它是银弹，而是它把连接与线程解耦，让IO事件和数据处理的资源分配变得可控。接下来的实践都围绕这个前提展开。

2. Reactor核心机制拆解：从epoll到事件分发全链路

2.1 epoll为什么会成为Linux上的主角

Linux下的多路复用接口经历了select、poll到epoll的演进。select有FD_SETSIZE限制，默认只能管理1024个fd；poll虽然去掉了数量上限，但每次调用都要把全量fd集合从用户态拷贝到内核态，内核再线性扫描哪些fd有事件，当fd数量上升到十万时，这个扫描成本是灾难性的。

epoll把复杂度降了下来。它通过epoll_create创建一个epoll实例，内部维护一棵红黑树用于管理注册的fd；epoll_ctl负责添加、修改、删除fd；epoll_wait只返回有事件触发的fd，不再需要每次全量拷贝扫描。性能上，事件发生时内核通过回调把fd放到就绪链表，用户态只需要取走现成就绪的事件。

不过，epoll并不是所有场景都完胜poll。如果你管理的是几百个连接，且每个连接都频繁活跃，epoll的红黑树和回调机制优势并不明显，poll的线性扫描可能更简单。但当连接数达到数万、数十万时，epoll的收益就会非常明显。我们讲百万级并发，技术上默认会把epoll放在核心位置。

给socket设置非阻塞也很关键。Reactor期待的是“事件来了，我马上去读，读不到就算了”，这个逻辑必须配合非阻塞IO使用。如果fd是阻塞的，在读事件回调里执行read就会因为对方刚好没发完整数据而挂住线程，直接拖垮事件循环。所以凡是注册进Reactor的连接socket，都要在accept之后立刻设置O_NONBLOCK。Linux下用accept4可以一步完成，省一次系统调用。

2.2 LT和ET不是玄学，是两种触发哲学

epoll的事件通知有两种模式，水平触发LT和边缘触发ET。LT下，只要缓冲区里还有没读完的数据，内核就会持续通知你“可读”；ET下，只有缓冲区从空变为非空、或者有新数据到来时，才会通知一次。

从写法上看，LT更宽容。你用LT时，即使一次只读一部分，下一轮epoll_wait还会再通知你，不容易漏事件。ET则要求你必须一次性把数据都读出来，一般通过while循环read到返回EAGAIN为止，否则剩余数据可能要等下一次新数据到来才会再次触发，从而造成数据滞留。

我在实际项目里更推荐LT起步。很多人觉得ET性能一定比LT高，其实在epoll的实现里，水平触发只是每次epoll_wait返回时会多检查一次就绪状态，并不会造成数量级差距。瓶颈往往在用户态内存拷贝和业务处理上，而不是这一下触发方式。我见过用ET却一直不读EAGAIN导致CPU飙到100%的例子，这种问题在LT上几乎不会出现。

如果你确实想用ET，有几个条件必须具备：一是fd必须是非阻塞；二是读取要循环到EAGAIN；三是最好配合大块buffer和使用readv分散读，减少系统调用次数；四是对应用层的粘包处理要非常严谨。原生的网络通信协议，比如WebSocket或自定义长度帧，数据未完整到达时，你需要把半包先暂存在用户态缓冲区，等下一个可读事件到达时再拼接。

2.3 一个连接从建立到销毁要经过哪些事件

Reactor把一个连接的完整生命周期拆成若干个事件：

1. 监听socket可读，表示有新的连接请求到达；
2. accept返回新fd，把新fd设置非阻塞并注册到事件循环；
3. fd可读，表示对端有数据到达；
4. fd可写，表示发送缓冲区有空间，可以继续写数据；
5. fd发生对端关闭、错误等异常，需要回收资源。

监听socket通常只注册EPOLLIN事件。accept之后，新连接大概率也会注册可读事件，但写事件不是一开始就注册的，只有send缓冲区积压、需要等fd可写时，才临时注册EPOLLOUT。用完再把写事件摘掉，否则fd在大部分时间可写，会反复触发无意义的写事件，造成“忙轮询”。

事件分发这部分是最考功夫的。Reactor内部会为每个连接维护一个上下文对象，把fd、读缓冲区、写缓冲区、连接状态、回调函数都放在一起。当epoll_wait返回一个就绪事件列表时，事件循环根据事件类型去调用上下文里的对应回调，这个“注册什么就回调什么”的机制，让网络层和业务层解耦得很干净。

我还习惯在连接上下文里保存对端地址、最近活跃时间、收发字节统计等数据。后面做踢掉空闲连接、统计流量、限流时，这些字段都能直接派上用场。

2.4 单线程Reactor、多线程Reactor、主从Reactor如何选

Reactor最基础的形态是单线程事件循环：一个线程里跑epoll_wait，所有连接的读写、accept都在这一个线程里处理。它实现简单，不用考虑加锁，但要求IO回调绝对不能阻塞。只要某个回调里做了耗时的数据库查询或者sleep，整个服务的所有连接都会被拖住。

多线程Reactor是在单线程基础上加入线程池，把耗时的业务逻辑丢到线程池执行。不过需要注意，比如“发送数据”动作不能简单放到工作线程里直接做，因为同一个连接fd可能同时被事件循环线程和工作线程访问，会引入竞争条件。稳妥做法是把需要发送的数据放到连接的发送队列，然后通过事件循环线程统一执行send，或者给每个连接的发送缓冲加锁。

主从Reactor则是把“监听连接”和“处理已建立连接”拆到不同的事件循环里。main Reactor只负责accept新连接，然后把新fd通过一些方式分发给sub Reactor；sub Reactor各自跑独立的事件循环，负责一组连接的读写。这样做的好处是避免大量连接的读写事件和accept事件互相干扰，也能利用多核。

选择哪种要看场景。连接中大量是空闲或轻业务的，单线程Reactor配合线程池即可；连接数大且每个连接有频繁事件、要求低延迟的，用主从Reactor。我做长连接网关时用的是“main+多个sub”的布局：main事件循环只处理监听socket和accept，连接分配使用round-robin策略；每个sub事件循环绑定一个线程，线程数按CPU核心数决定，一般不会超过两倍核数。

3. 动手实现一个高性能Reactor骨架：核心代码与取舍

3.1 一个最小可运行的EventLoop应该长什么样

为了说清楚Reactor的运行逻辑，我用C++11写了一个精简骨架，生产环境直接用会有问题，但核心脉络是完整的。先看EventLoop和Epoller封装：

cpp复制class Epoller {
public:
    Epoller() {
        epfd_ = ::epoll_create1(EPOLL_CLOEXEC);
    }

    void add(int fd, uint32_t events) {
        epoll_event ev;
        ev.events = events;
        ev.data.fd = fd;
        ::epoll_ctl(epfd_, EPOLL_CTL_ADD, fd, &ev);
    }

    void mod(int fd, uint32_t events) {
        epoll_event ev;
        ev.events = events;
        ev.data.fd = fd;
        ::epoll_ctl(epfd_, EPOLL_CTL_MOD, fd, &ev);
    }

    void del(int fd) {
        ::epoll_ctl(epfd_, EPOLL_CTL_DEL, fd, nullptr);
    }

    int wait(epoll_event* events, int maxevents, int timeoutMs) {
        return ::epoll_wait(epfd_, events, maxevents, timeoutMs);
    }

private:
    int epfd_;
};

事件循环的核心是注册回调。用一个Channel类代表一个fd及其关心的读写回调：

cpp复制using EventCallback = std::function<void()>;

class Channel {
public:
    Channel(int fd) : fd_(fd), events_(0) {}

    void setReadCallback(EventCallback cb) { readCb_ = std::move(cb); }
    void setWriteCallback(EventCallback cb) { writeCb_ = std::move(cb); }
    void setErrorCallback(EventCallback cb) { errorCb_ = std::move(cb); }

    int fd() const { return fd_; }
    uint32_t events() const { return events_; }

    void handleEvent() {
        if (revents_ & (EPOLLIN | EPOLLHUP)) {
            if (readCb_) readCb_();
        }
        if (revents_ & EPOLLOUT) {
            if (writeCb_) writeCb_();
        }
        if (revents_ & (EPOLLERR | EPOLLRDHUP)) {
            if (errorCb_) errorCb_();
        }
    }

private:
    int fd_;
    uint32_t events_;
    uint32_t revents_;
    EventCallback readCb_;
    EventCallback writeCb_;
    EventCallback errorCb_;
};

EventLoop注册Channel，调用epoll_wait后分发给对应的Channel：

cpp复制class EventLoop {
public:
    explicit EventLoop(Epoller* ep) : epoller_(ep) {}

    void updateChannel(int fd, uint32_t events) {
        auto it = channels_.find(fd);
        if (it == channels_.end()) {
            channels_[fd] = std::unique_ptr<Channel>(new Channel(fd));
            epoller_->add(fd, events);
        } else {
            epoller_->mod(fd, events);
        }
    }

    void addChannel(Channel* ch, uint32_t events) {
        channels_[ch->fd()].reset(ch);
        epoller_->add(ch->fd(), events);
    }

    void removeChannel(int fd) {
        channels_.erase(fd);
        epoller_->del(fd);
    }

    void loop() {
        const int kMaxEvents = 4096;
        epoll_event events[kMaxEvents];

        while (true) {
            int n = epoller_->wait(events, kMaxEvents, 1000);
            for (int i = 0; i < n; i++) {
                auto it = channels_.find(events[i].data.fd);
                if (it != channels_.end()) {
                    auto& ch = it->second;
                    ch->handleEvent();
                }
            }
        }
    }

private:
    Epoller* epoller_;
    std::map<int, std::unique_ptr<Channel>> channels_;
};

这段代码省略了错误处理，也没有考虑同一个Channel在回调中可能被删除的迭代器失效问题，真实项目要对回调执行做延迟删除保护。但从结构上已经能看出Reactor的运转方式：注册fd与回调，等待事件，按fd分发，调用回调。

3.2 accept与读写的回调怎么组织

监听socket的可读回调是Reactor的“门禁”。当它触发时，要尽可能多地accept，直到返回EAGAIN为止，否则高并发下会有新连接在accept队列里一直得不到处理。

cpp复制void onListenReadable() {
    while (true) {
        struct sockaddr_in addr;
        socklen_t len = sizeof(addr);
        int connfd = ::accept4(listenFd_, (struct sockaddr*)&addr, &len,
                               SOCK_NONBLOCK | SOCK_CLOEXEC);
        if (connfd < 0) {
            if (errno == EAGAIN || errno == EWOULDBLOCK) {
                break;
            }
            if (errno == EMFILE || errno == ENFILE) {
                // 文件描述符耗尽，优先处理，不能在这里直接 break 死循环
                handleFdExhausted();
            } else {
                break;
            }
        }
        // 为新连接分配上下文，注册EPOLLIN事件
        auto conn = new ConnContext(connfd);
        addNewConnection(conn);
    }
}

一个ConnContext大体元素是fd、远端地址、收发缓冲区和状态字段。读事件回调是工作量最大的位置。典型的读逻辑是循环read到EAGAIN，然后把读到的数据交给协议解析器：

cpp复制ssize_t ConnContext::doRead() {
    char localBuf[8192];
    ssize_t total = 0;
    while (true) {
        ssize_t n = ::recv(fd_, localBuf, sizeof(localBuf), 0);
        if (n > 0) {
            inputBuffer_.append(localBuf, n);
            total += n;
            if (!hasCompletePacket(inputBuffer_)) {
                continue;
            }
            handlePacket();
        } else if (n < 0) {
            if (errno == EAGAIN || errno == EWOULDBLOCK) {
                break;
            }
            if (errno == EINTR) {
                continue;
            }
            markClosed();
            return -1;
        } else {
            // n == 0，对端关闭
            markClosed();
            return 0;
        }
    }
    return total;
}

每次读取拿到数据后不要立即处理完整协议，先判断缓冲区里是否有完整包，有的话再解析。这样TCP粘包半包问题能在设计上被天然消化，不需要在底层裸奔处理。比如自定义协议是4字节长度头加消息体，那就在Buffer中检查已有长度是否达到头长度，再判断是否攒齐完整消息体。

事件循环的性能很大程度上取决于doRead写得是否坚决。如果一次read只读一个很小的块就退出回调，那么在高负载场景下LT模式会马上再次唤醒，产生大量无意义的用户态与内核态切换。理想情况是把单次缓冲read循环到EAGAIN，同时控制每次处理的总数据量上限，避免某个连接一次性霸占太长时间。

3.3 把耗时业务交给线程池，但写回必须归队

业务处理不能放在IO线程。比如一个登录请求需要查数据库或者做加密校验，如果直接写在onPacket回调里，一个慢请求就可能阻塞整条事件循环。所以我一般会给Reactor配一个独立线程池，协议解析完成并把请求对象提取出来后，将完整请求作为任务投递到线程池。

线程池代码不复杂，但容易忽略“回写”环节。工作线程解析完请求、生成了响应数据，能不能直接对这个连接fd调用send？这需要小心。如果这个连接注册在某个事件循环线程里，同时工作线程也在操作同一个fd的发送队列，两个线程并发操作就存在数据竞争。

我在工程里习惯把每个连接的发送缓冲加锁，工作线程先把响应写入发送队列并加锁，然后触发一次该连接所在事件循环的任务唤醒。事件循环线程在之后统一执行真正的send操作。这样能避免send被两个线程同时调用导致字节交叉，也不会触发“多线程不经序列化操作同一个socket”的未定义行为。

具体来说，工作线程里的逻辑大致是：

cpp复制void WorkerThread::onRequest(ConnContext* ctx, RequestData& req) {
    ResponseData resp = doBusiness(req);
    ctx->appendResponse(resp);   // 加锁，塞到发送缓冲
    ctx->loop()->wakeup([ctx]() { ctx->flushWrite(); });
}

flushWrite执行时检查发送缓冲，如果还有剩余字节就尝试循环send，一旦fd写缓冲满，就注册EPOLLOUT事件；等可写事件触发后再把剩余数据发出去。这个流程看起来繁琐，但能避免很多诡异的并发bug。我踩过一次工作线程和IO线程同时向fd写数据导致响应乱序的坑，后来全部改成了“只由IO线程发数据”，线上立刻稳定了。

3.4 边界行为清单：每段回调都要处理这些情况

设计回调时，我会强制自己填写一张清单，防止漏处理：

• 对端调用close，本端read返回0，一定要清理连接资源；
• 对端发送RST，read可能返回ECONNRESET，也要清理；
• send时遇到EPIPE，说明对端已经关闭，不能再发；
• 注册事件时fd是否可能已经在其他线程被关闭；
• 连接空闲超过阈值，是否需要发送心跳并主动回收；
• 应用层是否错误使用了非线程安全的缓冲区。

每一条遗漏都可能在高并发下演变成内存泄漏或者进程崩溃。连接对象被回调引用时，尤其要小心悬空指针：如果某个连接在回调执行中被close并delete，而这次回调还在使用它，那就需要用“延迟删除标记”：先把fd从epoll中摘除，把连接标记为deleted，等到事件循环本轮的“清理阶段”再统一释放内存。

4. 单机百万连接的参数调优：系统配置与资源估算

4.1 文件描述符限制是第一个拦路虎

先做一个物理实验：把上面这个Reactor的主机连接数往上推，到了1万个左右，程序可能突然报EMFILE。这个报错不是代码bug，而是系统的进程级fd限制默认只有1024。ulimit -n查出来是1024，对应的服务器最多只能同时打开1024个文件描述符，连接数当然涨不上去。

需要调整的资源限制有两种：

• 用户级nofile软限制和硬限制，通过/etc/security/limits.conf配置；
• 系统级fs.file-max，表示整个操作系统能分配的文件描述符总量。

limits.conf中推荐这样配置：

bash复制* soft nofile 1048575
* hard nofile 1048575
root soft nofile 1048575
root hard nofile 1048575

调完后重启session或重新登录，再用ulimit -n确认。这里把上限设置成1048575而不是1000000，是因为内核和一些库可能会占用部分fd，留一点余量比较安全。

系统级参数用sysctl调整：

bash复制sysctl -w fs.file-max=12000000
sysctl -w fs.nr_open=12000000

注意nr_open是单个进程可分配fd的硬上限，不能小于你希望进程打开的fd数量。还有一个容易被忽略的点：epoll实例本身的fd也计入进程的fd额度，epoll_wait返回一个n很大的数组，也会使用内存，但一般不构成主要压力。

4.2 TCP内核参数：端口、队列与TIME_WAIT

文件描述符限制解决了，连接数继续往上推时会遇到TCP协议栈参数。我会在sysctl.conf里维护一组经验值：

bash复制net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_tw_buckets = 65536
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

somaxconn和tcp_max_syn_backlog解决的是连接建立阶段的问题。服务端listen时传入的backlog如果大于somaxconn，内核会截断到somaxconn。高并发下如果瞬间涌入大量SYN包，accept队列和处理队列不够就会丢连接。一般建议把这两个值调大，且listen传入的backlog和somaxconn保持一致。

ip_local_port_range对服务端监听固定端口来说不是限制，因为服务端不主动消耗本地端口；它影响的是主动发起大量短连接的客户端。如果你的网关要作为上游客户端访问大量下游服务，那么本地端口只有6万多个，上限就是6万多条并发连接，这时要么扩展端口范围，要么用多IP或SO_REUSEPORT分散。

tcp_tw_reuse只对主动发起连接的一方有效。服务端主动关闭连接会产生大量TIME_WAIT，这些连接会占用fd但不能再复用。如果你的协议设计是服务端主动断开，就要重新考虑，或者让客户端主动断开。生产环境我还会关注ss输出中的TimeWait数量，如果持续高于tcp_max_tw_buckets，早期内核会直接丢弃新连接，旧版本内核行为不同，务必结合实际版本观察。

如果你的连接是长连接，还要设置合适的TCP keepalive，防止对端已经崩溃但本端还维护半开连接。Keepalive默认2小时太慢了，长连接网关一般调到60到300秒不等，具体看业务容忍度。

4.3 单机百万连接需要多少内存

这是很容易被忽略的无底洞。并发连接数高，不只是fd数字变大，你为每个连接分配的内存会直接决定整台机器能不能撑住。

默认TCP读写缓冲区其实很大。tcp_rmem典型值和tcp_wmem典型值如果在几十KB到上百KB之间，当一个连接在网络上发送窗口变大后，内核为socket分配的缓冲区会自动扩大。百万连接如果每连接都占用几十KB，那就是几十GB的用量，这还没算用户的ConnContext、发送缓冲、协议缓冲。

在实际调优中需要做三件事：

第一，给用户态连接对象瘦身。ConnContext设计要紧凑，能省则省，一个连接稳定在数百字节到1KB左右比较合理，避免把无用的日志字段、超大Buffer直接放进每个上下文。

第二，申请连接时按需分配缓冲，不要每连接直接塞一个64KB的输入缓冲。先用一个小缓冲，比如2KB到4KB起步，协议需要扩展时再扩容。这样大多数只发心跳的连接不会占太大内存。

第三，评估总账。以100万连接为例，粗略估算：内核文件描述符和epoll相关资源约每个连接1到2KB，用户态每个连接预留1到2KB，再加上一些page cache和线程开销，一台机器至少需要准备8GB到16GB可用的内存，才能比较从容。如果每个连接还要维护应用层业务状态、消息记录，那就要重新算。我压过80万连接，那台机器把大部分非必要服务都关了，内存才勉强够用。

4.4 压测如何看“真百万”而不是“假百万”

压测时最容易犯的错误是用单台客户端去建立100万连接。客户端可用的本地端口最多6万多个，所以无论如何都建不起超过这个量的连接。正确做法是让多个压测客户端分别从不同机器发起，或者使用多网卡IP配合，才能绕过端口限制。

建议先做分层验证。第一层只验证系统承载能力：写一个最小客户端只connect不发送业务数据，让Reactor服务端只accept并注册读事件，观察连接数能否稳定维持在目标水位。第二层再叠加心跳和业务请求，验证CPU和内存是否可接受。这样出了问题也容易定位是系统参数问题还是业务代码问题。

压测过程中稳定关注这几个指标：

• ss -s查看socket总量和TCP连接状态；
• ss -lnt查看listen队列溢出情况；
• ss -ant和cat /proc/net/sockstat核对连接数；
• top和pidstat观察用户态CPU、系统态CPU和单线程CPU分布；
• vmstat观察上下文切换次数；
• netstat -s观察TCP重传、丢包、内存压力等计数。

如果上下文切换次数高得离谱，说明事件循环线程数配多了或者业务处理占用了大量锁。如果system CPU占比高，说明系统调用密集，可以检查是否在循环里频繁做小数据read，考虑合并读取再解析。

5. 高频踩坑实录与排查方法

5.1 惊群问题：多个线程等你一个fd

主从Reactor里如果让多个sub Reactor同时监听同一个listen fd，会出现惊群：一个新的连接到来时，所有线程都被唤醒去争抢accept，但最终只有一个成功，其它线程白白空转。老版本内核这个问题更明显。后来epoll提供了EPOLLEXCLUSIVE，它允许在内核层面让一个事件只唤醒一个等待线程，能有效降低惊群。

我现在的做法更简单直接：监听socket只注册在main Reactor一个线程里，accept完成后，通过负载均衡策略把连接分发到不同的sub Reactor。这样不会惊群，每个sub Reactor内部的事件互不干扰，逻辑上也安全。

SO_REUSEPORT是另一种思路：允许多个进程各自bind同一个端口，由内核做负载均衡分发。它的优势是多个进程可以彻底隔离，一个进程崩溃不会影响另一个。但这个特性会带来连接分布不均和调试复杂度，要在进程粒度使用，不适合线程模型下随意嵌套。

5.2 recv返回0和返回-1必须分清

客户端断开时，TCP会触发可读事件。服务端read可能返回0，表示对端执行了FIN，即正常关闭；也可能返回-1且errno是ECONNRESET，表示对端直接发送RST。很多文档会把两者都写成“断开”，但处理路径完全不同。

正常关闭应该走“四次挥手”流程，可以把剩余缓冲数据清掉后释放连接；收到RST时再继续发数据会触发SIGPIPE并导致进程退出，所以一定要对send返回的EPIPE错误做处理。我一般会在进程启动时忽略SIGPIPE信号，并在所有send路径检查错误码。

另外，epoll的读事件在fd挂断和正常关闭时都可能触发。如果你只判断了EPOLLIN，没有判断EPOLLRDHUP或EPOLLHUP，可能在对方断开后还继续尝试读，状态机变得混乱。现在我的回调开头会统一检查revents中的错误位和挂断位，先做错误处理，再决定是否读。

5.3 ET模式下读不完包就开启死循环

ET模式最容易出现的线上现象是：某个连接的CPU被打满，服务整体卡顿。原因是ET模式下可读事件只触发一次，如果开发者只阻塞读了一次就退出，后续数据哪怕在缓冲区里也不会再触发新事件。于是只能靠其他事件瞎折腾，或者进程内部不断重试，看起来就像忙轮询。

就算程序在反复读，如果没读到EAGAIN就退出，下一次事件触发又被错误消费掉，数据就一直滞留在内核缓冲区，连接等效于饿死。ET的正确读法是while循环，每次读取后如果读到了足够数据就继续读，直到read返回EAGAIN才退出；单次读出上限也要做保护，否则一个高速连接可能饿死同线程其他连接的调度。

我建议团队里的新成员从LT开始写。等理解了水线机制、缓冲区管理，再考虑ET。LT下一次读不完也没有关系，内核会在下一轮继续触发可读事件，状态机清晰很多。

5.4 accept返回EMFILE之后的处理千万不要忽略

连接数到达进程fd上限时，accept会返回EMFILE。如果只简单continue，监听fd会一直处于可读状态，epoll_wait不断被触发，但每次accept都失败，最终导致事件循环忙等，CPU空转，退化成死循环。

经典解法是“先用备用fd占位”。当EMFILE发生时，先关闭一个预先打开的空闲fd，空出一个fd额度；然后再accept一次，这次虽然能成功，但会立刻close掉刚accept到的连接。这样处理之后，再把空闲fd恢复回来。虽然新连接最终还是被关闭，但至少accept队列不会被持续塞满，而真正可用的连接也能正常建立。更简单一点的做法是把连接数监控放到另一个线程，在fd接近上限之前提前拒绝新连接并打日志，留出操作余量。

5.5 回调里处理业务是最大的长尾隐患

Reactor模型最禁忌的是在IO回调中做time-consuming操作，尤其是磁盘IO、数据库访问、第三方远程调用。一次慢查询会阻塞整个事件循环，影响的是后面成千上万个连接，不只是当前连接。

我经历过一个事件：业务代码里直接同步调用了一个外部Redis，Redis偶尔抖动到几百毫秒，随后整个网关的读事件全部排起队，连接大量超时。排查到根因后，把所有第三方调用全部改为异步或放进线程池，并加了超时保护。事件循环里的代码执行时间，必须严格控制到微秒和低毫秒量级，超过这个量级的动作原则上都要丢出去。

如果业务处理必须依赖连接状态，比如要按连接ID路由，那么工作线程投递请求时不能直接传裸指针，而应该传一个连接Id或shared_ptr。连接断开时，事件循环负责把连接从路由表移除，工作线程再访问时要做有效性校验。这类“连接生命周期与业务线程竞争”的问题，在稳定运行一两周后往往会以偶发崩溃的形式爆发出来，最好在架构设计阶段就规避掉。

5.6 我的压测与线上验证方法

最后说下我的调试习惯。先用小连接数跑功能测试，确认单包、粘包、半包、断开重连都正常；再用1万、5万、20万连接逐级增加压测，每上一级先观察系统参数是否异常，再放量。发现异常先查ss -s和dmesg，很多连接问题其实在内核日志里有提示。

压测工具上，wrk适合测HTTP短连接，但对于长连接和自定义协议，我更倾向自己写压测客户端。它可以控制并发连接数、消息频率、心跳间隔，以及连接断开后的重建逻辑。测试过程尽量贴近真实业务模型，因为长连接的心跳频率、单连接上消息量的大小，会直接影响事件循环能支撑的连接数。一百万条空闲连接，和一个连接每秒发一条消息的十万连接，CPU负载完全不是一个量级。

另外，建议把监控埋点放进去：事件循环每次循环耗时、单次epoll_wait返回的事件数、每个连接的平均读耗时、发送队列积压长度。这些数据在线上问题是“慢还是卡”的判断依据。我之前排查一个“连接偶尔全部断开”的问题，就是发现某个事件循环在某一轮epoll_wait返回了上万事件，单轮处理耗时超过500毫秒，导致心跳超过超时阈值被对端断开，后来通过限制单轮处理事件数并在多线程间分散连接解决了。

这套Reactor设计和相关的调优手段，我在这几年迭代了好几个项目。相比最初“一连接一线程”的版本，代码量反而降了，稳定性却明显提升。如果你正在设计一个高并发的Linux服务，可以先从单线程Reactor加线程池入手，把事件循环维持干净，再按需演进到主从Reactor。连接数目标一步步往上调，每个阶段都做压测和观测，百万级并发并不是一个遥不可及的指标，但它考验的是对整个IO链路细节的把控能力。