Асинхронность Node.js против Java, в чем подвох?

Question

[ericcartman]

Добрый день, помогите разобраться, прочел:

В чём преимущество Node?

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

( если нужен источник - гуглите, ссылки не дает вставлять)

Во-первых, обрабатывает запросы не Node с Java, а сервера. Предположим, мы хотим создать веб-сервис с бекендом и базой. Если создаем на Java, то ставим Nginx + Apache, и вот Апач то уже и выделяет на каждый запрос по воркеру, который работает синхронно, то есть повисает при тяжелых запросах к базе. Правильно я думаю?
Тогда вопрос, каким таким чудесным образом Node это избегает? И что получается? Node работает на движке V8, которому тоже нужен сервер, например Nginx , так? Если можно на пальцах объясните, пожалуйста,как там все происходит ( а я потом уже почитаю и рунет и буржунет) ? Ну асинхронная она, но запрос то должен кто-то делать? Кто его делает?
Ну и вообще, цитата выше, это правда? или просто агитация за ноду?

Answer 1

[InoMono]

Ну во первых, у Java дофига всяких разных greenlet и пр. технологий, где и явная асинхронность не нужна (она и неудобна)

Во вторых, отдельные воркеры в Apache нужны только для тех бэкэндов, которым это нужно.
Если вы хотите максимизировать число параллельно выполняемых бэкэндом запросов, то, очевидно, что нужно искать другой путь, без воркеров Apache. Например, https://habrahabr.ru/company/itsumma/blog/337346/

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

В четвертых, холивар абсолютнобессмысленнен, так как конкретное приложение будет реализовываться с учетом возможностей конкретной среды исполнения. Речь идет о качественной реализации, разумеется. И программист учтет особенности Ноды или JVM. Если он квалифицированный.

В пятых, неквалифицированному программисту не поможет никакой волшебный инструмент.

В шестых, при прочих равных (при одинаково хорошем познании программиста в обеих системах) - JVM будет завсегда быстрее. Ибо она и от С-то отстает ненамного.

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

Answer 2

[Алексей Черемисин]

Полнейшая глупость! На данный момент: а по хорошему уже лет 10 минимум, существует куча асинхронных фреймворков и сетевых библиотек, которые работают ровно на том же самом принципе, как и nodejs.
Примеров, у нас их есть:
- фреймворки jooby.org, sparkjava, springboot
- библиотеки (серверы) netty, undertow, akka
По производительности ничуть не уступают nodejs.

Ну а как все это работает? Есть два вида программирования, которые можно совмещать:
Старый и много кем используемый
- сервер ждет сетевое соединение
- как только соединение произошло, сервер запускает процесс/поток и ему передает открытое соединение.
В этом случае мы ограничены количеством потоков/процессов в системе, имеем большой оверхед на создание процесса/потока. Зато нам не нужно сильно заботиться о работе с сокетами.
Новый хайповый/модерновый
- при старте в сервере региструются обработчики данных (наши сервисы/приложения)
- сервер открывает сокет и слушает все открытые им ранее сокеты, висит в ожидании события прихода/передачи данных на методе select/poll/epoll или побобном.
- как только сервер получил ответ, он вызывает зарегистрированный обработчик и передает туда порцию полученных данных, принимает эти данные обратно и и отправляет в сеть на нужное соединение
В этом случае сервер работает в один поток, просто последовательно вызывая обработчики и отдавая им данные. Быстро, очень быстро, ловко, нет накладных расходов. Зато, если какой обработчик пытается сделать блокирующую операцию - виснут все остальные обработчики, поэтому обработчики с сервером общаются сообщениями и стараются не занимать много процессорных ресурсов. Программирование получается сложное.

Также можно совмещать эти два подхода, делая и пул потоков и работая в асинхронном режиме.

На почитать сюда например - https://ru.wikipedia.org/wiki/Epoll

Comments

[ericcartman]

Зато, если какой обработчик пытается сделать блокирующую операцию - виснут все остальные обработчики

Почему? обработчики = потоки, да? Почему если один поток застрял на тяжелой операции, остальные тоже повисли? С чего бы?

[ericcartman]

делая и пул потоков и работая в асинхронном режиме.

Подскажите, как это сделать на Java? Ну просто пример, допустим такой: Nginx + Apache + Spring 5 ( c WebFlux , Netty) + Akka + PostgreSQL - так пойдет? Будет асинхронно? или все же пул потоков, созданный Apache уже фейл?

[Алексей Черемисин]

