Ответ 1
Я знаю, что это старый вопрос, но теперь это объясняется в nodejs.org здесь:
Рабочие процессы порождаются с использованием метода child_process.fork, так что они могут связываться с родителем через IPC и передавать сервер обращается вперед и назад.
Когда вы вызываете server.listen(...) у рабочего, он сериализует аргументы и передает запрос мастер-процессу. Если мастер процесс уже имеет сервер прослушивания, соответствующий рабочему требования, затем он передает ручку работнику. Если это не уже есть сервер прослушивания, соответствующий этому требованию, тогда он создаст один и передаст дескриптор работнику.
Это вызывает потенциально неожиданное поведение в трех случаях:
server.listen({fd: 7}) - Поскольку сообщение передается мастеру, дескриптор файла 7 в родительском элементе будет прослушиваться, а дескриптор перешел к рабочему, вместо того, чтобы слушать рабочую идею что ссылается на дескриптор файла номер 7.
server.listen(дескриптор) - Прослушивание ручек явно вызовет чтобы использовать поставляемую ручку, а не разговаривать с мастером обработать. Если рабочий уже имеет дескриптор, то он предположил, что вы знаете, что делаете.
server.listen(0) - Обычно это приводит к тому, что серверы прослушивают случайный порт. Однако в кластере каждый рабочий получит тот же "случайный" порт при каждом прослушивании (0). По сути, порт случайный в первый раз, но предсказуемый после этого. Если ты хочешь прослушивать уникальный порт, генерировать номер порта на основе кластера идентификатор работника.
Когда несколько процессов принимают все() на одном и том же базовом ресурс, балансировка нагрузки операционной системы через них очень эффективно. В Node.js или в вашей программе нет логики маршрутизации, и нет общего состояния между рабочими. Поэтому важно создайте свою программу таким образом, чтобы она не слишком сильно в-памяти объектов данных для таких вещей, как сеансы и логин.
Поскольку рабочие - это все отдельные процессы, их можно убить или повторно создаются в зависимости от потребностей вашей программы, не затрагивая другие работников. До тех пор, пока некоторые рабочие еще живы, сервер будет продолжать принимать соединения. Node не автоматически однако, для управления количеством рабочих для вас. Это твое ответственность за управление пулом работников для ваших приложений.