Почему Node.js однопоточный? [закрыто]

В веб-серверах на основе PHP (или Java / ASP.NET / Ruby) каждый клиентский запрос создается в новом потоке. Но в Node.js все клиенты работают в одном потоке (они могут даже использовать одни и те же переменные!) Я понимаю, что операции ввода-вывода основаны на событиях, поэтому они не блокируют цикл основного потока.

Я не понимаю, ПОЧЕМУ автор Node выбрал его как однопоточный? Это усложняет ситуацию. Например, я не могу запустить функцию с интенсивным использованием процессора, потому что она блокирует основной поток (и новые клиентские запросы блокируются), поэтому мне нужно порождать процесс (что означает, что мне нужно создать отдельный файл JavaScript и выполнить другой процесс узла на Это). Однако в PHP процессоры с интенсивными процессами не блокируют других клиентов, потому что, как я уже говорил, каждый клиент находится в отдельном потоке. Каковы его преимущества по сравнению с многопоточными веб-серверами?

Примечание: я использовал кластеризацию, чтобы обойти это, но это не красиво.

Node.js был создан явно как эксперимент в асинхронной обработке. Теория заключалась в том, что выполнение асинхронной обработки в одном потоке может обеспечить большую производительность и масштабируемость при типичных нагрузках в сети, чем типичная реализация на основе потоков.

И знаешь, что? По моему мнению, эта теория была подтверждена. Приложение node.js, которое не выполняет нагрузку на процессор, может запускать на тысячи параллельных соединений больше, чем Apache, IIS или другие серверы на основе потоков.

Однопоточная, асинхронная природа усложняет ситуацию. Но вы честно думаете, что это сложнее, чем многопоточность? Одно состояние гонки может испортить весь ваш месяц! Или очистите пул потоков из-за каких-то настроек и наблюдайте, как время отклика замедляется до сканирования! Не говоря уже о взаимоблокировках, инверсиях приоритетов и всех других движениях, связанных с многопоточностью.

В конце концов, я не думаю, что это повсеместно лучше или хуже; это отличается, а иногда лучше, а иногда нет. Используйте правильный инструмент для работы.

Проблема с моделью «один поток на запрос» для сервера заключается в том, что они не хорошо масштабируются для нескольких сценариев по сравнению с моделью потока цикла событий.

Как правило, в сценариях с интенсивным вводом / выводом запросы проводят большую часть времени в ожидании завершения ввода / вывода. В течение этого времени в модели «один поток на запрос» ресурсы, связанные с потоком (например, память), не используются, а память является ограничивающим фактором. В модели цикла событий поток цикла выбирает следующее событие (ввод / вывод завершен) для обработки. Таким образом, поток всегда занят (если вы, конечно, программируете его правильно).

Модель цикла событий, поскольку все новые вещи кажутся блестящими, и решение для всех проблем, но какая модель будет использоваться, будет зависеть от сценария, который вам нужно решить. Если у вас есть сценарий интенсивного ввода-вывода (например, прокси-сервер), базовая модель событий будет действовать, тогда как сценарий с интенсивным использованием ЦП с небольшим числом одновременных процессов будет лучше всего работать с моделью на основе потоков.

В реальном мире большинство сценариев будет немного посередине. Вам нужно будет сбалансировать реальную потребность в масштабируемости и сложность разработки, чтобы найти правильную архитектуру (например, иметь внешний интерфейс базы событий, который делегирует внутреннему интерфейсу для задач с интенсивным использованием ЦП. Внешний интерфейс будет использовать небольшие ресурсы, ожидающие выполнения задачи). результат.) Как и в случае любой распределенной системы, для ее работы требуются определенные усилия.

Если вы ищете серебряную пулю, которая подойдет к любому сценарию без каких-либо усилий, вы получите пулю в ногу.

Короче говоря, узлы извлекаются из V8, который является внутренним однопоточным. Существуют способы обойти ограничения для задач, интенсивно использующих процессор.

В какой-то момент (0,7) авторы попытались представить изоляты как способ реализации нескольких потоков вычислений, но в конечном итоге были удалены: https://groups.google.com/forum/#!msg/nodejs/zLzuo292hX0/F7gqfUiKi2sJ