从Reactor模型到百万并发：Linux高并发网络编程实战指南

前段时间在优化一个内部网关服务时，核心节点扛到了 80 万左右的并发连接，距离百万级只有一步之遥。压测过程中反复折腾 epoll 参数、线程模型和内存分配，让我对 Linux 下高并发网络编程有了非常具体的认知。趁热把这段实践梳理成文，重点聊聊 Reactor 网络模型的演进思路，以及真正跑到百万级并发时那些藏在细节里的坎。

如果你正在做 Linux 服务端开发、技术选型，或者准备面试被问到底层网络模型，这篇文章应该能帮你少走不少弯路。内容偏实践，我会尽量讲清楚每个决策背后的“为什么”，也会把踩过的坑直接摆出来，供你参考。

1. 一上来就接百万并发？先搞清楚瓶颈在哪

很多新手第一次听到“百万级并发”时，第一反应是“调大 backlog、改个 ulimit 不就完事了”。但实际压测下来你会发现，真正卡住你的根本不是连接数本身，而是连接建立之后的 IO 分发效率、内存占用和内核参数是否匹配。

1.1 并发连接和并发请求其实是两码事

先理清一个关键概念：百万并发连接是指同一时刻服务端维持了 100 万个 TCP 连接（大部分处于 idle 状态），而百万并发请求（CPS，每秒新建连接数或 QPS）是指每秒钟处理 100 万个业务请求。这两者在工程上的难度完全不同。

举个例子，长连接场景下客户端连接上来后，可能几十秒甚至几分钟才发一个心跳包。这时百万连接对 CPU 的压力很小，真正消耗的是文件描述符和内存。而如果是高频 RPC 调用，每秒钟有上百万次数据读写，压力就集中在事件分发、线程切换和业务处理上。咱们说的“百万级并发”，绝大多数时候是前者，也就是维持海量连接，同时保证活跃连接的处理能力足够快。理解这一点，才能明白为什么 Reactor 模型能成为高并发网络库的主流选择——它本质上是解决“IO 事件如何高效分发”的问题。

1.2 传统多线程模型的致命缺陷

如果你用 Java 或 C++ 写过传统的 BIO 服务，大概见过这种代码：每个连接来了就 new 一个线程，线程里阻塞读数据。

这种模型的痛处很明显：

• 线程是昂贵资源。一个线程默认栈空间 8MB（虚拟内存），100 万连接如果全部用阻塞线程处理，光线程栈就占 8TB 虚拟地址空间，物理内存也扛不住上下文切换。
• 阻塞 IO 导致线程大部分时间在瞎等。连接没有数据时，线程阻塞在 read 上，CPU 空转，资源利用率极低。
• 线程切换成本随数量增加急剧上升。系统调度 100 万个线程，光切换开销就能把 CPU 烧干。

有人可能说，那用线程池限制数量，每线程处理多个连接行不行？可以，但前提是这些连接必须是非阻塞的，而且你得有办法知道哪个连接可读了。这就引出了 IO 多路复用和 Reactor 模型。

2. Reactor 网络模型的设计演进

Reactor 翻译过来叫“反应器”，核心思想是通过一个或多个派发器，把就绪的 IO 事件分发给对应的事件处理器。简单理解：它就像一个前台接待员，宾客来了先登记，等有具体需求再叫对应的工作人员处理，而不是每个宾客雇一个专属服务员死等。

2.1 从单线程到主从多线程的演进

Reactor 模型在工程落地中经历了三个阶段，每个阶段都是针对明显的瓶颈做优化。

单 Reactor 单线程模型是最简单的一种：一个线程同时负责 accept 新连接、读取请求、分发业务。这个模型在 Redis 这类纯内存操作场景能工作得很好，但一旦业务里有一点耗时 IO，比如查数据库或调远程服务，整个事件循环就被卡住了。因为单线程串行处理事件，一个慢任务会阻塞所有其他连接。

单 Reactor 多线程模型把业务处理从 IO 线程中分离：Reactor 线程仍然负责 accept 和读写，但读到的数据被丢进业务线程池处理，反应器线程不等待业务结果，继续处理其他连接的事件。这样解决了“一个慢业务拖垮所有连接”的问题，但新连接的 accept 和现有连接的读写仍然由同一个 Reactor 线程承担，在极端情况（每秒新建数万连接）下依旧有瓶颈。

主从 Reactor 多线程模型是目前大型服务端的主流：mainReactor 线程只负责监听 listen fd，accept 新连接后把连接注册到某个 subReactor 上。subReactor 线程负责维护自己名下连接的读写事件。每个 subReactor 都有自己的 epoll 实例，事件分散到多个线程，既利用了多核，也避免了单个反应器过载。

像 Netty 的 boss/worker 线程组、Redis 6.0 之后的多 IO 线程（虽然实现的不是完整主从，但思路相近）、muduo 的多线程版本，本质都是这个套路。

2.2 Reactor 各模型优缺点对比

用一张表把三种模型的思路和瓶颈对比一下：

2.3 说句实在话：大多数场景别重复造轮子

虽然这篇文章在拆解 Reactor 模型如何工作，但我必须先泼一盆冷水：现代服务端编程，能直接用 Netty、libevent、libuv、muduo、Boost.Asio 就别自己从零撸 Reactor。这些库经过了多年的生产环境验证，对各种边界情况的处理远比你两周时间写出来的代码稳健。

我自己曾在一个嵌入式网关上手动实现过一次 Reactor 核心，原因是目标平台的 libevent 版本太老且不容易交叉编译。那次经历让我深刻理解到：理解模型和手写模型是两码事。但后来到了通用 x86 服务器上做高并发网关，我依然选择了 libevent 和自研状态机框架的组合，而不是纯手写事件循环。这就是工程决策：要可控的关键路径自己写，通用的网络事件库让专家帮你踩坑。

