“Ekki stífla atburðahringinn…” – þú hefur líklega heyrt þessa setningu mörgum sinnum… Ég er ekki hissa því hún er ein af mikilvægustu forsendunum þegar unnið er með Node. En það er líka önnur “hlutur” sem þú ættir að forðast að stífla – vinnuhópinn. Ef honum er vanrækt getur það haft veruleg áhrif á afköst forritsins og jafnvel öryggi þess.
Þræðir
Það helsta sem þarf að muna: það eru tvær tegundir af þráðum í Node.js: Aðalþráður – sem er meðhöndlaður af Viðburðahringrás, og Vinnuafl (þráðalaug) – sem er laug þráða –
þökk sé libuv. Hver og einn þeirra hefur mismunandi hlutverk. Markmið hins fyrsta er að sjá um óblokkandi I/O-aðgerðir, en sá annar sér um örgjörvamiðaða vinnu og einnig blokkandi I/O.

En hvað er þráður og hvernig er hann ólíkur ferli? Það eru nokkur munarmál, en það mikilvægasta fyrir okkur Þetta er hvernig minni er úthlutað þeim. Þú getur hugsað um ferli eins og forrit. Inni í hverju ferli er minnisbiti sem er eingöngu ætlaður því ferli. Þannig hefur eitt ferli ekki aðgang að minni hins ferlisins, og þessi eiginleiki tryggir háa öryggisgæslu. Til að koma á samskiptum á milli þeirra þurfum við að vinna nokkuð. Þræðir eru öðruvísi. Þræðir keyra innan eins ferlis og deila sama minni, svo engin vandamál koma upp við að þeir deili minni. gögn.
Hins vegar veldur eitt atriði vandamáli. Það kallast keppnisástand. Þræðirnir geta keyrt samtímis, svo hvernig vitum við hvaða aðgerð lýkur fyrst? Það getur gerst að í fyrsta sinn sem þú keyrir það ljúki fyrsta aðgerðin fyrst, en næst gæti komið fyrir að hin önnur aðgerðin ljúki á undan þeirri fyrstu. Ímyndaðu þér að vinna með skrifa- og lestraraðgerðir við slíkar aðstæður! Martröð! Stundum er mjög erfitt að skrifa rétt. kóði í fjölþráða umhverfi.
Einnig hafa fjölþráða forritunarmál mikið minnisálag vegna þess að þau búa til aðskilda þráð fyrir hverja beiðni; svo ef þú vilt kalla 1000 beiðnir, búa þau til 1000 þræði.
Hvernig á að takast á við slíkt vandamál? Notaðu eina þráð í staðinn! Og það er það sem Knútur sem býður þér.

Sem JavaScript þróunaraðili Ég hvet þig til að horfa á kvikmynd
í hvoru Bart Belder útskýrir hugtakið atburðarhringinn skýrt. Ofangreint myndrit er tekið úr kynningu hans. Og ef þú þekkir þessi hugtök alls ekki, bæði Knútur og Libuv hafa framúrskarandi skjöl 🙂
Um lokun
Í JavaScript þróun Í greininni segja þeir að vegna Knútur Er einþráða og óhindrandi, svo þú getur náð meiri samhliða vinnslu með sömu auðlindum en með fjölþráðu lausnum. Það er satt, en það er ekki eins fallegt og einfalt og það kann að virðast.
Frá Node.js er einþráða (JS hluta), örgjörvafreist verkefni munu stöðva allar beiðnir sem eru í gangi þar til viðkomandi verkefni er lokið. Svo, það er satt að í Node.js Þú getur lokað á allar beiðnir bara vegna þess að ein þeirra innihélt lokunarskipun. Lokunarkóði þýðir að það tekur lengri tíma en nokkrar millisekúndur að ljúka. En ruglaðu ekki saman löngum svartíma og lokun. Svarið frá gagnagrunninum getur tekið mjög langan tíma, en það stöðvar ekki ferlið þitt (forritið).
Blokkandi aðferðir keyrast samstillt og óblokkandi aðferðir keyrast ósamstillt.
Hvernig geturðu hægt á atburðarhringnum þínum (eða hindrað hann)?
- Véikburða reglubundið mynstur er slíkt sem reglubundins mynstursvinnslaforritið þitt gæti tekið veldisvísislega langan tíma; þú getur lesið meira um þau. hér,
- JSON-aðgerðir á stórum hlutum,
- með því að nota samstilltar API-er frá Knútur kjarnaeiningar í stað ósamstilltra útgáfa; allar I/O-aðferðir í Node.js staðalbókasafninu bjóða einnig upp á sínar ósamstilltu útgáfur,
- aðrir forritunarvankantar, eins og samstilltar endalausar lykkjur.
Í því tilviki, þar sem Worker Pool notar þráðapott, er hægt að stöðva þá líka? Því miður, já 🙁 Knútur er byggt á heimspeki einn þráður fyrir marga viðskiptavini. Segjum að tiltekið verkefni sem ákveðinn vinnumaður sinnir sé mjög flókið og taki lengri tíma að ljúka. Vinnumaðurinn verður þá fastur og getur ekki sinnt öðrum biðandi verkefnum fyrr en fyrirmælum hans hefur verið framfylgt. Eins og þú hefur líklega giskað á getur þetta haft áhrif á afköst. Þú getur komið í veg fyrir slík vandamál með því að lágmarka breytileika í verkefnatímum með verkefnaskiptingu.
Ályktun
Forðastu blokkun, það er víst. Ef þú getur, veldu alltaf ósamhverfar útgáfur af API-um staðalsafnsins. Annars, eftir að forritið þitt hefur keyrt, getur viðskiptavinurinn lent í ýmsum vandamálum, allt frá skertu gegnumstreymi upp í algjöra aftengingu, sem er banvænt úr sjónarhóli notandans.
Lesa meira:
Af hverju þú ættir (líklega) að nota TypeScript
Hvernig á ekki að drepa verkefni með slæmum forritunarvenjum?
Stefnur við gagnaleit í NextJS