Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient.
вот и мыNodeВы можете увидеть такое предложение на официальном сайте .Это предложение отражает несколько основных характеристик узла.Давайте рассмотрим его подробнее.
1. Node.js® — это среда выполнения JavaScript, построенная на движке Chrome V8 JavaScript.
Когда мы изучаем что-то, сначала нам нужно знать, для чего оно используется. Раньше я думал, что nodejs — это фреймворк, когда я слышал об узле Когда я узнал о узле, я подумал, что это просто javascript на стороне сервера, но правда ли это? Давайте посмотрим на приведенную выше фразу. Node.js — это среда выполнения javascript, построенная на движке Chrome V8. Возможно, вы не понимаете, что такое среда выполнения. На самом деле, в моем понимании, она похожа на Java JRE (Java Runtime Environment). Она предоставляет среду API и рабочую среду. , так что наш js может работать на стороне сервера, и в то же время он предоставляет API-интерфейсы, которые могут работать с файловой системой, сетью и т. д. Это прорыв, который очень взволновал интерфейсных инженеров.
2. Node.js использует модель неблокирующего ввода-вывода, управляемую событиями, что делает его легким и эффективным.
Следующее предложение отражает несколько основных характеристик Node:
- управляемый событиями
- Неблокирующая модель ввода/вывода
- Один поток (в нем не упоминается, но я думаю, что это тоже большая фича)
Прежде чем говорить о вышеуказанных функциях, давайте посмотрим, часто видим, как кто-то говорит, что узел имеет дело с высоким параллелизмом, тогда интенсивный ввод-вывод является преимуществом, тогда мой вопрос: I/O Интенсивный ввод-вывод, почему после поиска информации, обнаружил, что интенсивный ввод-вывод соответствует интенсивному процессору, мы можем взглянуть на разницу между ними.
- Интенсивный ввод-вывод: если большая часть времени, которое программа потребляет, используется для операций ввода-вывода с файлами, операций с базой данных или сетевых операций, а также операций доступа, то мы можем сказать, что это операция ввода-вывода. /O интенсивный оказание услуг.
- Интенсивная нагрузка на ЦП: если время программы расходуется на вычисления, распаковку, сжатие и т. д., которые требуют ЦП для выполнения операций, то можно сказать, что это служба с интенсивным использованием ЦП.
Что ж, прочитав разницу между ними, мы можем понять, почему Node подходит для веб-разработки.Подумайте о том, какие операции мы выполняем, когда разрабатываем веб-разработку, чтение статических ресурсов, выборку, сетевые операции, а также добавление, удаление и изменение базы данных. мы можем обнаружить, что операции ввода-вывода являются наиболее трудоемкими операциями в веб-сценариях. Теперь, когда скорость процессора высока, скорость выполнения инструкций очень высока, но выполнение операций ввода-вывода по-прежнему занимает очень много времени. Мы видим, что Интернет — это типичный сервис с интенсивным вводом-выводом, так почему мы говорим, что Node очень подходит для веб-сценариев? Поговорим позже.
Давайте взглянем на ситуацию с высокой степенью параллелизма. В книге «Введение в NodeJS» мы можем увидеть мнение г-на Пак Линга о сервисной модели. Я думаю, что это очень понятно. Давайте посмотрим:
-
Каменный век: синхронизация
Давным-давно наши серверы были синхронными и могли обслуживать только один запрос за раз, например, в ресторане мы наняли повара и официанта, сейчас у нас только один повар, поэтому мы можем принимать заказы только от один гость. Мы можем продолжать заказывать следующего клиента после завершения заказа предыдущего клиента. Мы все знаем, что такая эффективность определенно не будет работать, поэтому происходит следующая эволюция. -
Бронзовый век: процесс воспроизводства
Мы можем воспроизвести процесс, и один процесс может обслуживать один запрос, так что мы можем обслуживать несколько запросов, но мечта очень красивая, а идеал очень полный. Продолжая использовать приведенный выше пример, наш ресторан вырос, и один повар уже слишком занят. В это время, что мы можем придумать? Если мы пригласим больше поваров, мы также сможем решить проблему нескольких гостей, но мы, подумав об этом, если вы наймете столько поваров, кто будет платить зарплату?Это слишком дорого. Это тоже недостаток репликации процессов.Репликация процессов стоит очень дорого.Мы должны реплицировать состояние в процессе,и в процессе будет много одинаковых состояний,что приведет к потерям,так что же нам делать? -
Серебряный век: многопоточность
Мы думаем с вышеуказанной точки зрения, что наша медленная операция также является операцией чтения, нам не нужен очень сильный повар, подойдет маленький повар, поэтому мы уволили повара и наняли нескольких на деньги повара. готовить, чтобы наш маленький повар тоже умел готовить, поэтому после того, как мы получаем заказ, мы готовим его для этих маленьких поваров. Однако количество поваров у одного из наших официантов ограничено.Мы можем себе представить, что операция заказа происходит очень быстро.Возможно официант начинает играть после заказа,и ждет пока повар будет готов его подать,что вызывает ЦП В то же время для многопоточности занимаемое пространство памяти, переключение потоков и другие вопросы не могут быть полностью удовлетворены. -
Золотой век: события
Чтобы решить проблему высокого параллелизма, появилась модель обслуживания, управляемая событиями, так же как Node и Nginx оба управляются событиями, использование одного потока позволяет избежать ненужных накладных расходов на память и переключения контекста. Глядя на приведенный выше пример, по сути, мы нанимаем официанта, стоим в очереди, чтобы позвонить по номеру, а затем обслуживаем следующего гостя, нам не нужно ждать, пока блюдо этого гостя будет готово, прежде чем обслуживать следующего. повар готов, мы прямо говорим официанту, что блюдо готово. , а потом звоним по номеру, клиент придет и заберет.
один поток
Заимствование учителя рисования, на самом деле, эта цифра на самом деле мы можем очень четко видеть, что мы JSодин потокДа, то же самое верно и в узле.После того, как мы получим N запросов от клиента, мы напрямую откладываем трудоемкие операции в пул потоков для работы.Использование одного потока может избежать потребления памяти и переключения контекста. В то же время мы используем управление событиями, чтобы уведомить основной поток в виде события после завершения операции ввода-вывода последующего потока, а затем вернуть результат.
На самом деле, когда дело доходит до этого, некоторые люди так же путаются, как и я. Разве не сказано, что nodejs является однопоточным, почему появляется многопоточность. На самом деле, если мы подумаем об этом, мы сможем понять, что если nodejs полагается только на однопоточную работу, как он может выполнять веб-сервисы с высокой степенью параллелизма? Можно сказать, что один поток nodejs предназначен для основного процесса, в то время как асинхронные операции, операции ввода-вывода и т. д. планируются базовой многопоточностью операционной системы.Один поток nodejs отвечает только за планирование , точно так же, как официант в ресторане. Точно так же они отвечают только за прием заказов, а все повара - это повара на заднем плане. Кроме того, nodejs является однопоточным, так как же использовать текущий многоядерный процессор? На самом деле, нам не о чем беспокоиться, Node учла эту ситуацию, и у nodejs есть специальный модуль для работы.
управляемый событиями
Так что же такое событие? На самом деле, когда мы занимаемся фронтенд-разработкой, мы часто имеем дело с событиями, такими как ajax, мы инициируем запрос, затем слушаем событие и после успеха выполняем обратный вызов. На самом деле, это также важная функция узла.Подобно тому, как узел получает запрос, после того, как узел получает запрос, он передает соответствующую операцию ввода-вывода в операционную систему, а затем прослушивает события. операция завершена, срабатывает событие. Выполните обратный вызов, чтобы получить данные.
Неблокирующий ввод-вывод
Блокировка ввода-вывода означает, что когда пользователь отправляет операцию чтения файла, процесс будет заблокирован до тех пор, пока все данные для чтения не будут готовы для возврата пользователю. А как насчет неблокирующего ввода-вывода, то есть когда пользователь инициирует операцию чтения файла, функция немедленно возвращается без какого-либо ожидания, и процесс продолжает выполняться.Когда операция чтения завершена, основной процесс переходит к получению данные. Как программа узнает, что данные для чтения готовы? Самый простой метод — это опрос, который также упоминается в книге учителя Пак Линга.
Я только что кратко изучил узел сегодня. Если что-то не так, пожалуйста, дайте мне еще совет. Я только изучил nodejs.