3. epoll 才是百万级并发的基石

Linux 上实现 Reactor 模型几乎绕不开 epoll。它和 select/poll 有着本质区别——select/poll 每次调用都要把全部 fd 从用户态拷贝到内核态，内核线性扫描找出就绪事件，O(n) 复杂度在 fd 数量过万后就会出现明显性能拐点。而 epoll 通过三个系统调用和三个关键数据结构解决了这两个问题。

3.1 epoll 的三种触发模式与事件分发语义

用大白话解释 epoll 的工作原理：你在内核里维护一棵红黑树，所有需要监听的 fd 挂在这棵树上，同时每个 fd 关联一个就绪队列。当 fd 上有事件发生时，内核回调把它加入就绪队列；用户态调用 epoll_wait 时，只把就绪队列里的 fd 拷贝出来，复杂度 O(就绪数)，而不是 O(总连接数)。

epoll 的事件分发支持两种触发模式：

• 水平触发（LT）：只要 fd 上有未读完的数据，每次 epoll_wait 都会返回它。不容易漏事件，但如果你读得慢，同一个 fd 会被反复返回，可能造成 busy loop。
• 边缘触发（ET）：只有 fd 状态发生变化（从无数据到有数据）时才会通知一次。高效但要求你一次把数据尽量读干净——通常要循环 read 到返回 EAGAIN 为止。配合 non-blocking IO 使用，能有效减少无谓的系统调用。

在实际工程中，处理 TCP 数据流时有个经典做法：数据到达后不要在事件回调里一点点读，而是尽量多读几次，用应用层缓冲区把数据攒起来，解析完一个完整协议包再交给业务线程。LT 模式逻辑简单不容易错，是绝大多数项目的第一选择；ET 模式更适合追求极致性能且能保证 read 到 EAGAIN 的专家级开发者，我早期在项目里用 ET 吃过一次大亏——因为没处理好半包，导致某个 fd 的数据一直停在内核缓冲区，事件不再触发，连接假死。后来切回 LT 加应用层缓冲，虽然每次多一次系统调用，但稳定性大幅度提升。记住：先正确，后高效。

3.2 系统调用参数里的工程经验

epoll 的使用有几个关键参数和容易被忽略的细节：

首先是 epoll_event 结构里的 events 字段。处理 TCP 连接时，你不仅需要注册 EPOLLIN（可读）和 EPOLLOUT（可写），还要显式注册 EPOLLRDHUP（对端关闭连接）或依靠 EPOLLERR 来感知错误。如果不处理这些异常事件，某些 TCP 半关闭场景会让你的连接意外泄漏。建议统一注册 EPOLLIN | EPOLLOUT | EPOLLRDHUP，同时在业务层做心跳超时来兜底清理死连接。

其次是 epoll_wait 的 maxevents 参数。很多人图稳妥把它设成和最大并发数一样，比如 100 万，这是个馊主意。单次 epoll_wait 返回的事件数组本身就有内存需求，100 万个 event 数组就需要 1200 万字节起步（每个 event 12 字节）。实际事件不会那么密集，建议给 1024 或 4096 就够了，遍历完再重新进入 epoll_wait，事件不会丢失，只是多一次内核态切换而已。

还有人反复纠结 epoll_wait 的 timeout 参数该设多少，如果你的主线程除了 epoll_wait 之外不需要做周期任务，设 -1（永久阻塞）能获得最低的 CPU 空转率；但如果你有定时器任务（比如心跳超时扫描）要跑，可以设一个 50~200ms 的值，不要设太短，否则主循环空转，CPU 占用会上去。

3.3 边缘触发与多线程惊群

实现主从 Reactor 多线程时，一个隐藏较深的问题是 accept 惊群。旧版本内核里多个线程同时调 epoll_wait 监听同一个 listen fd，一个新连接到了，内核会唤醒所有等待线程，但只有一个线程能成功 accept，其余线程白白空跑一圈。

Linux 2.6 之后内核已经解决了 accept 本身的惊群问题（新连接只唤醒一个等待者），但如果你用多个 subReactor 分别持有一个同一 listen fd 的 epoll，2.6 到 4.5 版本之间的内核在事件发生时会唤醒所有等待的 epoll，这就是 epoll 层面上的惊群。解决办法有两个：

• 使用 SO_REUSEPORT：每个 worker 单独 bind 同一个端口，内核在底层做负载均衡，从源头避免共享 fd。
• 用 mutex 或原子标记保护 accept 操作：只有拿到锁的线程才执行 accept，其他线程继续等待。

我用 SO_REUSEPORT 比较多，一方面减少惊群，另一方面天然实现了多核负载分担。但要注意：使用 SO_REUSEPORT 后连接在多个 socket 之间的分布是内核 hash 决定的，某些场景下可能出现不够均匀。如果你希望某个客户端永远打到同一台 worker（有状态），还需要在应用层做一致性 hash，而不是依赖内核的随机分发。

4. 实现百万连接的运行期参数调优

模型选型做好后，真正的战场在操作系统参数。一个默认配置的 Linux 系统，连 10 万连接都撑不起来——这既包括 fd 数量的硬限制，也包括 TCP 协议栈和内存分配的诸多隐藏约束。以下参数是我在多次压测中验证过比较有效的调优区间。

4.1 用户态和内核态的 fd 限制

文件描述符是第一个硬门槛。Linux 默认的 ulimit -n 是 1024，这意味着一台机器只能开 1024 个 socket。想支撑百万连接，必须同时调整用户态限制和内核态限制。

首先是用户态限制：

• 临时生效：ulimit -n 1048576，只对当前 shell 及其子进程生效。
• 永久生效：编辑 /etc/security/limits.conf，加入：

  code复制* soft nofile 1048576
  * hard nofile 1048576
  

内核态还需要调整 fs.file-max，它决定整个系统能打开的文件总数上限，仅靠 ulimit 提高是不够的：