Берете jooby.org и вперед, уже и так все асинхронно и с пулами потоков. Если чо не асинхронно, используете deferred (там в документации есть словечко)
Spring/rxjava/akka и все остальное по мере надобности (смотрим в модули).
Апач не нужен. А nginx, ну если особенно желаете в качестве реверс-прокси.

[Алексей Черемисин]

Почему? обработчики = потоки, да? Почему если один поток застрял на тяжелой операции, остальные тоже повисли? С чего бы?

А потому что обработчик != поток
Вызываются все обработчики в одном потоке.

Answer 3

[Александр]

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

Синхронно: приняли запрос, обрабатываем: что-то там считаем, нужна инфа с базы/файло? - Ждем, пока ждем все висит мертвым грузом, получаем, что-то еще считаем, выдаем результат, принимаем следующий запрос.
Асинхронно: приняли запрос, обрабатываем: что-то там считаем, нужна инфа с базы/файло? - Не ждем, переходим к следующему запросу. Как только нужная инфа пришла - возвращаемся к невыполненному запросу, досчитываем недосчитанное, выдаем результат, переходим к следующему запросу.

Ну асинхронная она, но запрос то должен кто-то делать? Кто его делает?

Пользователь. Веб сервера обслуживают запросы от пользователей. При попытке посмотреть, например, эту страницу, ваш браузер отправляет веб-серверу запрос

HOST: toster.ru
GET: /q/500685

Получает ответ, содержащий html, парсит html, узнает, что ему нужно еще запросить: css-стили, js-скрипты, изображения и аналогично запрашивает их. И так далее...

Ну и вообще, цитата выше, это правда? или просто агитация за ноду?

И правда, и неправда одновременно. Правда в том, что Node действительно так работает. Неправда же заключается в том, что ничто не мешает на Java/C/C#/Go/Python/даже, при большом желании, на php написать приложение, которое будет обрабатывать пользовательские запросы точно так же.

Comments

[ericcartman]

Пользователь. Веб сервера обслуживают запросы от пользователей. При попытке посмотреть, например, эту страницу, ваш браузер отправляет веб-серверу запрос

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

[ericcartman]

ничто не мешает на Java/C/C#/Go/Python/даже, при большом желании, на php написать приложение, которое будет обрабатывать пользовательские запросы точно так же

Это хорошо! Тогда подскажите, вот Апач берет запрос, выделяет на него воркер ( это просто поток?) и этот поток пошел к базе данных и повис на тяжелом запросе. А чтобы было асинхронно, этот поток должен был закинуть запрос куда-то в очередь ( ну скажем к шине Кафка), а самому вернуться в пул воркеров, так?

[Александр]

ericcartman,

этот поток пошел к базе данных и повис на тяжелом запросе

да. Потому, что пока он ждет ответа - он простаивает. А мог бы в это время заняться чем то полезным.

этот поток должен был закинуть запрос куда-то в очередь

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

Кому нода его сбагривает, чтобы самой вернуться к обслуживанию запросов сервера?

ОС.

Вот, например, пример (уже устаревший, сейчас мода на async/await-конструкции, где это все прозрачно для программиста) из C#.

listener.BeginAccept( 
                    new AsyncCallback(AcceptCallback),
                    listener );

"Начни принимать запросы на подключение(Дерни мне вот этот метод, когда будет запрос; сокет, который слушает)"

public static void AcceptCallback(IAsyncResult ar) {
...
Socket handler = listener.EndAccept(ar); //получаем новый сокет, который и есть запрос на соединение
...
handler.BeginReceive( state.buffer, 0, StateObject.BufferSize, 0,
            new AsyncCallback(ReadCallback), state); //Говорим ос, что мы готовы принимать байты на сокете, в какой буфер, начиная с 0 байта буфера, размер буфера, колбек для обработки пришедших данных, какой то там объект, чтоб нам было удобнее работать
}

Обрабатываем запрос на подключение клиента.

