Sockets 操作系统如何在接受同一套接字的多个进程之间实现负载平衡？

我正在Node.js中阅读集群模块的文档：

它声称：

当多个进程都在同一基础上运行时 资源，操作系统负载平衡非常重要 效率高

这听起来很合理，但即使在谷歌搜索了几个小时后，我仍然没有找到任何文章或任何东西来证实这一点，也没有解释这种负载平衡逻辑在操作系统中是如何工作的

还有，是什么操作系统在做这种有效的负载平衡？

“负载平衡”也许用词有点不恰当，本质上只是操作系统如何选择下一个要唤醒和/或运行的进程的问题。一般来说，进程调度器会根据一些标准来选择要运行的进程，比如给优先级相同的进程分配相同的cpu时间、cpu/内存位置（不要在cpu周围反弹进程）等等。总之，通过谷歌搜索，你会发现很多关于进程调度算法和实现的内容

现在，对于accept（）的特殊情况，这还取决于操作系统如何实现等待accept（）的唤醒进程

• 一个简单的实现就是唤醒在accept（）调用中被阻塞的每个进程，然后让调度器选择它们运行的顺序

• 上面的过程很简单，但会导致一个“雷鸣般的群体”问题，因为只有第一个进程成功地接受了连接，其他进程返回到阻塞。更复杂的方法是操作系统只唤醒一个进程；在这里，可以通过询问调度程序来选择要唤醒的进程，或者（例如）仅通过为此套接字列表选择blocked-on-accept（）中的第一个进程。后者是Linux十年或更长时间以来所做的事情，基于其他人已经发布的信息

• 请注意，这仅适用于阻塞accept（）；对于non-blocking accept（）（我确信node.js就是这么做的），问题是在select（）/poll（）/which中阻塞哪个进程来传递事件。poll（）/select（）的语义实际上要求唤醒它们中的所有成员，因此这里再次出现了雷鸣般的从众问题。对于Linux，以及其他具有特定于系统的高性能轮询接口的系统，通过使用单个共享epoll fd和边缘触发事件，可以避免雷鸣般的群体。在这种情况下，事件将仅传递到epoll_wait（）上阻止的进程之一。我认为，与blocking accept（）类似，选择将事件传递到的进程只是在epoll_wait（）上阻塞的进程列表中为特定的epoll fd选择第一个进程

---

因此，至少对于Linux，无论是对于blocking accept（）还是带有边缘触发epoll的非blocking accept（），在选择要唤醒哪个进程时，都没有调度本身。但是，无论如何，工作负载在进程之间可能是相当均衡的，因为基本上系统会按照进程完成当前工作的顺序循环进程，然后返回到epoll_wait（）上阻塞。我猜你找不到任何与此相关的内容，因为js不应该依赖于操作系统。我不知道为什么文档中提到了操作系统，可能是因为它考虑了Chrome作为操作系统。有趣的是，@Paul-Node.js是一个服务器端框架，它不在浏览器中运行。@Steve我在谷歌搜索时也发现了这个链接，但是它在旧版本的Linux内核中处理了一个不同的问题。研究Apache中使用的“接受互斥”：每个新连接上所有等待的线程都会唤醒。太棒了，谢谢你的解释。因此，基本上，这是否意味着，他们不需要实现任何负载平衡，而只是信任内核通过将新连接提供给最不繁忙的进程来“做正确的事情”？谢谢！这是一个很好的解释，与我们看到的在金属上运行的2.6Linux内核非常匹配。然而，在AWS上运行3.2内核时，我们看到了一些非常不同的东西——当然不是循环。你知道应该在哪里寻找内核之间的变化或虚拟化硬件上的不同性能吗？@Brett:对不起，不知道。出于好奇，你在AWS上看到了什么？对于一个在黑暗中挣扎的想法，我猜在虚拟机主机如何选择要调度的虚拟机CPU方面可能会有一些不同？@janneb我们在裸机上尝试了3.2内核，看到了与AWS相同的东西。我在这里问了一个问题：，并在这里对node.js问题进行了评论：注意，在v0.11上，使用了循环负载平衡。