bash复制sysctl -w fs.file-max=2097152
# 持久化到 /etc/sysctl.conf
echo "fs.file-max=2097152" >> /etc/sysctl.conf

值得注意的是，每个 TCP socket 在内核里还有一个文件对象和对应的内存开销。我实测下来单个 idle 的 TCP 连接在内核里大约占用 3~5KB 内存（主要来自 socket buffer 和 inode 结构），100 万连接意味着光内核态就要预留 3~5GB。这还只是 idle 状态，如果每个连接有收发缓冲，内存开销会更大。所以做百万连接压测前，先算清楚机器的物理内存：

估算公式：总内存占用 ≈ 连接数 × (单个连接内核开销 + 应用层读写缓冲区 + 业务状态对象)。

在 64GB 内存的机器上跑 100 万连接，光内存预留就占掉近 10GB，这部分物理内存必须提前规划，别和其他业务共存一台机器，否则大概率出现内存抖动。

4.2 TCP 协议栈的关键调优点

TCP 层有大量参数直接影响能否维持百万级长连接。下面几个是我压测中调整最多、收益最明显的：

其中两个参数我要专门提示一下：

tcp_tw_recycle 是坑中之坑。早期一些优化教程会推荐开启它来快速回收 TIME_WAIT 连接，但对服务端来说，这个参数在 NAT（网络地址转换）环境下会引发严重问题：它根据时间戳判断连接是否可复用，而 NAT 后面不同设备的 timestamp 可能产生错乱，导致部分新连接被内核直接丢弃。实际生产中，我从未在服务端开启过 tcp_tw_recycle，如果 TIME_WAIT 太多，优先检查是不是服务端主动关闭连接太频繁，这个问题要从应用层解决。

tcp_keepalive 的默认参数要等 2 小时才开始探测，对百万连接来说太慢了——很多客户端异常掉线后你以为连接还在，结果对象渐渐就成了半开连接。把 tcp_keepalive_time 调到 600 秒是相对稳妥的范围，但更可靠的做法还是在业务上做心跳包：每 10~30 秒由客户端发一次业务心跳，服务端连续 3 次没收到就主动断开。内核 keepalive 作为兜底就好，因为默认时间太长，发现死连接太慢，会导致资源泄漏累积。

4.3 百万连接的内存预算实战计算

假设我们要支撑 100 万纯长连接客户端，每个客户端平均每 30 秒发送一个心跳包，我们规划一下服务端的内存占用：

• 每个 TCP 连接在内核态占用：约 4KB（socket 结构 + inode + 缓冲区基础预留）。
• 每个连接的应用层读写缓冲区：如果按 4KB + 4KB 预分配，那就是 8KB。
• 应用层连接状态对象：比如记录对端地址、最近活跃时间、协议状态机等，按 512B 算。
• fd 关联的用户态事件结构：按 256B 估算。

总计每个连接约 13KB，100 万连接就是 13GB。如果你还需要保留更大的应用层缓冲（比如待发送队列堆积），很容易涨到 20GB 甚至更高。所以，百万连接意味着什么？它不只是“打开 100 万个 socket”的考题，更是“你能否为每个连接建立合理且精简的内存模型”的考题。很多团队做百万连接压测挂掉，根本不是程序逻辑问题，而是内存被打满后触发了 OOM Killer。

4.4 单进程够不够？多进程如何协同

当连接数到百万级时，事件循环线程（subReactor）数量通常等于 CPU 核数或 2 倍核数。如果核数太多，超过 16 个线程后，每个线程的 epoll 实例维护的 fd 数量依然巨大，锁竞争和 CPU 调度也会让收益递减。我实测的一个直观数据：在 32 核机器上，subReactor 数量从 8 调到 16，收益明显；从 16 调到 32，几乎无提升。原因在于：真正活跃的连接占比不高，epoll_wait 返回的事件数量有限，瓶颈转移到了业务线程池的吞吐上。

多进程模式和单进程多线程模式的选择，更值得聊一聊。如果业务是无状态的，比如纯转发网关，优先考虑多进程 + SO_REUSEPORT，每个进程独立一个 mainReactor 和 subReactor 集合，天然隔离，某个进程崩溃不影响其他进程。如果业务需要共享内存状态（比如在线用户表），那单进程多线程更合适，通过 shm 或线程局部存储减少跨进程通信成本。混合架构也经常见到：多进程负责网络接入，通过共享内存队列把数据丢给独立业务进程处理。

实际压测中还有个容易被忽略的点：内存分配器和锁的争用。多线程环境下如果每个线程都频繁 new/delete 小块内存，glibc 默认的 malloc 会在锁上产生严重竞争。解决思路是自己实现内存池或者使用 jemalloc/tcmalloc。我在那个 80 万连接网关里直接替换了 jemalloc，配合预创建的连接对象池和 io buffer 池，内存分配耗时掉了接近 60%，整体吞吐提升明显。这一步看起来是细节，但到百万连接规模时，它不再是优化项，而更像必需品。

5. 实战中的连接管理：构建一个 HTTP 网关的 Reactor 骨架

理论聊清楚后，用一个具体例子把整个流程串起来：在 Linux 上用 C++ 和 epoll 实现一个简单的 Reactor 网关骨架，可以处理 TCP 连接，接收 HTTP 请求并回包。虽然具体代码量不大，但架构是按生产标准走的主从 Reactor 模式。

5.1 关键组件与类设计

一个可自定义的最小 Reactor 核心包含以下组件：

• EventLoop：封装 epoll 实例，提供 loop 循环、add/del/mod 事件接口。
• Channel：抽象一个 fd 及其感兴趣的事件和事件回调。
• Acceptor：封装 listen fd 和 accept 逻辑，当 EPOLLIN 就绪时取出新连接。
• TcpConnection：表示一个已建立的 TCP 连接，持有 socket、读写缓冲区和状态。
• ThreadPool：numThreads 个子线程，每个线程里运行一个 subReactor EventLoop。
• 主线程：持有 mainReactor（Acceptor），新连接按 round-robin 分配到 subReactor。

