3、SO_REUSEPORT 详解：多进程负载均衡与端口复用

聊完 SO_REUSEADDR，咱们得好好说说 SO_REUSEPORT。这个选项，说实话，是 Linux 3.9 内核之后才引入的「大杀器」。我当年第一次在生产环境用它，还是因为一个高并发网关扛不住了——单进程模型，CPU 用不满，但连接数已经爆了。嗯，那时候我才真正体会到这个选项的价值。

3.1 SO_REUSEPORT 到底干了什么？

简单说，SO_REUSEPORT 允许多个进程或线程，绑定到同一个 IP 和端口上。你没看错，是多个进程同时 bind 同一个端口。内核会在它们之间做负载均衡，把进来的连接分发给不同的进程。

你想想看，以前我们怎么做高并发？要么用多线程，要么用多进程 + 一个主进程 accept 然后分发。但 SO_REUSEPORT 直接让每个进程都有自己的 listen fd，各自 accept，互不干扰。这带来的好处很明显：

• CPU 亲和性更好：每个进程可以绑定到固定 CPU 核心，减少缓存抖动
• 锁竞争几乎为零：没有共享的 accept 队列，每个进程独立处理
• 平滑重启：新进程启动后直接 bind 同一个端口，旧进程慢慢退出

3.2 多进程负载均衡实战

我记得有一次帮一个游戏公司优化登录服务器。他们用的是传统的单进程 accept + 线程池模型，高峰期 CPU 使用率只有 40% 左右，但延迟已经上去了。我建议他们改成 SO_REUSEPORT 多进程模型，每个进程绑定一个 CPU 核心。改造后的效果很明显：CPU 利用率飙升到 85% 以上，吞吐量翻了一倍多。

下面是一个典型的 SO_REUSEPORT 服务端代码片段：

int fd = socket(AF_INET, SOCK_STREAM, 0);
int opt = 1;

// 关键：设置 SO_REUSEPORT
if (setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &opt, sizeof(opt)) < 0) {
    perror("setsockopt SO_REUSEPORT");
    exit(1);
}

struct sockaddr_in addr;
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(INADDR_ANY);
addr.sin_port = htons(8080);

if (bind(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
    perror("bind");
    exit(1);
}

listen(fd, SOMAXCONN);

// 每个子进程都执行 accept 循环
while (1) {
    int client = accept(fd, NULL, NULL);
    // 处理客户端请求...
}

启动的时候，你只需要 fork 出多个子进程，每个子进程都执行上面的代码。它们会共享同一个端口 8080，内核自动做负载均衡。

3.3 与 SO_REUSEADDR 的区别

这两个选项经常被搞混，我面试的时候也喜欢问这个问题。说白了，它们解决的问题完全不同：

特性	SO_REUSEADDR	SO_REUSEPORT
核心作用	允许重用处于 TIME_WAIT 状态的端口	允许多个 socket 绑定到同一 IP:端口
适用场景	服务重启时避免 "Address already in use"	多进程/多线程负载均衡
内核版本	所有版本都支持	Linux 3.9+
安全性	无特殊限制，任何进程都可设置	需要所有绑定进程具有相同 EUID，防止端口劫持
负载均衡	不支持，只有一个进程能 accept	内核自动做哈希分发

这里有个容易踩的坑：SO_REUSEPORT 并不能替代 SO_REUSEADDR。如果你在服务重启时，旧进程还在 TIME_WAIT 状态，新进程即使设置了 SO_REUSEPORT 也可能 bind 失败。所以，我通常两个选项一起设置：

int opt = 1;
setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &opt, sizeof(opt));

3.4 内核负载均衡的细节

内核是怎么做负载均衡的？我简单说一下，你理解了这个，排错的时候会更有方向感。

当 SYN 包到达时，内核会计算一个哈希值：

hash = 源IP ^ 源端口 ^ 目的IP ^ 目的端口

然后根据这个哈希值，从所有绑定了该端口的 socket 中选择一个。这个算法保证了：

• 同一个连接始终落在同一个进程（连接跟踪需要）
• 不同连接尽量均匀分布（哈希的随机性）
• 进程数变化时重新分布（新增或减少进程会触发重新哈希）

下面这张图展示了 SO_REUSEPORT 的工作流程：

3.5 避坑指南与最佳实践

最后，我总结几个实战中容易出问题的地方：

1. 进程数不是越多越好：超过 CPU 核心数后，性能反而下降。我习惯用 CPU 核心数 - 1 作为进程数，留一个核心给系统和其他进程。
2. 注意防火墙规则：有些防火墙会跟踪连接状态，如果连接被分发到不同进程，可能导致状态不一致。建议使用无状态防火墙或者 conntrack 模式。
3. 监控每个进程的负载：虽然内核做哈希分发，但某些场景下（比如短连接风暴）可能出现不均匀。我一般会加一个监控，如果某个进程的连接数超过平均值 20%，就触发告警。
4. 平滑重启的坑：新进程启动后，旧进程不要立即退出。给旧进程一个 grace period，让它处理完已有的连接再退出。我通常用 SIGTERM 信号触发优雅关闭。