В чем смысл / цель Ruby EventMachine, Python Twisted или JavaScript Node.js? - PullRequest
26 голосов
/ 29 мая 2010

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

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

Ответы [ 3 ]

19 голосов
/ 29 мая 2010

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

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

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

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

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

6 голосов
/ 29 мая 2010

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

4 голосов
/ 29 мая 2010

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

...