当新连接到达时，Acceptor 把它 accept 出来，得到新 fd，然后调用某个 subReactor 的 update 方法，把该 fd 注册到子 EventLoop 的 epoll 实例上。这个注册操作跨线程，所以需要唤醒子线程的 epoll_wait——常用的做法是 eventfd 写入一个字节，子线程从 eventfd 被唤醒后执行注册回调。

5.2 核心 IO 模块的示例代码

下面提供一个最小化的 EventLoop 核心循环示意（节选关键部分）：

cpp复制class EventLoop {
 public:
  explicit EventLoop()
      : epfd_(epoll_create1(EPOLL_CLOEXEC)),
        wakeup_fd_(eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC)) {
    addFd(wakeup_fd_, EPOLLIN, [this]() { handleWakeup(); });
  }

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

    while (!quit_) {
      int n = epoll_wait(epfd_, events, kMaxEvents, timeoutMs_);
      for (int i = 0; i < n; ++i) {
        auto* ch = static_cast<Channel*>(events[i].data.ptr);
        ch->handleEvent(events[i].events);
      }
      doPendingFunctors();  // 执行跨线程提交的任务
    }
  }

  void runInLoop(Functor cb) {
    if (isInLoopThread()) {
      cb();
    } else {
      queueInLoop(std::move(cb));
    }
  }

  void queueInLoop(Functor cb) {
    {
      std::lock_guard<std::mutex> lock(mutex_);
      pendingFunctors_.push_back(std::move(cb));
    }
    // 唤醒阻塞在 epoll_wait 的线程
    uint64_t one = 1;
    write(wakeup_fd_, &one, sizeof(one));
  }

 private:
  void handleWakeup() {
    uint64_t one;
    read(wakeup_fd_, &one, sizeof(one));  // 清空 eventfd
  }

  int epfd_;
  int wakeup_fd_;
  int timeoutMs_ = 100;
  bool quit_ = false;
  std::mutex mutex_;
  std::vector<Functor> pendingFunctors_;
};

看到这里你可能想问：给每个 Channel 都用 data.ptr 指向 Channel 对象，那么在 handleEvent 里怎么知道是哪个 fd 上发生了什么事件？这是 Channel 的职责，Channel 保存 fd、所属 EventLoop、感兴趣事件以及回调函数。epoll_event.data.ptr 指向 Channel，就能一路找回 fd 和对应回调。用指针而不用 data.fd 的好处是：你可以为同一个 fd 在不同阶段绑定不同的回调集合，让协议状态机实现更自然。

当一个连接进来，主线程 accept 到 fd 后，最简单粗暴的方式是立刻在新 fd 上注册 EPOLLIN 到某个 subReactor，并在 Channel 的读回调里调用连接对象的 onRead()。读回调读取 socket 数据，解析 HTTP 请求行和头部，构造响应报文返回客户端。下面这段代码展示了一个带有限长缓冲和 LT 模式读取的简化 onRead：

cpp复制ssize_t TcpConnection::handleRead() {
  char extrabuf[65536];
  ssize_t n = ::recv(fd_, extrabuf, sizeof(extrabuf), 0);
  if (n > 0) {
    inputBuffer_.append(extrabuf, n);
    // 尝试从 inputBuffer_ 中解析 HTTP 请求
    if (inputBuffer_.find("\r\n\r\n") != std::string::npos) {
      // 解析头部，这里就省略了
      std::string response = "HTTP/1.1 200 OK\r\nContent-Length: 2\r\n\r\nOK";
      outputBuffer_.append(response);
      enableWriting();  // 注册 EPOLLOUT 事件
    }
    return n;
  } else if (n == 0) {
    handleClose();
    return 0;
  } else {
    if (errno != EAGAIN && errno != EWOULDBLOCK) {
      handleError();
    }
    return -1;
  }
}

读这里注意两个设计选择：

• 我优先用 recv 而不是 read，因为 recv 的 flags 参数未来可以做带外数据等更精细的控制，虽然当前只传 0，但从一开始把接口定下来，后面扩展不伤筋动骨。
• 启用 EPOLLOUT 的时机很关键。没必要一上来就给所有连接注册 EPOLLOUT，绝大多数连接大部分时间只读不发，过早注册 EPOLLOUT 会导致每次 epoll_wait 都把它当成可写事件返回，白忙一场。正确的做法是：需要发送数据时再注册 EPOLLOUT，数据发完立刻删除 EPOLLOUT 事件。这就是边缘触发在写事件上的一个变体，业界叫“注册写事件的时机优化”。

5.3 主从 Reactor 的新连接分发流程

主从 Reactor 的好处在于 accept 和 IO 处理隔离。主线程的 EventLoop 只监听 listen fd。如果有新连接，Acceptor 执行 accept，得到一个 fd，然后从 ThreadPool 中选一个 subReactor（可以用原子变量做 round-robin），调用 subReactor->runInLoop 把注册操作丢过去：

cpp复制class Acceptor {
 public:
  Acceptor(EventLoop* loop, const InetAddress& addr)
      : loop_(loop), acceptChannel_(loop, listenFd_) {
    acceptChannel_.setReadCallback([this]() { handleRead(); });
    acceptChannel_.enableReading();
  }

  void handleRead() {
    while (true) {
      int connfd = ::accept4(listenFd_, nullptr, nullptr, SOCK_NONBLOCK | SOCK_CLOEXEC);
      if (connfd < 0) {
        if (errno == EAGAIN) break;  // 已经 accept 完所有连接
        if (errno == EINTR) continue;
        break;
      }
      // 选择 subReactor 并派发
      EventLoop* next = threadPool_->getNextLoop();
      next->runInLoop([this, connfd]() {
        // 在 subReactor 线程内创建 TcpConnection
        createConnection(connfd);
      });
    }
  }
};

