java - Entendiendo NodeJS y IO sin bloqueo
node.js nonblocking (3)
A pesar de que node.js ha existido por algunos años, su modelo de desempeño es todavía un poco misterioso.
Hace poco empecé un blog y decidí que el modelo node.js sería un buen primer tema, ya que yo también quería entenderlo mejor y sería útil para otros compartir lo que aprendí. Aquí hay un par de artículos que escribí que explican los conceptos de alto nivel y algunas compensaciones:
Por lo tanto, recientemente me han inyectado el virus Node, que se está propagando en el mundo de la programación muy rápido.
Me fascina su enfoque de "IO sin bloqueo" y, de hecho, he probado un par de programas por mi cuenta.
Sin embargo, no entiendo ciertos conceptos en este momento.
Necesito respuestas en términos simples (alguien que viene de un fondo de Java)
1. Multiproceso y no bloqueo de IO.
Consideremos un escenario práctico. Digamos, tenemos un sitio web donde los usuarios pueden registrarse. A continuación se muestra el código.
..
..
// Read HTTP Parameters
// Do some Database work
// Do some file work
// Return a confirmation message
..
..
En un lenguaje de programación tradicional, lo anterior sucede de manera secuencial. Y, si hay varias solicitudes de registro, el servidor web crea un nuevo hilo y el resto es historia. Por supuesto, los programadores pueden crear sus propios hilos para trabajar en la Línea 2 y en la Línea 3 simultáneamente.
En Node, según tengo entendido, las líneas 2 y 3 se ejecutarán en paralelo mientras que el resto del programa se ejecutará y el intérprete sondeará las líneas 2 y 3 cada ''x'' ms.
Ahora, mi pregunta es, si Node es un lenguaje de un solo hilo, ¿cuál es el trabajo de las líneas 2 y 3 mientras se está ejecutando el resto del programa?
2. escalabilidad
Hace poco leí que LinkedIn ha adaptado Node como back-end para sus aplicaciones móviles y ha visto mejoras masivas.
¿Alguien puede explicar cómo ha hecho tal diferencia?
3. Adaptación en otros lenguajes de programación.
Si las personas afirman que Node está haciendo una gran diferencia en lo que respecta al rendimiento, ¿por qué otros lenguajes de programación no han adaptado este paradigma de IO sin bloqueo?
Estoy seguro de que me estoy perdiendo algo. Sólo si me puede explicar y guiarme con algunos enlaces, sería útil.
Gracias.
Q1. "¿En qué consiste el trabajo de las líneas 2 y 3 mientras se está ejecutando el resto del programa?" Respuesta: "Nada". Cada una de las líneas 2 y 3 comienzan sus tareas respectivas, pero esas tareas no se pueden hacer de inmediato porque (por ejemplo) los sectores de disco requeridos todavía no están cargados, por lo que el sistema operativo realiza una llamada al disco para obtener esos sectores. "No pasa nada" (el nodo continúa con su próxima tarea) hasta que el subsistema de disco (más tarde) emita una interrupción para informar que están listos, en cuyo punto el nodo devuelve el control a las líneas 2 y 3.
Q2. El no bloqueo de un solo hilo no dedica casi recursos a cada conexión entrante (solo algunos datos de mantenimiento del socket conectado). Es muy eficiente la memoria. Los servidores web tradicionales "bifurcan" un proceso completamente nuevo para manejar cada nueva conexión, lo que significa hacer una copia enorme de cada bit de las variables de código y datos necesarias, y dividir el tiempo de la CPU para tratar todo esto. Eso es un desperdicio masivo de recursos. Por lo tanto, si su carga es una gran cantidad de conexiones inactivas en espera de cosas, como lo fueron las suyas, el nodo tiene más sentido.
Q3. casi todos los lenguajes de programación ya tienen E / S sin bloqueo si desea usarlo. Nodo no es un lenguaje de programación, es un servidor web que ejecuta javascript y usa E / S sin bloqueo (por ejemplo: personalmente escribí mi propia cosa idéntica hace 10 años en perl, al igual que google (en C) cuando empezaron, y Estoy seguro de que muchas otras personas también tienen servidores web similares). La E / S no bloqueante no es la parte difícil: lograr que el programador entienda cómo usarla es la parte difícil. Sucede que Javascript funciona bien para eso, porque esos programadores ya están familiarizados con la programación de eventos.
Se hizo una pregunta similar y probablemente contiene toda la información que está buscando: cómo funciona el modelo de E / S sin bloqueo de un solo hilo en Node.js
Pero voy a cubrir brevemente sus 3 partes:
1.
Las líneas 2 y 3 en una forma muy simple podrían verse como:
db.query (..., function (query_data) {...});
fs.readFile (''/ path / to / file'', function (file_data) {...});
Ahora la función (query_data) y la función (file_data) son devoluciones de llamada . Las funciones db.query y fs.readFile enviarán las solicitudes de E / S reales, pero las devoluciones de llamada permiten que el procesamiento de los datos de la base de datos o del archivo se retrase hasta que se reciban las respuestas. Realmente no "sondea las líneas 2 y 3". Las devoluciones de llamada se agregan a un bucle de eventos y se asocian con algunos descriptores de archivo para sus respectivos eventos de E / S. A continuación, sondea los descriptores de archivo para ver si están listos para realizar E / S. Si lo son, ejecuta las funciones de devolución de llamada con los datos de E / S.
Creo que la frase "Todo funciona en paralelo, excepto tu código" lo resume bien. Por ejemplo, algo como "Leer parámetros HTTP" se ejecutaría secuencialmente, pero las funciones de E / S como en las líneas 2 y 3 se asocian con devoluciones de llamada que se agregan al bucle de eventos y se ejecutan más adelante. Básicamente, el punto es que no tiene que esperar a la E / S.
2.
Debido a lo explicado en 1., Node se adapta bien a las solicitudes intensivas de E / S y permite que muchos usuarios se conecten simultáneamente. Es un solo hilo, por lo que no necesariamente se adapta bien a las tareas intensivas de CPU.
3.
Este paradigma se ha utilizado con JavaScript porque JavaScript admite las devoluciones de llamada, los bucles de eventos y los cierres que facilitan esta tarea. Esto no es necesariamente cierto en otros idiomas.
Puede que esté un poco alejado, pero esta es la esencia de lo que está sucediendo.