Подходит для рабочих нагрузок, не ограничивающихся ЦП
Прочтите практически любую статью о многопоточности Node.js, и вы увидите примерно такое заявление: «Многопоточность Node.js предназначена для обработки синхронных рабочих нагрузок, которые в противном случае блокировали бы цикл обработки событий, таких как вывод ИИ, который зависит от процессора. . Что касается рабочей нагрузки с интенсивным вводом-выводом, ожидайте небольшого улучшения. Лучше всего для этого подходит асинхронный ввод-вывод».
Проблема подобных утверждений заключается в том, что они подразумевают, что нет другой причины использовать потоки. Это неправда. Есть еще одна причина. Однако также верно и то, что инструментов для использования этого преимущества мало или они вообще отсутствуют. Если вы посмотрите на большинство существующих пулов потоков, вы увидите, что они предназначены для обработки хорошо известного варианта использования, описанного выше; но их нельзя использовать по другой, менее известной причине. Вы уже догадались? Вот подсказка: хотя потоки не сделают нас быстрее, они помогут нам сделать больше. Ответ - масштаб.
Мы можем использовать потоки для предсказуемого и программного масштабирования, если наш пул потоков поддерживает параллелизм. То есть он поддерживает не только синхронные рабочие нагрузки, где для параллелизма установлено значение 1, но и асинхронные, где для параллелизма установлено значение ›1. Более того, эти параллельные задачи могут использовать общую память в потоках и между ними.
Но как мы распределяем работу в этом пуле? Когда поток считается слишком занятым? Хорошие вопросы. Так случилось, что существует среда микросервисов, которая использует параллельный пул потоков; к сожалению, в настоящее время исходный код является собственностью, но цель состоит в том, чтобы предоставить сообществу код, который не связан с истинной целью приложения, например, этот. Тем временем, возможно, имеет смысл заручиться поддержкой этой неиспользованной возможности.