这是一个常常容易被忽略的点：accept 里 SOCK_NONBLOCK | SOCK_CLOEXEC 必须要有。accept4 相比 accept 的额外好处是，你可以避免后续 fcntl 设置非阻塞和 close-on-exec 的竞态窗口。如果直接用 accept 再加 fcntl，多线程下可能会出现短暂时间内新 fd 被无意继承给子进程，造成 fd 泄漏和潜在安全风险。

5.4 回调分层：让代码可维护的关键

骨架的另一个重点是事件回调的分层设计。把回调分成三个阶段：Channel 阶段只负责“这个 fd 可读了”，TcpConnection 阶段只知道“读到一段字节流”，业务阶段才解析 HTTP 协议或者做业务处理。如果用回调函数指针或 std::function 把这三个阶段串起来，你在新增协议时就不用大改网络层代码。比如我们后来在同一个网关上从 HTTP 切到 WebSocket，只更换了业务层解析器，网络层一行没动。这就是清晰的层次边界带来的收益，它不像性能压测那样能立刻量化，但对长线维护来说价值极大。

实测下来，这种分层的代码在排查问题时也简单得多：遇到诡异 bug，先看是不是 Channel 层事件分发出了问题，再看是不是 TcpConnection 层缓冲区清理不彻底，最后才怀疑业务层逻辑。每一层都能单独写测试验证，不用整条链路像黑盒一样瞎猜，这对上线后的故障定位帮助极大。

6. 压测百万并发时踩过的坑与排查技巧

前面讲的都是理论怎么落地，但真正到压测环节，各种问题才会集中爆发。我把那次 80 万连接里几个非常典型的坑整理出来，每个都说清楚现象和原因，最后附上一张排查对照表。

6.1 accept 返回 EMFILE 导致的 CPU 空转

现象：后端压测到 10 万连接左右，服务端 CPU 突然飙升到 100%，整机吞吐急剧下降。

排查过程：先用 strace 查看系统调用，发现进程在疯狂循环执行 accept，每次都返回 EMFILE（进程 fd 数到达上限）。原因是主 Reactor 里 accept 用的是水平触发，listen fd 一直可读，但每次 accept 都因为 fd 耗尽而失败，事件没清掉，epoll_wait 立刻又返回这个可读事件，陷入 busy loop。

这个问题最直接的解决办法有两个方向：

• 提前预留一组空闲 fd：让 accept 成功一次后立刻 close 掉，把连接挂到 idle 队列，等真正需要时再取出来用。这能保证 accept 永远成功，避免 EMFILE 卡死循环。
• 如果没有预留 fd，则要在 accept 返回 EMFILE 时立刻将 listen fd 的可读事件移除，等 fd 数量下降后再重新注册。

我当时的做法是第一种：进程启动时预先打开 1024 个指向 /dev/null 的 fd 作为应急池。当 accept 失败且 errno 为 EMFILE 时，从应急池中释放一个 fd 并立即执行 accept，再将该连接关闭，腾出空间，防止事件循环卡死。这个技巧在一些内存型服务里也常见，比如为了防止“文件句柄耗尽导致监控消失”，很适合作为保底手段。

6.2 TIME_WAIT 堆积与端口耗尽

现象：短连接压测场景下，服务端主动断开后大量连接进入 TIME_WAIT，客户端用完了端口范围，新连接无法建立。

原因分析：TIME_WAIT 是 TCP 协议为了保证“迟到报文段不会错误匹配新连接”而设计的 2MSL (最大段生存期) 等待状态，默认 60 秒。服务端如果频繁主动关闭连接，每秒关 1 万个连接，60 秒内 TIME_WAIT 就累积到 60 万，超出了默认的 tcp_max_tw_buckets。

解决这个问题的常见经验排序如下：

• 尽量让客户端先断开连接。客户端断开后产生的 TIME_WAIT 在客户端上，服务端进入 CLOSE_WAIT，可以尽快释放资源。这要求通信协议设计上支持服务端发起关闭后等客户端确认回包并先关闭。
• 开启 tcp_tw_reuse，仅对客户端出向连接有效，能复用处于 TIME_WAIT 状态的连接来发起新的出向连接。这不是万能药，但对于压测工具自己发连接的场景很有用。
• 降低 tcp_max_tw_buckets 并不能解决问题，只是让新的 TIME_WAIT 无法建立，反而可能断连接。
• 调大端口范围：ip_local_port_range 的范围大小决定了作为客户端时可用的四元组数量，从默认 28232 个提高到约 64512 个后，测试机的客户端连接数上限翻倍。如果还嫌不够，客户端需要绑定多个 IP，或者直接用长连接而不是短连接。

在这个项目里我们最终说服了协议组把“服务端主动断开”改成了“服务端返回关闭请求，客户端主动断开”，TIME_WAIT 直接降了一个数量级。这个优化不费 CPU 不费内存，但治标不治本，底层逻辑是：短连接频繁断开时，只能靠大量 TIME_WAIT 来换取协议正确性。

所以在设计早期就尽量用长连接或连接池，才是避免端口耗尽的根本策略。比如做 RPC 框架时客户端维护一个连接池，长连接 + 心跳，大幅降低连接建立/断开的频率。

6.3 半包粘包导致业务解析错乱

现象：压测中偶发性出现 400 错误响应，客户端重试后正常，但错误率始终不是 0。

根因：TCP 是字节流协议，recv 一次不一定拿到一个完整的应用层报文，可能只拿到半包，也可能一次拿到多个报文（粘包）。如果写代码时按“收到多少处理多少”的原始逻辑直接解析，解析器会在半包处报错。

