Как Node обрабатывает интенсивные файловые операции с несколькими потоками в пуле потоков?

Question

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

Проблема начинается для меня, когда пул потоков входит в picture.its, приведенный в документации узла, что там, где поддержка демультиплексора операционной системы не годится, тогда узел использует пул потоков (который является ничем иным, как потоками, 4 по умолчанию и 128 макс.) Для достижения похожая функциональность. Также упоминается, что файловые операции используют пул потоков вместо демультиплексора ОС.

Итак, меня беспокоит, скажем, я пишу веб-сервер, который должен выполнить несколько файловых операций для каждого клиента, тогда, если миллион клиентов одновременно использует мое приложение, тогда 4 рабочим потокам Node может потребоваться вечность для обслуживания всех запросов. так как пул потоков Node может работать с четырьмя файловыми операциями на данный момент по умолчанию. другие должны ждать, пока эти потоки не освободятся. Даже если рассматривать наилучший вариант пула потоков Node 128, может быть не лучше, если учесть, например, Tomcat, который может параллельно обрабатывать миллионы файловых операций в режиме блокировки.

Это заставило меня задуматься, если на веб-сервере слишком много операций ввода-вывода (в основном связанных с файлами и базами данных), действительно ли Node - правильный выбор?

Answer 1

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

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

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

Эта концепция и дает Node.js свое имя.Каждый процесс должен быть узлом в некотором кластере.

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

Вы действительно проверяли, есть ли проблемы с производительностью?Если нет, откуда вы знаете, что есть какая-то проблема?Большинство файлов могут быть открыты только на короткое время.

На техническом уровне существует ограничение на количество файлов, которые Node.js может открывать одновременно.После достижения этого уровня файловые операции завершатся с ошибкой EMFILE (слишком много открытых файлов).Для превышения этой суммы есть модуль Node.js, который вы можете использовать https://github.com/isaacs/node-graceful-fs, который ставит в очередь дальнейшие файловые операции.