public static void ReadCallback(IAsyncResult ar) {
        StateObject state = (StateObject) ar.AsyncState; //для какого объекта пришли данные
        Socket handler = state.workSocket; //сокет для работы с нашим клиентом
... //всякая важная работа, т.е. логика  для работы с сетью внутри нашего приложения
               handler.BeginReceive(state.buffer, 0, StateObject.BufferSize, 0,
                new AsyncCallback(ReadCallback), state); // cнова просим ос принять нам данные и оповестить, когда они будут готовы

Получаем данные от клиента. С отправкой аналогично.
Т.е. при новом входящем запросе мы можем сформировать задачу для воркера и скинуть ее воркеру. Точно так же воркер откладывает выполнение задачи, пока мы ждем ответ.

Типичная логика приложения-сервера

парсим запрос //тратим, условно, 0.5 мкс
чего-то считаем, что можем посчитать //0.5-1 мкс  (данные для этого у нас есть рядом в памяти)
запрашиваем нужное файло у ос/по сети и ждем ответ//10-500 мкс
компонуем ответ //1-2 мкс
отсылаем ответ клиенту //1-2 мкс

в асинхронном (читай псевдо-параллельном)

парсим запрос //тратим, условно, 0.1-0.5 мкс
чего-то считаем, что можем посчитать //0.5-1 мкс (данные для этого у нас есть рядом в памяти)
запрашиваем нужное файло у ос/по сети //0.3 мкс, здесь начинается параллелизм
переключаемся на другой запрос из списка обрабатываемых //0.1 мкс
чего то делаем с другим(и) запросом(ами) //10-500 мкс пока не пришла инфа для предыдущего запроса
пришла инфа, переключаемся обратно, получаем инфу //0.1-0.2 мкс потому, что ос уже положила инфу нам в память
компонуем ответ //1-2 мкс
отсылаем ответ клиенту //1-2 мкс

[ericcartman]

Александр, Получается, нода из коробки умеет

приостановить текущее задание и перейти к другому, пока из очереди не получен ответ. Причем, не только какие-то там абстрактные очереди, даже сама ос может работать асинхронно. Т.е. ос уведомляет нас (вызовом callback), когда в сокет пришел ответ/прочитан файл. Из этого коллбека мы определяем для какого запроса пришли данные и продолжаем выполнять тот запрос.

Но минус ее в том, что там 1 поток, т.е. если проц 8 ядерный, то 7 ядер будут простаивать?
А вот tomcat допустим создаст 8 потоков, и утилизирует все 8 ядер, но зато каждый из этих 8 потоков придется самому научить быть асинхронным, т.е. сбагривать таски ОС а самому освобождаться. Так?
Скажем ставлю tomcat + spring и обрабатываю рест-запросы так:

@RequestMapping
public Future<String> get(@RequestParam String input) {
  CompletableFuture<String> future = new CompletableFuture<>();
  return CompletableFuture.supplyAsync(() -> "in the background");
}

Таким образом, у меня пул асинхронных воркеров, так? или все же есть где-то синхронность?

[Александр]

ericcartman, вот насчет кол-ва потоков у ноды я не знаю, но полагаю, ее пишут люди неглупые =)

но зато каждый из этих 8 потоков придется самому научить быть асинхронным, т.е.

... сбагривать таски на доступ к данным ОС, а самому переключаться на следующую задачу и выполнять ее, пока ОС отвечает.
Истинно-верный путь на Java не знаю, но с ходу нагуглил это.

[ericcartman]

Александр,

Истинно-верный путь на Java не знаю, но с ходу нагуглил это.

Прочел, но там

public class AsyncRequestProcessor implements Runnable

В общем банально в новом потоке, а Нода отдает ОС ( как Вы писали выше)

[Александр]

ericcartman, уточню: Нода отдает на откуп ОС ожидание ввода/вывода, что позволяет Ноде во время ожидания ввода-вывода, блокирующей операции, не блокироваться и продолжать работать.

[ericcartman]

Александр, ну ок, а в примере выше как? поток же не отдает на откуп ОС, а повиснет сам? Но зато это отдельный поток, и то что он повиснет, другим не повредит потокам. Но зато потоков ограниченное кол-во можно, явно не для задачи о 10К подключениях ( которая в наше время звучит как 50к)

Answer 4

[Евгений Калибров]

nodeJs не требует отдельного веб сервера, так как имеет свой собственный встроенный.

Comments

[Ерлан Ибраев]

Java (SpringBoot) тоже не требует отдельного сервера, т.к. в нем есть встроенный (два на выбор)

[ericcartman]

И, что, прям его можно на нагруженные системы вешать, этот сервер??? То есть Nginx - нафиг?

[Евгений Калибров]

Ерлан Ибраев, причём тут Spring Boot, это же просто ПО для быстрого и удобного развёртывания спринга?

Вот хорошая статья https://habrahabr.ru/company/Voximplant/blog/303780/ которая объясняет в чём заключается асинхронность в nodeJS

[ericcartman]

Вот хорошая статья которая объясняет в чём заключается асинхронность в nodeJS

Спасибо, прочел. Возникли доп вопросы:
Там сравнивается с PHP, а изначально тут речь шла про Java, как все таки с ней быть? В статье указано:

Event loop регистрирует операцию в пуле потоков с нужным коллбеком.