之前代码里需要改成完整的分包解析流程：把收到的所有字节先扔进 inputBuffer_，从 buffer 开头检查是否包含一个完整报文（在 HTTP 场景是找到 \r\n\r\n 并核对 Content-Length），不完整就继续等待数据，完整就按照长度提取报文，剩余数据留在缓冲区继续处理下一个报文。

这个“应用层缓冲区 + 状态机解析”的模式在长连接场景下是绕不过去的基础设施。很多新手直接基于 read 返回的 char 数组解析，一旦业务 QPS 上来，几乎百分百会出现偶发性的解析失败。另外一个建议是：给解析器写单测时一定要准备“半包 + 粘包 + 跨包边界”三组用例，否则很难提前发现这个问题。

6.4 缺乏背压导致的内存暴涨

现象：压测过程中，如果客户端消费速度跟不上，服务端发送缓冲会持续增长，内存占用直线上升，最终 OOM。

原因：你在 EPOLLOUT 事件里不断往 socket 里写数据，而 socket 发送缓冲区已满，数据就一直堆积在用户态的应用层 outBuffer 里，如果不限制 outBuffer 的大小，内存就无上限增长。

解决这类问题的通用做法是带背压的流控：

• 设置 outBuffer 的软上限，比如 16MB。超过这个阈值，要么断开连接（协议允许的话），要么暂停读取客户端数据（从 subReactor 中去掉 EPOLLIN），让 TCP 窗口自然收紧，迫使对方减慢发送。
• 在协议中建议客户端做流控窗口：只有收到服务端 ACK 或允许发送的指令后，客户端才能继续发送大量数据，这能在更早阶段避免堆积。

有人可能觉得背压是消息队列才需要考虑的事，但实际上 TCP 服务和消息队列本质一样，都是生产者消费者模型。只要生产者不确定消费者的处理能力，就必须设计背压机制。没做背压的高并发服务，就像没有泄洪闸的水库，台风一来必然出问题。

6.5 Client 连接数到不上去时的参数检查清单

如果你在压测时发现客户端程序连接数超过几千就上不去了，先用下面这张表快速定位：

这张表是我后来每次做高并发压测前的预检单。排查问题最怕的不是查不出根因，而是没有一套稳定的逐层排查顺序。先看 fd，再看端口，再看网络层参数，最后才回溯应用代码。因为参数类问题通常影响面大且表现一致，应用代码问题往往偶发并带有业务特征，按影响面和一致性来分优先级，能省下大量盲查时间。

7. 实战中与 Reactor 密切相关的进阶设计

连接管理、IO 读写这些基础框架搭好后，能让系统真正稳定跑到百万并发，还需要考虑定时器、线程模型、内存分配和性能观测这些配套环节。它们与 Reactor 不是孤立关系，而是共同构成了高并发服务的完整闭环。

7.1 定时器与心跳超时管理

高并发长连接必然要管理大量空闲连接。服务端要定期清理死连接，通常做法是给每个连接记录最近活跃时间，然后用一个定时器周期扫描所有连接，把超时未活跃的连接主动关闭。

如果只是简单粗暴地每个连接启动一个定时器，比如每个连接设一个 timerfd_alarm，在 100 万连接下会瞬间创建出海量内核定时器对象，性能和资源消耗都会失控。工程里的普通做法是用层级时间轮或最小堆管理超时时间，统一由一个 tick 触发扫描。

我在项目里用了一个基于最小堆的定时器集合：每个连接的 lastActiveTime 存下来，tick 时不断弹出堆顶，对比是否超时。更新活跃时间不需要删除堆节点，只要更新字段，堆的实际执行成本非常可控。当连接 idle 太久时触发回调关闭连接，同时释放堆中的节点。这套方案在 80 万连接下表现很稳，tick 间隔设为 1 秒，CPU 占用不到 1%。

如果追求更极端的性能，可以用单层级时间轮（比如 60 格，每格 1 秒），连接按超时时间挂到对应格子里。每次 tick 只获取当前指针指向的一格，遍历其中的连接，检查是否需要关闭。这样既不频繁扫描，也不会在堆中反复做 sift 操作，在毫秒级超时场景特别好用。

7.2 线程模型与锁粒度控制

主从 Reactor 的多线程框架里，每个 subReactor 独自管理一批连接，理论上 subReactor 之间无共享状态，不需要互相加锁。但实际操作中还是会有跨线程交互的场景：

• 主线程 accept 新连接后要通知 subReactor，这里通过 eventfd + runInLoop 完成，锁粒度只在 pendingFunctors 队列上，开销很低。
• 业务线程处理完请求后要往 subReactor 里发数据，同样走 runInLoop 或直接调用 connection 的 send 方法，send 内部先判断当前线程是不是持有该连接的 Reactor 线程：是就直接写 socket，不是就入队加唤醒。

这个设计意味着锁只存在每个 subReactor 自己的队列中，全局没有一把大锁。这个模型才是主从 Reactor 真正能拓展到百万的核心竞争力：把锁的竞争范围压到单线程内部，剩下的交给 CPU 核数去并行。

有的团队把一个 Reactor 配置一个线程，另一个业务处理线程去操作该连接 fd 时偶尔会出现并发问题。我的建议是：明确所有 fd 操作应该在哪个线程，任何不属于该线程的操作都提交到对应 EventLoop 队列里执行，尽量别裸调系统调用写 fd，否则事件机制和业务线程会产生竞态，问题非常难排查。

7.3 应用层缓冲区的内存优化

百万连接如果每个连接都预分配 4KB 读缓冲和 4KB 写缓冲，100 万连接就是 800MB 的静态预分配。而实际上绝大多数连接大部分时间没有数据，空闲连接大量预分配是浪费很大的。

