Node.js utiliza E/S sin bloqueo, el mecanismo que le permite tener un solo hilo de ejecución ejecutando su programa. Si Node.js tuviera que usar el bloqueo de E/S, no podría hacer nada más mientras espera que se complete una E/S. A continuación se muestra una imagen de ejemplo de lo que sucede cuando Node.js necesita usar E/S de bloqueo:
Operación de E/S con bloqueo frente a sin bloqueo
El proyecto Node.js incluye un motor de JavaScript, un bucle de eventos y una capa de E/S. A menudo se lo conoce como un servidor web sin bloqueo.
Nota: «E/S» generalmente se refiere a la interacción entre el disco del sistema y la red y es compatible con libuv.
¿Por qué el bloqueo de las operaciones de E/S era un problema?
En los lenguajes de programación tradicionales como C y PHP, todas las instrucciones están bloqueadas de forma predeterminada a menos que las «habilite» explícitamente para realizar operaciones asíncronas. Digamos que realiza una solicitud de red para leer algunos datos o puede querer leer algún archivo y desea mostrar sus datos al usuario, pero luego se bloquea la ejecución de dicho hilo, hasta que la respuesta de respuesta esté lista pero para resolver esto El problema del bloqueo del flujo de E/S JavaScript le permite crear código asíncrono y sin bloqueo de una manera muy sencilla, mediante el uso de un único subproceso, funciones de devolución de llamada y programación basada en eventos.
¡Veamos con un ejemplo para entender mejor esto!
Ejemplo 1: El siguiente ejemplo usa la función readFileSync() para leer archivos y demostrar el bloqueo en Node.js:
Javascript
// The fs module provides access to
// interact with the file system.
const fs = require('fs');
const data = fs.readFileSync('/sample.txt');
/*This line of code will block the main thread,
until the file is read.*/
console.log(data);
console.log("This is a beautiful message");
console.log("This code is doing some great work")
Producción:
This data is from the text file This is a beautiful message This code is doing some great work
Explicación: en el ejemplo anterior, vemos que el método de bloqueo se ejecuta sincrónicamente [ o puede decir línea por línea]. Ahora ves que cada línea de código espera a que se ejecute la línea anterior para el resultado, lo que puede convertirse en un problema, especialmente con operaciones lentas como lectura o actualización o puedes decir operaciones relacionadas con E/S, porque cada línea bloquea la ejecución de el resto del código y decimos que es código de bloqueo ya que la siguiente línea de código solo se puede ejecutar después de que la anterior haya terminado y porque la forma en que se diseñó Node.js resultó ser un gran problema que nos lleva a la Los métodos sin bloqueo que ejecutan el código de forma asincrónica significa que el código no se ejecuta línea por línea, sino que se utilizan devoluciones de llamada para lograr este comportamiento sin bloqueo. A continuación se muestra el mismo ejemplo que usamos anteriormente para describir el comportamiento síncrono, pero ahora lo hemos modificado usando la función de devolución de llamada para que sea asíncrono.
Ejemplo 2: El siguiente ejemplo usa la función readFile() para leer archivos y demostrar el no bloqueo en Node.js
Javascript
const fs = require('fs');
// This piece of code doesn't block the main thread
// but will run after the file is completely read.
fs.readFile('/sample.txt', (err, data) => {
if (err) throw err;
else {
// Call-back function
console.log(data);
}
});
console.log("This is a beautiful message");
console.log("This code is doing some great work")
Producción:
This is a beautiful message This code is doing some great work This data is from the text file
Nota: En el ejemplo anterior, vemos que en el método sin bloqueo, la consola, en realidad, imprime los mensajes antes que el contenido del archivo. Esto se debe a que el programa no espera a que la función readFile() regrese y pase a la siguiente operación para que sea asincrónica. Y cuando la función readFile() regresa, imprime el contenido del archivo de texto.
¿Cómo resolvió el problema node.js?
Es posible que haya escuchado sobre este concepto llamado E/S sin bloqueo y cómo Node.js lo usa para resolver el problema del bloqueo de llamadas y para ejecutarse súper rápido, pero ¿qué es la E/S sin bloqueo y por qué ayuda? ? Comprenderemos esto más adelante, pero primero, debe comprender cómo funcionan los servidores y los subprocesos en el camino y cómo los servidores manejan las requests. Antes de pasar a node.js, hablemos de los servidores y los subprocesos como descripción general.
El servidor no es más que lo que toma las requests y hace un trabajo para calcular la respuesta necesaria para devolverla. Por ejemplo, cuando llega a google.com, envía una solicitud HTTP a un servidor de Google que calcula la respuesta HTML que debería ver en la página de inicio de su navegador. Pero en el interior, el servidor divide el trabajo entre uno o más subprocesos internos [ un subproceso puede considerarse como un solo trabajador ], procesando los requisitos y requests de otros usuarios al mismo tiempo sin bloquear el subproceso principal.
Podemos explorar esto usando un restaurante como analogía, aquí en un restaurante frecuentado solo hay un mesero porque no es muy popular, el cliente tiende a venir uno por uno, el mesero sirve a cada fiesta antes de pasar a la siguiente como el mesero termina una fiesta, está esperando más clientes o cambiando a otro, este ejemplo funciona bien para describir servidores.
Síncrono vs Asíncrono
El restaurante que acabamos de mencionar es como un servidor con la frecuencia de recibir requests y el mesero es como un hilo y la solicitud es como clientes .
Ahora imagina si dos personas entran al restaurante al mismo tiempo y un mesero solo puede atender a una persona a la vez, pero ese no es el caso, mira mientras los clientes están ocupados con el menú no necesitan tu ayuda, entonces el mesero puede moverse o puede decir cambiar de mesa y ayudar a ambos al mismo tiempo, ya que cada uno necesita ayuda sin que alguien se quede de pie o espere su turno.
Bueno, qué sucede cuando ambos amigos necesitan ayuda al mismo tiempo, entonces uno debe esperar un poco más que si es solo una fiesta. La idea básica aquí es que un mesero puede atender a más de una mesa a la vez porque cada mesa tiene algún tiempo de inactividad.
¡Todo esto se aplica a los servidores y al Node JS también!
Al igual que una tabla, necesitamos ayuda con el procesamiento de requests de tiempo, también hay una parte que requiere atención activa y la parte que no requiere atención activa, generalmente se denomina trabajo de CPU, ya que requiere la unidad central de procesamiento de la computadora donde pasamos el tiempo. pensar y calcular resultados.
El trabajo de la CPU requiere un subproceso para procesarlo como una tabla que requiere un servidor para procesarlo, pero la parte que no requiere atención de activación se llama E/S porque estaba esperando que algo más proporcionara una entrada o enviara una salida.
Aquí está la parte de la salida, así como el camarero puede ahorrar tiempo al cambiar la mesa, el mismo bloqueo permite que el subproceso sabotee el tiempo al cambiar la solicitud, cuando una solicitud realiza una E/S, aumenta en gran medida la cantidad de trabajo efectivo de la E/ ¡Oh puede hacer!
Nota: Entonces, la solución a este problema en node.js es usar código asíncrono sin bloqueo y Node.js usa un bucle de eventos para esto.
Bucle de eventos de E/S sin bloqueo
Cuando se necesitan datos, Node.js registra una devolución de llamada y envía la acción a este bucle de eventos. La devolución de llamada se llama cuando los datos están disponibles. Básicamente, estamos descargando la gran carga de trabajo para ejecutarla en segundo plano, y luego, cuando el trabajo finaliza, se llama a una función de devolución de llamada para procesar el resultado, lo guardamos antes, y durante este tiempo el resto del código aún es ejecutable mientras el La tarea pesada actualmente bloqueada se está ejecutando en segundo plano.
En una palabra:
Todo se ejecuta en paralelo, excepto su código y siempre tratamos de pasar una función de devolución de llamada que se llamará una vez que terminemos con la tarea y continuemos con el procesamiento. No esperamos a que esto acabe para seguir con el resto.