То есть то же самое, что у Apache? Пул потоков, и каждый уже может повиснуть при тяжелом запросе. Да?
И второе: сервер ,встроенный в Node, чем он лучше Apache + Nginx ?

[Elmo Sputterspark]

ericcartman, ты даже не представляешь, на сколько бессмысленный твой вопрос. Ты же пирожки с яблоками сравниваешь.

[Алексей Черемисин]

Зачем ставят nginx перед nodejs или любым другим web-сервером или приложением?
Nginx простой в конфигурировании и может очень просто, через набор правил перенаправлять запросы с одного приложения на другое, или в случае с nodejs, осуществлять балансировку между несколькими nodejs. Ну и что-то подкрутить в nginx гораздо легче, чем править конфиги в приложении.
Например у нас есть четырех-ядерный сервер, мы на нем запускаем 4 копии web-приложения, каждое из которых жрет один CPU. Впереди ставим nginx с балансировкой и получаем большой профит.
Ну и на nginx еще можно отдавать статику, а также лимитировать всякие загрузки, что в самом приложении иногда сделать очень тяжело или муторно, а в nginx это все есть из коробки.

[Александр]

Алексей Черемисин,

Ну и на nginx еще можно отдавать статику

Вы, к сожалению, не раскрыли суть: nginx разрабатывался специально для статики. Статику он отдает шедеврально-быстро, причем тратит на это ресурсов гораздо меньше, чем вышестоящее приложение (справедливо для 99% случаев) и, тем самым разгружает вышестоящее приложение.

[Алексей Черемисин]

Александр, что-то мне казалось это само-собой разумеющееся :-D

[Александр]