优化思路之一是延迟分配：初始时读写缓冲都是空的，不分配内存；第一次有数据要写时，才分配一个 1KB 或 4KB 的块；数据发送完毕后，不建议立刻释放，而是保留一定水位（比如当容量超过 16KB 时再释放），这样连接反复发送少量数据时不用频繁 malloc/free。

再进阶一些可以引入对象池或 Slab 分配器。把常用大小的缓冲区块放在池子里复用，避免每次 send/recv 都走系统分配。我在压测中对比过：开启缓冲池后，在随机大小请求下，服务端的 malloc 耗时占比从 25% 降到 8% 左右，效果直观且显著。

一个更具体的经验来自空闲连接的处理：如果你有 100 万连接，其中 80% 长期无数据收发，那这个 80% 的空闲连接应该尽量不占业务缓冲区内存。一种常见做法是为 idle 连接保留一个最小对象（几十字节的连接信息），读缓冲延迟到第一次读取时再初始化。这套做法有点像数据库连接池：连接初始很轻，只有真正出现数据流量时才分配大的内存块。

7.4 全链路性能观测指标

把百万连接撑起来只是第一步，难的是后续持续稳定运行。我建议在代码里埋入几个关键计数器，它们是判断系统健康状态的重要依据：

• 当前 TCP 连接数、每秒新建连接数和每秒关闭连接数。通过这三个数字能算出连接净增速，提前发现连接泄漏。
• 每个 subReactor 的 epoll_wait 返回事件数和耗时分布。如果某个 subReactor 自身事件数明显偏高，说明负载不均，需要检查 hash 策略。
• 每个连接的读写缓冲平均水位和最大值，用来判断背压是否生效。
• 分配器、对象池的命中率与内存总量。

这些指标在压测和线上都很有价值：压测时报出“100 万连接建好”，其实只是起点。在一个空闲连接占 90% 的真实场景中，最需要关注的是故障恢复速度和新连接建立速率，不是单纯的总连接水位。比如你维持 100 万连接，某个上游瞬间抽风 5 秒，恢复后是否有 50 万连接同时重连？如果服务端 accept 突增能力不足，瞬间就会被冲垮。这种“连接风暴”才是高并发系统最考验设计的地方。

为了避免被冲垮，通常要做连接建立速度的限流（比如 accept 速率上限），并且在接入层使用连接权重分配，让重连均匀分散到多台机器。Reactor 网络模型能高效处理并发连接，但它并不会自动防止业务突发流量带来的过载。只有加上信号处理和过载保护逻辑，整个系统才算完整。

8. Reactor 模型的横向对比与适用边界

Reactor 模型并不是唯一的高并发方案，实际工程里还要区分场景做取舍。比如 Nginx 用的是多进程 + 非阻塞 IO 事件驱动，本质上也是 Reactor 的变种；而 Go 的 goroutine 配合 netpoller 在语言层面隐藏了 IO 多路复用细节；Erlang/BEAM 则是进程级别的 Actor 模型。

8.1 Reactor、Proactor 与协程的取舍

拿 Proactor 模型来说，它和 Reactor 的区别在于异步 IO 的层次。Reactor 里读数据仍要应用自己调 read/recv，Proactor 则通知内核把数据读到指定缓冲区后，直接回调你的业务逻辑。Windows 的 IOCP 是典型的 Proactor 实现。Linux 的 AIO 多年来在 socket 支持上不够成熟，所以实际上 Linux 下多数库依然走 Reactor 路线，simplified 地讲，就是“告诉内核你要看哪些事件，然后等通知”的模式，但把数据读写和应用逻辑的时机做了更细的分工。

另外要注意 Proactor 在 UDP 和文件 IO 上有其优势，在磁盘异步 IO（比如 io_uring）场景下很好用。如果主业务是海量磁盘文件和网络混合的场景，Proactor 思路其实比 Reactor 更合理。所以不要让“Linux 下必须用 Reactor”的观点僵化，技术选型要结合 IO 类型的分布来做。

协程模型则是另一个维度的优解。像 libco、brpc 的 bthread 或 C++20 的 coroutine，它们利用协程挂起/恢复机制，把“等待事件”变得像写同步代码一样自然。底层驱动通常还是 epoll，但代码层的表达和调度模式完全不同。如果一个团队整体对异步回调掌握得不好，选择协程框架可能交付效率反而更高。

作为参考，我在多语言项目中做过一个粗略对照：

8.2 是不是所有系统都要冲百万并发

我观察到的一个常见误解是，很多新项目连日活一万都没有，却一上来就要求系统按百万连接设计。百万连接意味着更复杂的代码结构、更多的调试成本和更高的运维要求，对初创或中小规模业务来说，这种复杂度通常并不划算。

Reactor 模型的选择应该由质量和扩展方式驱动，而不是盲目跟风。如果业务只会同时存在几百个在线用户，用一个多线程阻塞式服务或单 Reactor 单线程可能就够用了。与其把时间花在追求百万连接，不如先把业务逻辑、数据模型和可观测性做好。正如我在前面提到的，如果从一开始就知道会向千万在线发展，那直接采用成熟网络库（Netty、libevent 等）并按其规范设计业务层，比中途重构网络层会省太多时间。

8.3 从单机百万到分布式千万的跃迁

单台物理机支撑百万 TCP 连接，在现代 Linux + 合理调优下是可以做到的。但更大规模通常需要拆到多机：客户端使用域名解析到多个 VIP，通过负载均衡（如 LVS、Nginx）分发到后端的多个接入节点。这时每个单机只需要支撑 10~20 万连接即可，分布式的好处还显著降低了单点故障风险。

这里要注意连接迁移和会话保持的问题。如果客户端建立了到 A 节点的长连接，A 节点重启或缩容时，已经建立的连接必然断开。为解决这个问题可以引入接入层 session 复制或强制客户端重连。最简单的方案是在客户端使用一致性 hash 且支持 failover 重连，服务端在上线发布时采用滚动重启，一次只重启一小批实例，配合客户端指数退避重连，可以让存量连接的整体无感率控制在 99% 以上。Reactor 模型在高并发下的意义在于让单机性能最大化，但真正扛住大规模业务靠的是分布式集群的共同协作，二者缺一不可。

