Socket.io lisamine mitme keermega Node.js-le

Foto autor Vidar Nordli-Mathisen saidil Unsplash

Üks sõlme miinuseid on see, et see on ühe keermega. Muidugi on selle ümber võimalus - nimelt klastriks moodul. Cluster võimaldab meil oma rakendust jaotada mitmesse lõime.

Nüüd on aga tegemist uue probleemiga. Vaadake, et meie koodil, mida käitatakse mitmel eksemplaril, on tegelikult märkimisväärne varjukülg. Üks neist ei ole globaalsete riikide olemasolu.

Tavaliselt pole ühe keermega juhtumil palju muret. Meie jaoks muudab see nüüd kõike.

Vaatame, miks.

Mis siis probleem on?

Meie rakendus on lihtne veebis vestlus, mis töötab neljal lõimel. See võimaldab kasutajal samal ajal oma telefoni ja arvutisse sisse logida.

Kujutage ette, et meil on pistikupesad täpselt nii seatud, nagu oleksime need ühe keerme jaoks seadistanud. Teisisõnu on meil nüüd üks suur globaalne riik, millel on pistikupesad.

Kui kasutaja oma arvutisse sisse logib, avab veebisait ühenduse meie serveris Socket.io eksemplariga. Pistikupesa hoitakse keermes # 3.

Kujutage nüüd ette, et kasutaja läheb kööki suupisteid haarama ja võtab endaga kaasa telefoni - soovides loomulikult sõpradega võrgus veeta.

Nende telefon ühendatakse keermega nr 4 ja pistikupesa salvestatakse lõime olekus.

Telefonist sõnumi saatmine ei tee kasutajale midagi. Ainult 3. lõime inimesed näevad sõnumit. Selle põhjuseks on asjaolu, et lõimele 3 salvestatud pistikupesad ei jää kuidagi võluväel ka lõimedele nr 1, 2 ja 4.

Naljakas on see, et isegi kasutaja ise ei näe oma sõnumeid oma arvutis, kui nad köögist tagasi tulevad.

Muidugi, kui nad veebisaiti värskendavad, võiksime saata GET-i päringu ja tuua viimase 50 sõnumit, kuid me ei saa tegelikult öelda, et see on „dünaamiline” viis.

Miks see juhtub?

Meie serveri hajutamine mitme keerme vahel on mingil moel sama, kui meil on mitu eraldi serverit. Nad ei tea üksteise olemasolust ega jaga kindlasti mälu. See tähendab, et ühel eksemplaril objekti teisel ei ole.

Lõimes 3 salvestatud pistikupesad ei pea tingimata olema kõik pistikupesad, mida kasutaja hetkel kasutab. Kui kasutaja sõbrad on erinevates lõimedes, näevad nad kasutaja sõnumeid ainult siis, kui nad värskendavad veebisaiti.

Ideaalis tahaksime kasutaja sündmusest teisi juhtumeid teavitada. Nii võime olla kindlad, et iga ühendatud seade saab reaalajas värskendusi.

Lahendus

Teistest lõimedest saame teada anda, kasutades Redise avaldamise / tellimise sõnumite saatmise paradigmat (pubsub).

Redis on avatud lähtekoodiga (BSD-litsentsiga) mälusisene andmestruktuuride pood. Seda saab kasutada andmebaasi, vahemälu ja sõnumite vahendajana.

See tähendab, et saame Redise abil oma sündmuste vahel sündmusi jaotada.

Pange tähele, et tavaliselt salvestaksime tõenäoliselt kogu oma struktuuri Redisesse. Kuna aga seda struktuuri ei saa seerialiseerida ja seda tuleb mälus “elusana” hoida, salvestame osa sellest igal esinemisjuhul.

Vool

Mõelgem nüüd nendele sammudele, kus hakkame hakkama saama saabuvate sündmustega.

  1. Üritus nimega sõnum jõuab ühte meie pistikupesa - sel moel ei pea me kõiki võimalikke sündmusi kuulama.
  2. Selle sündmuse käitlejale argumendina edastatud objekti sees võime leida sündmuse nime. Näiteks saatke sõnum - .on ('teade', ({sündmus}) => {}).
  3. Kui selle nime jaoks on käitleja, siis hakkame seda käivitama.
  4. Käitleja võib saata vastuse koos saatmisega.
  5. Saatejuht saadab vastussündmuse meie Redise pubisse. Sealt eraldub see igale meie instantsile.
  6. Iga eksemplar väljastab selle oma socketsState'i, tagades, et iga ühendatud klient saab sündmuse.