Алексей Черемисин, ну, мы тут стараемся для ТСа, а ему это, судя по вопросу, далеко не разумеющееся =(

[Ерлан Ибраев]

ericcartman, Смотря насколько нагружен.
А так обычно ngnix играет роль балансировщика (не веб сервера) в высоко нагруженных системах.
SpringBoot может выступать как сервером приложений (монолит), так и микросервисом.
Как микросеврис SpringBoot удобнее, чем как монолит.

[ericcartman]

Ерлан Ибраев,

SpringBoot может выступать как сервером приложений (монолит)

Мне казалось, что SpringBoot - это просто надстройка над Spring, уже содержащая необходимые библиотеки, чтобы можно было в 1 строчку написать сервис. Заодно там встроен и Tomcat, то есть сервер там Tomcat, просто запускается автоматом

[ericcartman]

Александр,

ну, мы тут стараемся для ТСа, а ему это, судя по вопросу, далеко не разумеющееся =(

Я очень благодарен вам, ребята, спасибо! Nginx нужен для отдачи статики в основном, так? Ну пусть так. И все же, как на Java технологиях сделать то же самое, что делает Node? уверен, это возможно.
В ноде есть асинхронный сервер говорите? Ну хорошо, значит берем асинхронный сервер заточенный под Java: Jetty? jooby? Дальше что? Spring можно юзать? или это все синхронно, и максимум чего можно там добиться, это запуститься в отдельном потоке

@RequestMapping
public Future<String> get(@RequestParam String input) {
  CompletableFuture<String> future = new CompletableFuture<>();
  return CompletableFuture.supplyAsync(() -> "in the background");

Это говорят не является асинхронным вызовом? А просто в отдельном потоке запускает?
ну а WebFlux - асинхронно?

[Евгений Калибров]

ericcartman, так оно и есть

[Ерлан Ибраев]

ericcartman, Да. Но если не капаться глубоко, может показаться, что SpringBoot сам все делает :-)

[Евгений Калибров]

ericcartman, а вот вам ссылка по поводу асинхронных энд-поинтов в спринге - carlmartensen.com/completablefuture-deferredresult...

[ericcartman]

Евгений Калибров, да, это уже писали тут:

@RequestMapping
public Future<String> get(@RequestParam String input) {
  CompletableFuture<String> future = new CompletableFuture<>();
  return CompletableFuture.supplyAsync(() -> "in the background");
}

Просто создает другой поток, а Нода как то отдает все ОС а сама занимается обслуживанием след клиента...

Че то меня уже терзают смутные сомнения, что проще Ноду выучить, чем разбираться, как на джаве сделать то же самое, может там просто невозможно это...

Answer 5

[Сергей Горностаев]

Во-первых, обрабатывает запросы не Node с Java, а сервера.

Нет.

Если создаем на Java, то ставим Nginx + Apache

Нет.

Правильно я думаю?

Нет. Вы абсолютно не представляете о чём пишите.

Comments

[ericcartman]

Запрос от юзера все же приходит к серверу. И сервер его обслуживает, при помощи всяких сторонних программ, написанных на Java, на Ноде и тп. Это разве неверно?

[Сергей Горностаев]

ericcartman, вы неправильно и поверхностно представляете процесс сетевого взаимодействия. Это мешает вам понять, что Java-программа может быть сервером сама по себе, в том числе асинхронным, и может принимать и обрабатывать запросы самостоятельно.

[ericcartman]

Сергей Горностаев, Согласен, я не знаю как устроено все на сервере. Но скажем простейший сервер я и сам написать могу. Просто прогу которая слушает сокет и обрабатывает запрос, пишет ответ. К сожалению, это мало помогает, поскольку уже все давно написано, надо просто знать как устроено и что там под капотом, не всмысле кода, а просто как и что происходит.
Ну вот получается простейший веб-рест-сервис я делаю так: ставлю томкэт, спринг. В методе, который отвечает за обработку запроса ( @RequestMapping) делаю запрос к базе. Все висит в это время. Я понимаю, что этот метод запускается в отдельном потоке сервером ( да?) но он подвис теперь. Как превратить это в асинхронный?

[Сергей Горностаев]

ericcartman, не использовать синхронный фреймворк Spring MVC на синхронном сервере Tomcat.

[ericcartman]

Сергей Горностаев,
Ну вот вроде синхронность спринга побеждаю таким образом:

@RequestMapping
public Future<String> get(@RequestParam String input) {
  CompletableFuture<String> future = new CompletableFuture<>();
  return CompletableFuture.supplyAsync(() -> "in the background");
}

Нормально?
Вместо томката что посоветуете? Jetty? Undertow?

[Сергей Горностаев]

ericcartman, CompletableFuture.supplyAsync() выполнит лямбда-выражение не асинхронно, а параллельно, в отдельном потоке.

Я советую вам написать с нуля свой http-сервер. Сначала однопоточный на сокетах. Потом сделать его многопоточным. Потом переписать в асинхронном варианте с java.nio.channels. Потом переписать ещё раз на Netty. Потом вдумчиво изучить Servlet API. Это даст вам базу, чтобы понимать как там все происходит.

[ericcartman]

Сергей Горностаев, Да, это дельный совет.

Сначала однопоточный на сокетах

Done

Потом сделать его многопоточным

Done

Потом переписать в асинхронном варианте с java.nio.channels

In Progress

Потом переписать ещё раз на Netty

To Do
---

Потом вдумчиво изучить Servlet API. Это даст вам базу, чтобы понимать как там все происходит

Обязательно. Собственно я в посте первом и написал, что все изучу/прочту и наши и буржуйские сайты. Просто хотелось бы сначала на пальцах, чтобы придали мне направление ( и уверенности)
Вот скажем эта статья: journaldev.com/2008/async-servlet-example
говориться, что асинхронно, но на деле опять просто поток создается.

Хотелось бы понять все же, что такое асинхронность Ноды и как сделать на Джаве такое же. Это же не то же самое, что поток запустить просто отдельный? Это отдать задачу ОС и ждать колбек? Или я ошибаюсь?

Если нетрудно, можно просто инструкцию: "чтобы было как Нода, бери такой-то асинхронный сервер, такой то асинхронный фреймворк и изучай" ( ну или Spring c WebFlux ) то есть я очень хочу изучить этот вопрос, прям не могу ))) просто хотелось бы знать, что я двигаюсь в правильном направлении.

[Сергей Горностаев]

ericcartman, в метафорах о видах многозадачности.

Грубо говоря, если 100 человек подключатся к приложению на Spring MVC, будет запущено 100 потоков, каждый из которых будет обслуживать своё соединение. Если 100 человек подключатся к приложению на Netty, поток останется один, в нём будет крутиться бесконечный цикл, проверяющий на каждой итерации наличие данных в каждом из 100 соединении и вызывающий обработчик, в случае необходимости.

Чтобы было как Нода, бери Netty и изучай.

[ericcartman]

Сергей Горностаев, Спасибо, понял, изучу Netty
Один вопрос остался: Netty - это фреймфорк ? Но не сервер ? то есть какой то сервер должен стоять впереди него. Подскажите, любой можно ставить? или только асинхронный? А над Netty хорошо бы Spring 5 и WebFlux ?

[Сергей Горностаев]

ericcartman, Netty это фреймворк для разработки асинхронных серверов. Перед сервером на Netty ставить ничего не требуется. И над ним что-то ставить тоже не надо. Если хочется асинхронности, но попроще, то можно взять Spring WebFlux. Правда, я не знаю, способен ли он решать C10k problem.