基于Linux TCP Socket的C++同步服务器：子进程间信息通知方案咨询

嘿，这个场景我太熟了——用fork多进程扛TCP连接的服务器，要给所有子进程发通知，确实有几个成熟的方案，我给你唠唠各自的优劣和最佳实践：

方案1：为每个子进程创建独立管道（最简单的可靠方案） #

这是我最常用的方案，实现起来没什么弯弯绕，可靠性也高。

原理 #

每次fork子进程前，父进程先创建一个匿名管道。子进程会继承管道的读端，父进程则保留管道的写端，把所有写端存在一个列表里。当需要通知所有子进程时，父进程遍历这个列表，给每个写端都写入通知消息；每个子进程在处理客户端请求的主循环里，同时监听自己的管道读端，一旦收到数据就执行对应操作。

代码示例（核心部分） #

父进程管理管道和子进程：

#include <vector>
#include <unistd.h>

std::vector<int> child_write_pipes;

// 给所有子进程发通知
void broadcast_to_children(const std::string& msg) {
    for (int fd : child_write_pipes) {
        write(fd, msg.c_str(), msg.size());
    }
}

int main() {
    // 初始化TCP监听套接字（bind、listen步骤省略）
    int listen_fd = ...;

    while (true) {
        int client_fd = accept(listen_fd, nullptr, nullptr);
        if (client_fd == -1) continue;

        int pipe_fd[2];
        if (pipe(pipe_fd) == -1) {
            perror("pipe failed");
            close(client_fd);
            continue;
        }

        pid_t pid = fork();
        if (pid == -1) {
            perror("fork failed");
            close(client_fd);
            close(pipe_fd[0]);
            close(pipe_fd[1]);
            continue;
        } else if (pid == 0) {
            // 子进程：关闭监听套接字和管道写端
            close(listen_fd);
            close(pipe_fd[1]);
            handle_client(client_fd, pipe_fd[0]);
            close(client_fd);
            close(pipe_fd[0]);
            exit(EXIT_SUCCESS);
        } else {
            // 父进程：关闭客户端套接字和管道读端
            close(client_fd);
            close(pipe_fd[0]);
            child_write_pipes.push_back(pipe_fd[1]);
        }
    }
}

子进程处理逻辑：

void handle_client(int client_fd, int pipe_read_fd) {
    fd_set read_fds;
    int max_fd = std::max(client_fd, pipe_read_fd) + 1;

    while (true) {
        FD_ZERO(&read_fds);
        FD_SET(client_fd, &read_fds);
        FD_SET(pipe_read_fd, &read_fds);

        int ret = select(max_fd, &read_fds, nullptr, nullptr, nullptr);
        if (ret == -1) break;

        // 处理父进程的通知
        if (FD_ISSET(pipe_read_fd, &read_fds)) {
            char buf[1024];
            ssize_t n = read(pipe_read_fd, buf, sizeof(buf));
            if (n <= 0) break; // 管道被关闭，父进程可能退出了
            printf("Child %d received: %.*s\n", getpid(), (int)n, buf);
            // 这里执行通知对应的操作
        }

        // 处理客户端请求
        if (FD_ISSET(client_fd, &read_fds)) {
            char req_buf[1024];
            ssize_t n = read(client_fd, req_buf, sizeof(req_buf));
            if (n <= 0) break;
            // 如果是触发通知的操作，通知父进程
            if (strncmp(req_buf, "trigger_notify", 14) == 0) {
                kill(getppid(), SIGUSR1); // 用信号告诉父进程要广播
            }
        }
    }
}

优缺点 #

• ✅ 优点：实现简单，每个子进程的管道独立，不会出现数据竞争；支持传递任意格式的消息。
• ❌ 缺点：父进程需要维护所有子进程的管道写端，子进程退出时要及时从列表中移除（可以通过SIGCHLD信号处理函数做清理）；如果子进程数量上千，遍历写入会有轻微开销，但绝大多数场景下完全够用。

方案2：信号+共享内存（轻量且支持复杂数据） #

如果只是需要“触发子进程执行操作”，不需要传递太多数据，信号是最轻量的选择；如果需要带数据，搭配共享内存就完美了。

原理 #

父进程先创建一块共享内存，用来存储通知的详细数据。当需要通知时，父进程把数据写入共享内存，然后给所有子进程发送自定义信号（比如SIGUSR2）；子进程收到信号后，从共享内存中读取数据并执行操作。

核心注意点 #

• 信号处理函数要尽量简单，只设置一个标志位，不要在里面做复杂操作（比如printf、malloc这些非可重入函数都不能用），然后在主循环里检查标志位再处理。
• 共享内存需要同步机制，比如用信号量，防止父进程写的时候子进程读，导致数据乱掉。

优缺点 #

• ✅ 优点：信号触发速度极快，共享内存可以传递大量复杂数据；不需要维护多个管道，适合子进程数量多的场景。
• ❌ 缺点：信号可能丢失（短时间内多次发送同一个信号，Linux只会保留一个），所以适合通知频率不高的场景；需要处理共享内存的同步和生命周期管理。

方案3：UNIX域套接字多播（高并发大数量场景首选） #

如果你的服务器有几百上千个子进程，而且需要频繁发通知，UNIX域套接字的多播是最高效的选择——父进程只需要发一次消息，所有子进程都能收到。

原理 #

父进程创建一个UNIX域数据报套接字，绑定到本地路径，然后配置多播组；每个子进程创建套接字并加入这个多播组。父进程发送的多播消息会自动被所有加入组的子进程接收。

优缺点 #

• ✅ 优点：一次性广播给所有子进程，不需要遍历；支持结构化数据，比信号灵活；适合高并发场景。
• ❌ 缺点：代码实现比管道和信号复杂，需要处理多播配置；退出时要记得删除套接字文件，避免下次启动报错。

最佳实践总结 #

• 👉 简单通知（无需传数据）：直接用信号，代码最少，速度最快。
• 👉 需要传递结构化消息且子进程不多：选独立管道方案，实现简单，不容易踩坑。
• 👉 子进程数量多且通知频繁：用UNIX域套接字多播，效率最高。
• 👉 需要传递复杂数据且通知频率不高：信号+共享内存组合是最优解。

另外别忘了，父进程一定要处理SIGCHLD信号，及时回收退出的子进程，并清理对应的资源（比如管道写端、子进程PID列表），否则会产生僵尸进程和资源泄漏。

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