¿Cuál es la diferencia entre la arquitectura basada en eventos de Node.js y la programación multiproceso en otros idiomas?


Respuesta 1:

Tanto en el paradigma controlado por eventos como en el multihilo, el código se ejecuta dentro de un proceso del sistema operativo.

Cuando el proceso ejecuta múltiples hilos, estos hilos comparten la memoria del proceso (espacio de direcciones) tanto para leer como para escribir.

JavaScript que alimenta Node.js es de un solo subproceso por diseño. Se garantiza que cada función se ejecutará hasta su finalización, y ningún otro código JavaScript en el proceso actual se ejecutará durante la ejecución de esa función. Los eventos naturalmente asíncronos (red, entrada-salida de disco, temporizadores, otros eventos de hardware y sistema operativo) son manejados por el motor que agrega las funciones de JavaScript registradas como controladores (o devoluciones de llamada) para estos eventos a la cola del bucle de eventos que se ejecutará después las funciones en frente de la cola han terminado.

En el paradigma de subprocesos múltiples, dos o más subprocesos ejecutan código en paralelo, por lo que durante la ejecución de una función, un código diferente también puede ejecutarse en un núcleo de procesador diferente, posiblemente leyendo o escribiendo en las mismas direcciones de memoria. Esto puede provocar un estado inconsistente de la memoria a menos que el código utilice mecanismos especiales del sistema operativo (primitivas de sincronización) para administrar el acceso a la memoria compartida.



Respuesta 2:

Esta es una buena pregunta, "¿Cuál es la diferencia entre la arquitectura basada en eventos de Node.js y la programación multiproceso en otros idiomas?".

Podemos y debemos desglosar esto un poco.

  • La arquitectura basada en eventos de Node.

La arquitectura dirigida por eventos no es exclusiva de Node, por ejemplo, Tornado (Python), Vertx (Java), Akka (Scala), ReactiveX (varios idiomas).

  • Programación multiproceso en otros idiomas.

Tenga en cuenta que JavaScript, por diseño, no admite múltiples hilos. Aunque es compatible con los trabajadores web, que, hasta donde yo sé, pueden funcionar como hilos.

Por lo tanto, el manejo de eventos no es exclusivo de Node y se pueden realizar subprocesos múltiples en Node.

Por lo tanto, puede haber dos preguntas aquí: "¿Cuál es la diferencia entre eventos y múltiples subprocesos" y "¿Cuál es la diferencia entre Node y otros idiomas (marcos)". Me centraré en lo último, ya que parece ser la intención de la pregunta.

Diría que lo que hace que Node sea especial es que el autor lo creó con el propósito de evitar el bloqueo de IO al crear aplicaciones web. La cultura de la comunidad Node es enfatizar y construir sobre la fuerza de las IO sin bloqueo. No vas a encontrar demasiadas bibliotecas de terceros que realizan llamadas de bloqueo. Como desarrollador que usa Node, es poco probable que se encuentre con sutiles operaciones de bloqueo en su código. Mientras que en otros idiomas, un desarrollador ingenuo podría realizar accidentalmente llamadas de bloqueo altamente ineficientes, como leer desde una conexión de base de datos.

Aparte de eso, realmente debería leer sobre varios modelos de "concurrencia" y comprender los pros y los contras de cada uno. Puntos de bonificación por apreciar por qué el subprocesamiento múltiple fue aceptable durante tanto tiempo.



Respuesta 3:

Las diferencias conceptuales son bastante fáciles de entender.

En la arquitectura controlada por eventos, su programa se ejecuta en un bucle continuo de un solo subproceso (puede hacer algunos subprocesos múltiples en el nodo, pero no se preocupe por eso ahora). Cuando se dispara un evento, hay un trabajo en la pila de llamadas para ser tratado en el tiempo libre del programa.

La arquitectura de subprocesos múltiples generalmente distribuye un nuevo subproceso cuando debe esperar una acción. Por lo tanto, realiza una llamada a una base de datos y activa un nuevo hilo que llevará a cabo todas las cosas que necesita y hará lo que necesite y concluirá o volverá a unirse al hilo original.

Ambos métodos son muy útiles para diferentes cosas. El evento controlado es ideal para la interfaz de usuario y los servidores porque su programa no sabe cuándo ocurrirá un nuevo evento y, a menudo, los eventos vendrán en ráfagas. Si bien el enhebrado es necesario para trabajos computacionalmente pesados ​​en los que desea dividir un problema en partes mucho más pequeñas (o se está acercando al límite de su bucle de un solo hilo).