После прочтения нескольких сообщений об управляемых событиями и nodejs, единственные преимущества, которые я вижу, - это то, что управляемое событие предотвращает выделение памяти для потоков и заменяет опрос уведомлениями там, где это возможно.Какая магия в отношении событий?
Другие преимущества все спорно:
программа Multithread легче делать ошибки, чем один поток.
Аргумент: для веб-приложений, запросы независимы друг от друга, если функции обработчика не имеют побочного эффекта; если все части ввода-вывода обрабатываются серверами баз данных, не стоит беспокоиться о многопоточности.
Подход, управляемый событиями, не блокирует IO и, следовательно, может обрабатывать больше запросов. Это преимущество кажется самой важной особенностью управляемого событиями. И в this пример сравнивается с врачами, которые, я думаю, не являются правильными.
Аргумент: В примере с врачами регистратор не ждет, пока пациент заполнит формы, но будет обслуживать других пациентов, пока предыдущий пациент заполняет форму. Это вводящий в заблуждение пример.
a. Если мы интерпретируем пациентов как клиентов, отправляющих запрос на сервер. Сервер, конечно же, не будет блокировать для клиентов заполнение форм в их собственном браузере. И когда клиенты заканчивают формы и отправляют http POST на сервер, тогда сервер начнет работать. Веб уже был управляемой событиями системой до того, как nodejs существует. Таким образом, этот пример недействителен для объяснения программирования на стороне сервера.
b. Кто-то сказал бы, что мы должны интерпретировать пациента, заполняющего формы, в качестве интенсивных операций на стороне сервера. Но разница в том, что мы не платим пациентам за заполнение форм, но мы платим за интенсивные операции ввода-вывода.
Итак, я утверждаю, что даже временные операции не блокируют ваш текущий поток, будет заблокирован какой-либо другой поток или сервер процессов или базы данных. Я вижу много раз, что nodejs может обслуживать 10k параллельных подключений, потому что он не блокирует. Я бы сказал, что, если не хватает других потоков или процессов или серверов для обработки части времени, это было бы невозможно.
В этом случае, событийное это не более, чем балансировки нагрузки с помощью Nginx, за исключением того, что балансировка нагрузки Балансирует запрос к приложениям, а событийная балансы запрос отнимает много времени операции, которая перемещает балансировки нагрузки слоя в обратном направлении. И единственным преимуществом этого является то, что я упомянул в начале этого вопроса: 1. он избегает выделения памяти для потоков. 2. по возможности заменяет опрос уведомлениями.
Спасибо, что прочитали этот вопрос, мой вопрос: правильно ли я понимаю? Любые ошибки, которые я сделал в своих аргументах?
Когда дело доходит до этого, вам все равно придется писать код, который обрабатывает «события». То, что вы, кажется, навязали, - это стиль, когда вам нужно больше сосредоточиться на существе. '" Является ли мой код удобным, надежным, надежным? "' – ChaosPandion
Проверьте ответ на этот вопрос, поскольку я думаю, что это может улучшить ваше понимание: http://stackoverflow.com/questions/3629784/how-is-node-js-inherently -faster-when-it-still-relies-on-threads-internal – phairoh
@Phairoh Спасибо за информацию. Поэтому я думаю, что в основном я понимаю это правильно. Выполняя async и callbacks, планирование задач более эффективно, поскольку меньше опроса больше уведомлений. –