Qual è la differenza tra l'architettura basata sugli eventi di Node.js e la programmazione multi-thread in altre lingue?


Risposta 1:

Sia nel paradigma basato su eventi che in quello multi-thread, il codice viene eseguito all'interno di un processo del sistema operativo.

Quando il processo esegue più thread, questi thread condividono la memoria del processo (spazio degli indirizzi) sia per la lettura che per la scrittura.

JavaScript che alimenta Node.js è a thread singolo in base alla progettazione. Ogni funzione è garantita per il completamento e nessun altro codice JavaScript nel processo corrente verrà eseguito durante tale funzione. Gli eventi naturalmente asincroni (rete, input-output del disco, timer, altri eventi hardware e del sistema operativo) sono gestiti dal motore che aggiunge le funzioni JavaScript registrate come gestori (o callback) per questi eventi nella coda del ciclo di eventi da eseguire dopo le funzioni davanti alla coda sono terminate.

Nel paradigma multi-thread, due o più thread eseguono il codice in parallelo, quindi durante l'esecuzione di una funzione può essere eseguito anche un diverso pezzo di codice su un diverso core del processore, eventualmente leggendo o scrivendo sugli stessi indirizzi di memoria. Ciò può comportare uno stato incoerente della memoria a meno che il codice non utilizzi speciali meccanismi del sistema operativo (primitive di sincronizzazione) per gestire l'accesso alla memoria condivisa.



Risposta 2:

Questa è una buona domanda, "Qual è la differenza tra l'architettura basata sugli eventi di Node.js e la programmazione multi-thread in altre lingue?".

Possiamo e dovremmo scomporlo un po '.

  • Architettura guidata dagli eventi del nodo.

L'architettura basata su eventi non è esclusiva di Node, ad esempio Tornado (Python), Vertx (Java), Akka (Scala), ReactiveX (più lingue).

  • Programmazione multi-thread in altre lingue.

Si noti che JavaScript, di progettazione, non supporta più thread. Sebbene supporti i webworker, che, per quanto ne so, possono funzionare come thread.

Pertanto, il event-driven non è univoco per Node e il multi-threading può essere eseguito in Node.

Quindi ci possono essere due domande qui: "Qual è la differenza tra event-driven vs multi-threading" e "Qual è la differenza tra Node e altre lingue (framework)". Mi concentrerò su quest'ultimo poiché questo sembra essere l'intento della domanda.

Direi che ciò che rende speciale Node è che l'autore l'ha creato allo scopo di evitare il blocco di IO durante la creazione di applicazioni web. La cultura della community di Node è quella di enfatizzare e sviluppare la forza di IO non bloccanti. Non troverai troppe librerie di terze parti che eseguono il blocco delle chiamate. Come sviluppatore che utilizza Node, è improbabile che si verifichino sottili operazioni di blocco nel codice. Mentre in altre lingue, uno sviluppatore ingenuo potrebbe accidentalmente eseguire chiamate di blocco altamente inefficienti come la lettura da una connessione al database.

Oltre a ciò, dovresti davvero leggere su più modelli di "concorrenza" e comprendere i pro e i contro di ciascuno. Punti bonus per apprezzare perché il multi-threading era accettabile per così tanto tempo.



Risposta 3:

le differenze concettuali sono abbastanza facili da avvolgere la testa.

Nell'architettura basata sugli eventi, il tuo programma viene eseguito in un loop continuo a thread singolo (puoi eseguire alcuni thread multipli nel nodo, ma non preoccuparti di questo in questo momento). Quando viene generato un evento, un lavoro viene inserito nello stack di chiamate per essere gestito a piacimento dei programmi.

L'architettura multi-thread generalmente invia un nuovo thread quando deve attendere un'azione. Quindi, si effettua una chiamata a un database e si crea un nuovo thread che eseguirà tutte le cose necessarie e farà ciò di cui si ha bisogno e si concluderà o si ricongiungerà al thread originale.

Entrambi questi metodi sono molto utili per cose diverse. Event driven è ottimo per l'interfaccia utente e i server perché il tuo programma non sa quando accadrà un nuovo pareggio e spesso gli eventi arriveranno a raffica. Mentre il threading è necessario per lavori computazionalmente pesanti in cui si desidera suddividere un problema in pezzi molto più piccoli (o si sta avvicinando il limite del singolo loop con thread).