Чтобы явно ответить на этот вопрос, я думаю, что требуется более глубокое понимание цикла асинхронных событий Node.js.
JavaScript является однопоточным, и использование этого асинхронного цикла событий позволяет Node.js выполнять неблокирующие операции ввода-вывода в этом отдельном потоке.
Способ, которым это достигается путем разгрузки операцийядру, когда это необходимо (например, когда имеется много запросов или операций ввода-вывода), а затем забирает результат позднее в цикле событий, в фазе опроса.
Чтобы дать дополнительное пояснение, я включил диаграмму, представленную в документации Node.js:
┌───────────────────────────┐
┌─>│ timers │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ pending callbacks │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ idle, prepare │
│ └─────────────┬─────────────┘ ┌───────────────┐
│ ┌─────────────┴─────────────┐ │ incoming: │
│ │ poll │<─────┤ connections, │
│ └─────────────┬─────────────┘ │ data, etc. │
│ ┌─────────────┴─────────────┐ └───────────────┘
│ │ check │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
└──┤ close callbacks │
└───────────────────────────┘
Об этих фазах можно прочитать более подробно по адресу: https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/
Вкратце:
- таймеры: здесь будут выполняться запланированные обратные вызовы и все, что установлено на таймеры, например setInterval () или setTimeout ().Причина, по которой это происходит в первую очередь, заключается в том, что это просто гарантия того, что указанное время является минимальным количеством времени, которое может потребоваться для их запуска.Это время дополняется временем завершения циклов цикла событий.Их наличие - это способ сохранить их наиболее точными в соответствии с тем, что разработчик указал в функциях интервала или тайм-аута.
- ожидающие обратные вызовы: выполняет обратные вызовы ввода / вывода, отложенные до следующей итерации цикла.Если максимальный номер обратного вызова достигнут в каком-либо цикле событий, остальные обратные вызовы, которые необходимо выполнить, откладываются до следующего цикла (который может быть достигнут вручную, хотя process.nextTick ()), поэтому после таймеров они должны выполнятьсядалее
- idle: используется только для внутреннего использования.Если в цикле обработки событий ничего не осталось, цикл прекратит откладывать что-либо до ядра до тех пор, пока
- prepare: используется только для внутреннего использования.Готовится к следующему циклу цикла событий, если потребуется одно или несколько
- poll: получить новые события ввода-вывода;выполнять связанные с I / O обратные вызовы (почти все, за исключением закрытых обратных вызовов, запланированных таймерами и setImmediate ());узел будет блокировать здесь, когда это необходимо.Эта фаза опроса позволяет продолжить все, что было отложено.
- check: здесь вызываются обратные вызовы setImmediate ()
- close обратные вызовы: некоторые закрытые обратные вызовы, например, socket.on ('close', ...) и другие события 'close', вызываютсяздесь
Опять же, большая часть этого взята из документации по Node.js, но я немного пояснил некоторые детали, чтобы немного понять в этом контексте.
В вашем случае ваши операции с базой данных не будут «блокировать» других пользователей, им просто придется ждать, пока их обратные вызовы не будут обработаны в цикле.Если бы одновременно выполнялось много операций, в ядро было бы выгружено больше, а затем, как только это было бы возможно, возобновлено, что может обеспечить небольшую дополнительную задержку (1) .
Еще одна хорошая графика, которая поможет визуализировать этот процесс, взята из этой статьи: https://webapplog.com/you-dont-know-node/

На заметку -
Есть места, где цикл обработки событий Node.js является хорошим решением, и другие места, где более надежное многопоточное решение может быть лучшим подходом.Убедиться в том, что вы проводите исследование, необходимое для разумного принятия этого решения, связанного со спецификой вашего проекта, никогда не бывает плохой идеей.
(1) Существует несколько статей, которые являются простопоиск в Google по поводу различий в производительности, ожидаемой задержки при большой загрузке сети и различных решений этой проблемы.
Надеюсь, это поможет!