Mitä eroa Node.js: n tapahtumavetoisella arkkitehtuurilla ja monisäikeisellä ohjelmoinnilla muilla kielillä on?


Vastaus 1:

Sekä tapahtumavetoisessa että monisäikeisessä paradigmassa koodi kulkee käyttöjärjestelmäprosessin sisällä.

Kun prosessi suorittaa useita säikeitä, nämä säieet jakavat prosessimuistin (osoitetilan) sekä lukemista että kirjoittamista varten.

Node.js: n käyttävä JavaScript on yksinkertaisella suunnittelulla. Jokaisen toiminnon on taattu suorittavan loppuun saakka, eikä mitään muuta JavaScriptin koodia nykyisessä prosessissa ajeta toiminnon ajon aikana. Luonnollisesti asynkronisia tapahtumia (verkko, levyn sisääntulo, ajastimet, muut laitteisto- ja käyttöjärjestelmätapahtumat) käsittelee moottori, joka lisää näiden tapahtumien käsittelejinä (tai takaisinsoittoina) rekisteröidyt JavaScript-toiminnot tapahtumasilmukkajonoon, joka suoritetaan jälkeen jonon edessä olevat toiminnot ovat päättyneet.

Monisäikeisessä paradigmassa kaksi tai useampi säie kuljettaa koodia rinnakkain, joten toiminnon ajon aikana erilainen koodin pala voi myös toimia eri prosessorin ytimessä, lukemalla tai kirjoittamalla mahdollisesti samoihin muistiosoitteisiin. Tämä voi johtaa muistin epäjohdonmukaiseen tilaan, paitsi jos koodi käyttää erityisiä käyttöjärjestelmämekanismeja (synkronointiprimatiivit) jaetun muistin käytön hallitsemiseksi.



Vastaus 2:

Tämä on hyvä kysymys, "Mitä eroa Node.js: n tapahtumavetoisella arkkitehtuurilla ja monisäikeisellä ohjelmoinnilla muilla kielillä on?"

Voimme ja meidän pitäisi hajottaa tämä hiukan.

  • Solmun tapahtumavetoinen arkkitehtuuri.

Tapahtumavetoinen arkkitehtuuri ei ole yksinomainen solmulle, esimerkiksi Tornado (Python), Vertx (Java), Akka (Scala), ReactiveX (useita kieliä).

  • Monisäikeinen ohjelmointi muilla kielillä.

Huomaa, että JavaScript ei tue rakenteeltaan useita ketjuja. Vaikka se tukee verkkotyöntekijöitä, jotka minusta tiedän, voivat toimia säikeinä.

Joten tapahtumavetoinen ei ole ainutlaatuinen solmulle, ja solmuissa voidaan tehdä monisäikeinen lanka.

Joten täällä voi olla kaksi kysymystä: "Mikä ero on tapahtumavetoisen vs. monisäiettämisen välillä" ja "Mitä eroa solmun ja muiden kielten (kehysten) välillä". Keskityn viimeksi mainittuun, koska se näyttää olevan kysymyksen tarkoitus.

Sanoisin, että solmun tekee erityiseksi se, että tekijä on luonut sen välttääkseen IO: n estämisen web-sovelluksia rakennettaessa. Solmuyhteisön kulttuuri on korostaa ja rakentaa estämättömän viestinnän voimaa. Et löydä liian monta kolmannen osapuolen kirjastoa, joka estää puhelut. Solmuna käyttävänä kehittäjänä et todennäköisesti suorita koodissasi hienoja estotoimia. Kun taas muilla kielillä naiivi kehittäjä saattaa vahingossa suorittaa erittäin tehottomia estäviä puheluita, kuten lukemista tietokantayhteydestä.

Paitsi, että sinun pitäisi todella lukea useista malleista "samanaikaisuus" ja ymmärtää niiden edut ja haitat. Bonuspisteet siitä, miksi monisäikeistäminen oli hyväksyttävää niin kauan.



Vastaus 3:

käsitteelliset erot ovat melko helppoja kääri päätäsi.

Tapahtumavetoisessa arkkitehtuurissa ohjelmasi toimii jatkuvasti yhdellä kierteitetyllä silmukalla (voit tehdä useita kierteityksiä solmussa, mutta älä ole huolissasi siitä tällä hetkellä). Kun tapahtuma ampuu, työ on puhelupinossa, jota on tarkoitus käsitellä ohjelmissa vapaa-aikana.

Monisäikeinen arkkitehtuuri lähettää yleensä uuden säikeen, kun sen on odotettava toimintoa. Joten soitat tietokantaan ja spinät uuden säikeen, joka suorittaa kaikki tarvitsemasi asiat ja tekee tarvittavat asiat ja päättele tai liity alkuperäiseen säieeseen.

Nämä molemmat menetelmät ovat erittäin hyödyllisiä erilaisissa asioissa. Tapahtumavetoinen on erinomainen käyttöliittymä ja palvelimet, koska ohjelmasi ei tiedä milloin uusi edes tapahtuu ja usein tapahtumat tulevat purskeiksi. Kierteitys on välttämätöntä laskennallisesti raskaille töille, joissa haluat hajottaa ongelman paljon pienemmiksi kappaleiksi (tai olet lähestymässä yhden kierteitetyn silmukan rajaa).