Tundub keeruline, ma tean, aga kanna mind.

Rakendamine

Siin on keskkond valmis hoidla, nii et me ei pea kõike ise installima ja seadistama.

Esiteks seame Expressi abil serveri üles.

Loome Expressi rakenduse, HTTP-serveri ja init-pistikupesad.

Nüüd saame keskenduda pistikupesade lisamisele.

Edastame Socket.io serveri eksemplari meie funktsioonile, milles me seadistame keskvara.

onAuth

OnAuth-funktsioon imiteerib lihtsalt volituse manitsemist. Meie puhul on see märgil põhinev.

Isiklikult asendan selle tõenäoliselt tulevikus JWT-ga, kuid seda ei täideta mingil viisil.

Liigume nüüd edasi onConnectioni vahevara juurde.

onConnection

Siin näeme, et hangime kasutaja eelmises vahetarkvaras seadistatud ID ja salvestame selle oma socketsState'i, võtmeks on id ja väärtuseks on pistikupesade massiiv.

Järgmisena kuulame sõnumsündmust. Kogu meie loogika põhineb sellel - iga sündmust, mille esipaneel meile saadab, hakatakse kutsuma sõnumiks.

Sündmuse nimi saadetakse argumendiobjekti sisse - nagu eespool öeldud.

Käitlejad

Nagu näete saidil OnConnection, eriti sõnumiürituse kuulajas, otsime käitlejat sündmuse nime põhjal.

Meie käitlejad on lihtsalt objekt, mille võti on sündmuse nimi ja väärtus on funktsioon. Kasutame seda sündmuste kuulamiseks ja sellele vastamiseks.

Hiljem lisame ka väljasaatmisfunktsiooni ja kasutame seda sündmuse saatmiseks kõigil esinemisjuhtudel.

SocketsState

Me teame oma riigi liidest, kuid peame selle veel rakendama.

Lisame meetodeid nii pistikupesa lisamiseks ja eemaldamiseks kui ka sündmuse eraldamiseks.

Funktsioon Lisamine kontrollib, kas olekul on atribuut, mis on võrdne kasutaja ID-ga. Kui see nii on, siis lisame selle lihtsalt oma olemasolevasse massiivi. Vastasel juhul loome kõigepealt uue massiivi.

Eemaldamise funktsioon kontrollib ka seda, kas oleku omadustes on kasutaja ID. Kui ei - see ei tee midagi. Vastasel korral filtreerib see massiivi massiivi eemaldamiseks massiivi. Kui massiiv on tühi, eemaldab ta selle olekust, seades atribuudi määratlemata.

Redise pubis

Pubisubi loomiseks kasutame paketti nimega node-redis-pubsub.

Saate lisamine

Ok, nüüd on vaja vaid lisada väljastusfunktsioon ...

... ja lisage kuulaja väljamineva_saba_meili jaoks. Nii võtab iga juhtum sündmuse vastu ja saadab selle kasutaja pistikupesadesse.

Muutes selle mitme keermega

Lõpuks lisame koodi, mis on vajalik meie serveri mitme keermestamiseks.

Märkus. Peame sadama tapma, sest pärast meie Nodemoni protsessi lõpetamist Ctrl + c abil ripub see lihtsalt seal.

Pisikese tutistamisega on meil kõigil juhtumitel töötavad pistikupesad. Selle tulemusel: palju tõhusam server.

Suur tänu lugemise eest!

Ma hindan seda, et see kõik võib alguses tunduda tohutult keeruline ja pingutav, kui võtta kõik korraga kasutusele. Seda silmas pidades soovitan tungivalt, et lugeksite koodi uuesti tervikuna ja mõtleksite selle üle tervikuna.

Kui teil on küsimusi või kommentaare, lisage need allpool olevasse kommentaaride jaotisse või saatke mulle teade.

Vaadake minu sotsiaalmeediat!

Liituge minu uudiskirjaga!

Algselt avaldati veebisaidil www.mcieslar.com 10. septembril 2018.