Wat is het verschil tussen de gebeurtenisgestuurde architectuur van Node.js en multi-threaded programmeren in andere talen?


Antwoord 1:

Zowel in het event-driven als het multi-threaded paradigma loopt de code binnen een besturingssysteemproces.

Wanneer het proces meerdere threads uitvoert, delen deze threads het procesgeheugen (adresruimte) zowel voor lezen als schrijven.

JavaScript dat Node.js aanstuurt, is ontworpen met één thread. Elke functie wordt gegarandeerd volledig uitgevoerd en er wordt geen andere JavaScript-code in het huidige proces uitgevoerd tijdens die functie. De natuurlijk asynchrone gebeurtenissen (netwerk, schijfinvoer-uitvoer, timers, andere hardware- en besturingssysteemgebeurtenissen) worden afgehandeld door de engine die de JavaScript-functies die zijn geregistreerd als handlers (of callbacks) voor deze gebeurtenissen toevoegt aan de wachtrij die moet worden uitgevoerd na de functies voor de wachtrij zijn voltooid.

In het multi-threaded paradigma voeren twee of meer threads code parallel uit, dus tijdens een functie-run kan een ander stuk code ook op een andere processorkern worden uitgevoerd, mogelijk naar dezelfde geheugenadressen gelezen of geschreven. Dit kan een inconsistente geheugenstatus tot gevolg hebben, tenzij speciale besturingssysteemmechanismen (synchronisatieprimitieven) door de code worden gebruikt om de toegang tot het gedeelde geheugen te beheren.



Antwoord 2:

Dit is een goede vraag: "Wat is het verschil tussen de gebeurtenisgestuurde architectuur van Node.js en multi-threaded programmeren in andere talen?".

We kunnen en moeten dit een beetje afbreken.

  • Node's event-driven architectuur.

Gebeurtenisgestuurde architectuur is niet exclusief voor Node, bijv. Tornado (Python), Vertx (Java), Akka (Scala), ReactiveX (meerdere talen).

  • Multi-threaded programmeren in andere talen.

Merk op dat JavaScript per ontwerp geen ondersteuning biedt voor meerdere threads. Hoewel het webwerkers ondersteunt, die, voor zover ik weet, als threads kunnen fungeren.

Dus event-driven is niet uniek voor Node en multi-threading kan worden gedaan in Node.

Dus er kunnen hier twee vragen zijn: "Wat is het verschil tussen event-driven versus multi-threading" en "Wat is het verschil tussen Node en andere talen (frameworks)"? Ik zal me op dit laatste concentreren, omdat dat de bedoeling van de vraag lijkt te zijn.

Ik zou zeggen wat Node speciaal maakt, is dat de auteur het heeft gemaakt om te voorkomen dat IO wordt geblokkeerd bij het bouwen van webapplicaties. De cultuur van de Node-gemeenschap is om de kracht van niet-blokkerende IO te benadrukken en erop voort te bouwen. U zult niet teveel bibliotheken van derden vinden die blokkerende oproepen uitvoeren. Als ontwikkelaar die Node gebruikt, is het onwaarschijnlijk dat u subtiele blokkeerbewerkingen in uw code tegenkomt. Terwijl in andere talen een naïeve ontwikkelaar per ongeluk zeer inefficiënte oproepen blokkeert, zoals het lezen van een databaseverbinding.

Anders dan dat, moet u echt lezen over meerdere modellen voor "concurrency" en de voor- en nadelen van elk begrijpen. Bonuspunten voor het waarderen waarom multi-threading zo lang acceptabel was.



Antwoord 3:

de conceptuele verschillen zijn vrij eenvoudig om je hoofd rond te wikkelen.

In een evenementgestuurde architectuur wordt uw programma uitgevoerd in een doorlopende lus met één thread (u kunt wat multithreading uitvoeren in een knooppunt, maar maak u daar nu geen zorgen over). Wanneer een evenement wordt gestart, staat er een taak op de stapel om te worden afgehandeld op het programma.

Multi-threaded architectuur verzendt over het algemeen een nieuwe thread wanneer deze op een actie moet wachten. Dus, u belt naar een database en u maakt een nieuwe thread aan de gang die alle dingen uitvoert die u nodig hebt en doet wat u moet doen en die de oorspronkelijke thread afsluiten of er weer bij aansluiten.

Beide methoden zijn erg nuttig voor verschillende dingen. Gebeurtenisgestuurd is geweldig voor gebruikersinterface en servers, omdat uw programma niet weet wanneer er zelfs een nieuw zal gebeuren en gebeurtenissen vaak in bursts komen. Hoewel inrijgen noodzakelijk is voor computationeel zware taken waarbij u een probleem in veel kleinere stukjes wilt opdelen (of u de limiet van uw enkele threaded lus nadert).