针对你遇到的gRPC多进程共享端口的问题，我来拆解原因并给出具体的解决办法：

一、为什么只有最后一个子进程处理请求？ #

在Mac OS X（BSD系系统）环境下，gRPC默认仅为监听套接字启用SO_REUSEADDR选项，而非SO_REUSEPORT。两者的核心区别是：

• SO_REUSEADDR允许多个进程绑定同一端口，但内核只会把新连接转发给最后一个成功绑定的进程，之前绑定的进程会被内核“忽略”，这就是所有请求都流向最后启动子进程的原因。
• SO_REUSEPORT才是真正支持多进程共享端口的选项，启用后内核会将新连接均匀分配给所有监听同一端口的进程。

二、为什么限制MaxThreads后部分客户端连接失败？ #

grpc::ResourceQuota::SetMaxThreads()设置的是服务器可使用的总线程上限，包含业务处理线程、gRPC内部IO线程等。当并发客户端数量超过这个阈值时，服务器无法分配足够线程处理新连接，内核就会直接拒绝部分客户端的连接请求。

具体修改方案 #

1. 开启SO_REUSEPORT实现多进程负载均衡 #

修改ForkedProcess::start()方法，通过ChannelArguments启用SO_REUSEPORT：

void start() {
    ServerBuilder builder;
    grpc::ChannelArguments args;
    // 开启SO_REUSEPORT，让多进程共享端口接收请求
    args.SetInt(GRPC_ARG_ALLOW_REUSEPORT, 1);
    
    // 使用带参数的AddListeningPort重载，传入配置好的ChannelArguments
    builder.AddListeningPort(server_address, grpc::InsecureServerCredentials(), nullptr, &args);
    
    grpc::ResourceQuota quota;
    quota.SetMaxThreads(2);
    builder.SetResourceQuota(quota);
    builder.RegisterService(&service);
    
    std::unique_ptr<Server> server(builder.BuildAndStart());
    std::cout << "Server listening on port: " << server_address << std::endl;
    server->Wait();
}

启用后，内核会将客户端连接均匀分发给所有子进程，每个进程都能处理一部分请求。

2. 解决MaxThreads限制导致的连接失败问题 #

如果必须限制线程数，可通过以下方式优化：

• 适当调高MaxThreads值：预留出gRPC内部IO线程的开销（默认等于CPU核心数），确保总线程数能覆盖预期并发量。
• 增大连接排队队列（backlog）：让内核暂时排队更多连接请求，等待服务器线程空闲后处理：

  int backlog = 200; // 默认通常为128，可根据业务调整
  builder.AddListeningPort(server_address, grpc::InsecureServerCredentials(), &backlog, &args);
  

  注意：backlog只是临时缓冲，若服务器长期线程饱和，超出backlog的连接仍会被拒绝。
• 切换到gRPC异步API：异步模型无需为每个连接分配单独线程，少量线程即可处理大量并发连接，是高并发场景下的更优选择。

3. 优化主进程的子进程等待逻辑 #

你当前的主进程仅调用一次wait()，会导致第一个子进程退出后主进程就终止，第二个子进程变成孤儿进程。建议循环等待所有子进程退出：

// 替换原有的wait(&error_code);
int status;
pid_t pid;
while ((pid = wait(&status)) > 0) {
    std::cout << "Child process " << pid << " exited with status " << status << std::endl;
}

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