Какова цель/цель Ruby EventMachine, Python Twisted или JavaScript Node.js?

Я не понимаю, какую проблему решают эти рамки. Являются ли они заменой для HTTP-сервера, такого как Apache HTTPD, Tomcat, Mongrel и т.д.? Или они больше? Почему я могу использовать их... некоторые примеры в реальном мире? Я видел бесконечные примеры чатов и широковещательных сервисов, но не вижу, как это отличается от, например, настройки программы Java для открытия сокетов и отправки потока для каждого запроса.

Я думаю, что я понимаю неблокирующий ввод-вывод, но я не понимаю, как это отличается от многопоточного веб-сервера. Для Node.js я читал, что он имеет только один поток и что это может быть более эффективным, чем манипулирование несколькими потоками, но является ли это единственной разницей между этими фреймворками и традиционным веб-сервером?

Ответ 1

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

Например, если вы собираетесь написать многопользовательскую видеоигру, "настроить Java-программу... для отправки потока для каждого запроса", вероятно, не вариант; жонглирование тем, что многие потоки феноменально сложны, и он работает плохо. Не говоря уже о том, что "просто порождать пучок потоков" отсутствует куча инструментов управления, которые Twisted et. и др. имеют, например, twistd, который обрабатывает ведение журнала, демонанизацию, запуск и завершение работы и т.д.

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

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

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

Ответ 2

Действительно, фреймворки, основанные на событиях, подходят для ситуаций, когда у вас много операций io и меньше cpu, но это определяет большинство веб-страниц, потому что они ждут db. Другими примерами являются чаты или видео, такие как youtube - один стек позволяет одновременно обслуживать большее количество клиентов. Серверы, основанные на событиях, могут обрабатывать десятки или сотни тысяч подключенных клиентов, где такое количество потоков будет убивать машину. Они менее эффективны, если у вас действительно есть какая-то обработка.

Ответ 3

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