Linux C Socket使用epoll时如何避免多个fork子进程accept同一连接

问题确认 #

首先明确两个核心判断：

1. 你担心的「两个子进程同时读写同一个TCP连接」的场景存在发生概率，核心原因是当前架构下所有子进程共享同一个监听套接字，触发epoll惊群问题：内核默认会将新连接的就绪事件通知给所有阻塞在epoll_wait的子进程，极端情况下会出现多个子进程同时争抢同一个连接的异常。
2. 不同进程的相同文件描述符数值默认不代表指向同一个TCP连接：只有fork时继承的文件描述符才会指向同一个文件实例，你当前架构下每个子进程自行accept得到的文件描述符属于进程私有，只要没有主动在子进程间传递文件描述符，就算FD数值相同，也对应不同的TCP连接，不会出现读写同一个连接的问题。如果你确实抓到两个子进程操作四元组完全一致的TCP连接，说明你的惊群问题已经触发了异常，或者文件描述符管理逻辑存在bug。

解决方案 #

方案1：启用SO_REUSEPORT端口复用（最推荐，改造成本最低） #

在创建监听套接字后、bind操作前，给监听套接字设置SO_REUSEPORT选项，代码示例：

int opt = 1;
if (setsockopt(listenSocketfd, SOL_SOCKET, SO_REUSEPORT, &opt, sizeof(opt)) < 0) {
    exitPerrorLog("setsockopt SO_REUSEPORT");
}

该方案优势：

• 内核自动将新连接按四元组哈希均匀分发到各个监听子进程，每个新连接只会唤醒一个子进程，完全解决惊群问题
• 同一个TCP连接的整个生命周期只会分配给同一个子进程，特别适配你的HTTP1.1 keep-alive长连接场景，不会出现跨进程操作同一个连接的问题
• 不需要修改现有业务处理逻辑，改造成本极低

方案2：改用单进程accept+多进程处理架构 #

单独启动一个主进程负责监听端口、accept新连接，拿到新连接后通过Unix域套接字将文件描述符传递给空闲的工作子进程，工作子进程只负责处理连接、不监听端口：

• 从架构上彻底避免多进程同时accept的问题
• 可自行实现灵活的负载均衡策略，比如按客户端IP哈希分配，保证同个客户端的长连接始终落在同一个子进程处理
• 缺点是需要额外实现主进程与子进程的文件描述符传递逻辑，改造成本略高

方案3：加进程锁保护accept逻辑 #

如果不想调整现有架构，可以用基于共享内存的互斥锁、或者文件锁保护accept调用，保证同一时间只有一个子进程能执行accept操作：

• 实现简单，但高并发场景下锁会成为性能瓶颈，仅适合低吞吐的业务场景使用

额外优化提示 #

你当前的代码存在隐藏风险：curfdCount变量的维护逻辑被注释，仅在超过10000时强制设为10000，会导致epoll_wait的maxevents参数长期固定为10000，即使实际连接数很少也会浪费内存资源，建议你在连接关闭时正确维护curfdCount的递减逻辑。

内容的提问来源于stack exchange，提问作者Huy Le