9. 常见问题快查与排障思路

在项目开发的各个阶段，团队小伙伴经常在群里提问一些共性问题。我把一些高频问题和排查顺序整理成速查内容，方便你在实际开发中对照参考。

9.1 Reactor 线程中能吃 CPU 的耗时操作吗

直接吃 CPU 会阻塞整个事件循环，导致该线程负责的所有连接都不能被处理。通常标准做法是：读事件只做解析和业务任务投递，CPU 耗时计算放在业务线程池。但 CPU 占用高的计算任务本身也会占满业务线程，因此需要把计算任务继续拆分或用异步队列削峰。如果计算任务的耗时可控且不频繁，可以考虑事件循环中做，但要随时评估延迟冲击。

9.2 EPOLLOUT 注册时机如何把握才合适

最常见的原则是“用到才注册，写完立刻删除”。连接刚建立时不注册 EPOLLOUT，因为大概率还没有数据可写；发送数据时把数据放入 outBuffer，尝试直接调用 write，若一次性写完则不需要注册 EPOLLOUT；若只写了部分，则需要注册 EPOLLOUT，等待内核缓冲区可写后继续发送剩余数据，全部写清再把 EPOLLOUT 移除。这个逻辑能有效避免灵魂拷问“为什么我的 epoll_wait 一直返回 EPOLLOUT”。

9.3 为什么连接数越多，响应延迟反而提高了

主要有三个可能方向：一是某个共享资源（像锁、日志、数据库连接）到达饱和，单个请求处理时间变长；二是内存开始不足导致 swap 或分配变慢；三是 CPU 核数有限，而线程数量超过核数太多造成大量上下文切换。排查时先用 top 观察 cpu 和内存，再配合 perf top 看热点函数，很多性能诡异的问题往往一下就暴露了。

9.4 如何有效观测真实场景下的高并发状态

不建议只在压测环境自嗨，所有指标在生产上也要持续观测。连接数上涨阶段要关注的新连接建立速率、内存增长斜率、TIME_WAIT 曲线和 epoll 事件分布。若内存在连接数不再增长后依然保持上升，基本就是连接对象或缓冲区泄漏——此时排查方向应该是连接是否在关闭回调中完全释放 fd 和相关内存。

如果遇到线上的诡异问题，一个有效的做法是抓一份当前所有连接状态的快照，结合日志确认连接的建立时间、最近活跃时间、收发字节数、所属 subReactor 编号，这能帮助你确定问题出在哪一个环路，或者哪一台 worker 上出现了局部不均匀。

9.5 有没有比“不断打印日志”更好的调试方式

生产环境打海量日志是高并发服务的毒药。百万连接体量下，每连接一条 info 日志一天就是千万级行，磁盘和 IO 开销爆炸。建议是：正常流程不打 info 日志，关键状态变化（连接建立、关闭、错误）使用结构化日志并采样（比如 1%）；错误路径日志必须包含 fd、对端 IP、连接状态、最近一次活跃时间等上下文，方便快速复现。线上诊断尽量通过 metrics 和定向抓包完成，而不是无脑打日志。

10. 一些个人项目经验与建议

聊了这么多，最后再补充一些零散但在实战中很重要的经验，如果你也在做 Linux 网络方向，应该用得上。

第一个经验是用好系统现状分析工具。当连接数和性能出现异常时，不要急着改代码。先用 ss -s 看 socket 统计，用 ss -tnp 或 netstat 查连接状态分布，用 sar 看网络和内存趋势，再决定从哪里入手。很多“诡异”问题最终都绕回到基础参数上，例如 TIME_WAIT 一堆，其实就是业务层主动断开太多导致。

第二个经验是尽早为连接对象设计可观测性。建议在连接创建和释放时自动上报计数，并且周期性打印每个 subReactor 维护的连接数。有一次排查内存泄漏，凭印象根本看不出来哪条路径没释放 fd，后来才发现是某个定时器回调里捕获了连接对象的 shared_ptr，形成循环引用。如果没有连接数按 subReactor 分布的监控面板，这个问题可能还得熬很久才能定位。

第三个经验是网络编程中“尽量别自定义应用层协议”也是一个重要权衡。高并发网关做内部协议时，我会先评估已有的 protobuf、gRPC、HTTP/2 是否满足需求。完全自定义协议意味着从编解码到兼容性都要自己负责，开发量可以轻松翻倍。只有网络包结构极为固定且要求极致性能时，才值得自己做二进制头 + 负载的轻量封装。

第四个经验是关于 code review 的。手写 Reactor 代码时，要求所有跨线程操作必须标记归属线程，review 重点看是否有别的线程直接操作了不属于自己的 fd。我在早期经历中踩过这类竞态的坑，有一次业务线程直接调用 fd 的 write 来发送数据，和事件循环里的 ET 读取发生了数据交错，最终拼出一个非常难排查的错包问题。从那以后就立了规矩：fd 归属哪条线程，操作权就只能在哪条线程；其他线程要发送数据走队列投递。这是主从 Reactor 框架运行稳定的隐形基石。

我实际测试的项目里，稳定压测后服务端只用 16 个 subReactor 线程，再加 8 个业务线程和 4 个定时器线程，就能把 80 万连接维持得非常好。CPU 总占用不到 80%，内存 40GB，剩余资源还在处理日常监控和前向代理逻辑。真正的百万并发，除了正确的网络模型，还需要在参数调优、内存规划和业务设计上做大量配合。希望这篇文章能给正在做 Linux 网络开发的朋友提供一个相对系统的参考思路，哪怕只帮你在一两个问题上省下排查时间，这篇内容也算值了。