Põhjalik sissejuhatus jaotatud süsteemidesse

Mis on hajutatud süsteem ja miks see nii keeruline on?

Maailma üha kasvava tehnoloogilise laienemisega levivad hajutatud süsteemid üha enam. Need on suur ja keeruline arvutiteaduse õppesuund.

Selle artikli eesmärk on tutvustada levitatavaid süsteeme põhilisel viisil, näidates teile pilguheit selliste süsteemide erinevatesse kategooriatesse, süvenemata üksikasjadesse.

Mis on hajutatud süsteem?

Hajutatud süsteem oma kõige lihtsamas määratluses on koos töötavate arvutite rühm, mis näib lõppkasutaja jaoks ühe arvutina.

Nendel masinatel on ühine olek, need töötavad samaaegselt ja võivad iseseisvalt ebaõnnestuda, mõjutamata kogu süsteemi tööaega.

Pakun, et töötame järk-järgult läbi süsteemi levitamise näite, et saaksite sellest kõigest paremini aru saada:

Lähme andmebaasiga! Traditsioonilised andmebaasid salvestatakse ühe masina failisüsteemi alati, kui soovite sellesse teavet tuua / sisestada - räägite otse selle masinaga.

Selle andmebaasisüsteemi levitamiseks vajame, et see andmebaas töötaks korraga mitmel masinal. Kasutaja peab saama rääkida valitud masinaga ega peaks saama öelda, et ta ei räägi ühe masinaga - kui ta sisestab rekordi sõlmesse nr 1, peab sõlm nr 3 suutma selle kirje tagastada.

Miks süsteemi levitada?

Süsteemid jaotatakse alati vajaduse järgi. Tõde on see - hajutatud süsteemide haldamine on keeruline teema, mis on täis lõkse ja maamiinid. Hajutatud süsteemide juurutamine, hooldamine ja silumine on peavalu, miks siis sinna üldse minna?

See, mida hajutatud süsteem võimaldab teil teha, on horisontaalne skaala . Tulles tagasi meie eelmise ühe andmebaasiserveri näite juurde, oleks ainus viis suurema liikluse haldamiseks riistvara uuendamine, milles andmebaas töötab. Seda nimetatakse vertikaalseks skaleerimiseks .

Vertikaalne skaleerimine on kõik hästi ja hea, kuni saate, kuid teatud aja möödudes näete, et isegi parimast riistvarast ei piisa piisava liikluse jaoks, rääkimata ebapraktilisest hostimisest.

Horisontaalne skaleerimine tähendab lihtsalt ühe arvuti riistvara täiendamise asemel rohkemate arvutite lisamist.

See on oluliselt odavam kui vertikaalne skaleerimine pärast teatud künnist, kuid see ei ole selle peamine eelistus.

Vertikaalne skaleerimine võib teie jõudluse tõsta ainult uusima riistvara võimalustele. Need võimalused osutuvad mõõduka kuni suure töökoormusega tehnoloogiaettevõtetele ebapiisavaks .

Parim asi horisontaalse skaleerimise juures on see, et teil pole mastaabisageduse ülempiiri - kui jõudlus halveneb, lisate lihtsalt teise masina, potentsiaalselt lõpmatuseni.

Lihtne skaleerimine pole ainus hajutatud süsteemide eelis. Sama oluline on ka riketaluvus ja madal latentsus .

Rikketaluvus - kümne masina klaster kahe andmekeskuse piires on oma olemuselt rikketaluvam kui üks masin. Isegi kui üks andmekeskus süttib, töötab teie rakendus ikkagi.

Madal latentsus - võrgupaketi maailmareiside aeg on füüsiliselt piiratud valguse kiirusega. Näitekson New Yorgi ja Sydney vahelise kiudoptilise kaabli abiltaotluse lühim aeg (st edasi-tagasi liikumine) 160 ms. Hajusüsteemid võimaldavad teil sõlme olla mõlemas linnas, võimaldades liiklusel tabada talle kõige lähemat sõlme.

Hajutatud süsteemi toimimiseks on siiski vaja, et nendes masinates töötav tarkvara oleks spetsiaalselt loodud korraga töötamiseks mitmes arvutis ja sellega kaasnevate probleemide lahendamiseks. See ei osutu kergeks saavutuseks.

Meie andmebaasi laiendamine

Kujutage ette, et meie veebirakendus sai meeletult populaarse. Kujutage ka ette, et meie andmebaas hakkas sekundis saama kaks korda rohkem päringuid, kui see suudab hakkama saada. Teie rakendus hakkab kohe jõudluses langema ja teie kasutajad märkavad seda.

Teeme koostööd ja kujundame oma andmebaasi skaala nii, et see vastaks meie kõrgetele nõudmistele.

Tavalises veebirakenduses loete teavet tavaliselt palju sagedamini, kui sisestate uut või muudate vana.

Lugemise jõudlust on võimalik suurendada ja seda nn esmase koopia replikatsiooni strateegia abil. Siin loote kaks uut andmebaasiserverit, mis sünkroonitakse peamisega. Konks on selles, et saate lugeda ainult nendest uutest eksemplaridest.

Alati, kui sisestate või muudate teavet - räägite esmase andmebaasiga. See omakorda teavitab asünkroonselt muudatuse koopiaid ja nad salvestavad ka selle.

Palju õnne, nüüd saate täita kolm korda rohkem loetud päringuid! Kas pole tore?

Lõks

Gotcha! Me kohe kaotanud C meie relatsiooniline andmebaas on ACID tagatisi, mis tähistab järjepidevust.

Näete, nüüd on olemas võimalus, et sisestame uue kirje andmebaasi, väljastame kohe pärast seda loetud päringu ja ei saa midagi tagasi, nagu poleks seda olemaski!

Uue teabe levitamine primaarsest koopiasse ei toimu koheselt. Tegelikult on olemas ajaaken, kust saate vananenud teavet hankida. Kui see nii ei oleks, kannataks teie kirjutamisvõime, kuna see peaks sünkroonselt ootama andmete levitamist.

Hajutatud süsteemidega kaasnevad käputäis kompromisse. See konkreetne teema on see, millega peate elama, kui soovite piisavalt suurendada.

Skaalaga jätkamine

Kasutades koopiate andmebaasi lähenemist, saame oma lugemisliiklust teatud määral horisontaalselt laiendada. See on suurepärane, kuid oleme oma kirjutamisliikluse osas vastu seina jõudnud - kõik on ikka ühes serveris!

Meile pole siin palju võimalusi jäänud. Peame lihtsalt jagama oma kirjutamisliikluse mitmesse serverisse, kuna üks ei suuda sellega hakkama saada.

Üks võimalus on minna mitme primaarse replikatsioonistrateegiaga. Seal on teil koopiate asemel, millest saate ainult lugeda, mitu peamist sõlme, mis toetavad lugemist ja kirjutamist. Kahjuks läheb see päris kiiresti keeruliseks, kuna teil on nüüd võimalus konflikte luua (nt sisestada kaks sama ID-ga kirjet).

Läheme teise tehnikaga, mida nimetatakse kildudeks(nimetatakse ka jaotamiseks ).

Shardinguga jagate oma serveri mitmeks väiksemaks serveriks, mida nimetatakse killudeks. Kõigil nendel kildudel on erinevad kirjed - loote reegli, millised kildud millisesse kildu lähevad. On väga oluline luua reegel, et andmed leviksid ühtlaselt .

Võimalik lähenemisviis sellele on vahemike määratlemine vastavalt teatavale dokumendi teabele (nt kasutajad nimega AD).

See kildklahv tuleks valida väga hoolikalt, kuna suvaliste veergude põhjal ei ole koormus alati võrdne. (nt rohkematel inimestel on pigem täht C kui Z algav nimi ). Ühte killukest, mis saab teistest rohkem taotlusi, nimetatakse kuumaks kohaks ja seda tuleb vältida. Jagunedes muutub andmete ümberhakkamine uskumatult kalliks ja võib põhjustada olulisi seisakuid, nagu juhtus FourSquare'i kurikuulsa 11-tunnise seisaku korral.

Näite lihtsuse tagamiseks eeldage, et meie klient (rakendus Rails) teab, millist andmebaasi iga kirje jaoks kasutada. Samuti väärib märkimist, et killustamiseks on palju strateegiaid ja see on lihtne näide kontseptsiooni illustreerimiseks.

Oleme praegu üsna palju võitnud - saame oma kirjutamisliiklust suurendada N korda, kus N on killude arv. See praktiliselt ei anna meile peaaegu mingeid piiranguid - kujutage ette, kui peeneteralised me selle jaotamise abil saame.

Lõks

Tarkvaratehnikas on kõik enam-vähem kompromiss ja see pole erand. Sharding ei ole lihtne feat ja seda on kõige parem vältida seni, kuni seda tõesti vaja on.

Nüüd oleme teinud päringuid võtmete järgimuud kui jaotatud võti on uskumatult ebaefektiivne (nad peavad läbima kõik killud). SQL- JOINpäringud on veelgi hullemad ja keerukad muutuvad praktiliselt kasutuskõlbmatuks.

Detsentraliseeritud vs hajutatud

Enne kui läheme edasi, tahaksin teha vahet neil kahel terminil.

Kuigi sõnad kõlavad sarnaselt ja võib järeldada, et need tähendavad sama loogiliselt, avaldab nende erinevus olulist tehnoloogilist ja poliitilist mõju.

Detsentraliseeritud ontehnilises mõttesendiselt levitatud , kuid kogu detsentraliseeritud süsteem ei kuulu ühele osalejale. Keegi ettevõte ei saa omada detsentraliseeritud süsteemi, muidu ei oleks see enam detsentraliseeritud.

See tähendab, et enamikku süsteeme, millest täna üle läheme, võib pidada hajutatud tsentraliseeritud süsteemideks - ja just selleks nad on loodud.

Kui järele mõelda - detsentraliseeritud süsteemi on raskem luua, sest siis peate tegelema juhtumiga, kus mõned osalejad on pahatahtlikud. Tavaliste jaotatud süsteemide puhul see nii ei ole, kuna teate, et kõik sõlmed kuuluvad teile.

Märkus: Selle definitsiooni üle on palju vaieldud ja seda võib segi ajada teistega (peer-to-peer, föderaalne). Varases kirjanduses on seda ka erinevalt määratletud. Sõltumata sellest, mida ma teile definitsioonina andsin, on see, mida ma tunnen praegu kõige enam kasutavat, kui plokiahel ja krüptorahad seda terminit populariseerisid.

Hajutatud süsteemikategooriad

Vaatame nüüd läbi paar hajutatud süsteemikategooriat ja loetleme nende suurimad üldkasutatavad tootmistarbed. Pidage meeles, et enamik näidatud numbreid on vananenud ja on tõenäoliselt palju suuremad kui seda aega loete.

Jaotatud andmekauplused

Jaotatud andmekauplused on kõige laialdasemalt kasutatavad ja tunnustatud hajutatud andmebaasidena. Enamik hajutatud andmebaasidest on NoSQL-i mitteseotud andmebaasid, mis on piiratud põhiväärtuste semantikaga. Need tagavad uskumatu jõudluse ja mastaapsuse järjepidevuse või kättesaadavuse hinnaga.

Tuntud skaala - Apple kasutab teadaolevalt 75 000 Apache Cassandra sõlme, mis salvestavad üle 10 petabaidi andmeid juba 2015. aastal

Me ei saa minna hajutatud andmepoodide aruteludesse, ilma et oleksime eelnevalt tutvustanud CAP-teoreemi.

ÜPP teoreem

2002. aastal tõestatud CAP-teoreem väidab, et hajutatud andmehoidla ei saa üheaegselt olla järjepidev, kättesaadav ja jaotustaluv.

Mõned kiired määratlused:

  • Järjepidevus - mida loete ja kirjutate järjestikku, on see, mida oodatakse (pidage meeles, et mõni lõige tagasi oli andmebaasi replikatsiooniga gotcha?)
  • Kättesaadavus - kogu süsteem ei sure - iga ebaõnnestunud sõlm annab alati vastuse.
  • Partitsioonitaluv - süsteem jätkab toimimist ja hoolitseb oma järjepidevuse / kättesaadavuse tagamise eest hoolimata võrgupartitsioonidest

Tegelikkuses tuleb jaotatud andmekogude jaoks anda jaotustolerants. Nagu mainitud paljudes kohtades, millest üks on see suurepärane artikkel, ei saa te olla järjepidevus ja kättesaadavus ilma jaotustaluvuseta.

Mõelge sellele: kui teil on kaks sõlme, mis aktsepteerivad teavet ja nende ühendus sureb - kuidas saavad need mõlemad olla kättesaadavad ja pakuvad teile samal ajal järjepidevust? Neil pole mingit võimalust teada saada, mida teine ​​sõlm teeb, ja sellisena võivad nad muutuda kas võrguühenduseta (pole saadaval) või töötada vananenud teabega (ebajärjekindel) .

Lõpuks on teil valida, kas soovite, et teie süsteem oleks võrgupartitsioonis tugevalt järjepidev või ülimalt kättesaadav .

Praktika näitab, et enamik rakendusi hindab kättesaadavust rohkem. Alati pole vaja alati tugevat järjepidevust. Isegi siis ei tehta seda kompromissi tingimata seetõttu, et vajate 100% kättesaadavuse garantiid, vaid pigem seetõttu, et võrgu latentsus võib olla probleemiks masinate sünkroonimisel, et saavutada tugev järjepidevus. Need ja muud tegurid panevad rakendused tavaliselt valima kõrge kättesaadavusega lahendusi.

Sellised andmebaasid lepivad kõige nõrgema järjepidevuse mudeliga - lõpliku järjepidevusega (tugev vs võimalik järjepidevuse seletus) . See mudel garantiid, et kui ei ole uusi uudiseid tehakse antud objekti lõpuks kõik juurdepääsude, et toode naaseb viimast ajakohastamist väärtus.

Need süsteemid pakuvad BASE omadusi (erinevalt traditsiooniliste andmebaaside ACID-st)

  • B asically vailable - Süsteem naaseb alati vastust
  • S sageli olek - süsteem võib aja jooksul muutuda, isegi sisenditeta (võimaliku järjepidevuse tõttu)
  • E ventuaalne järjepidevus - sisendi puudumisel levivad andmed varem või hiljem igasse sõlme - muutuvad seega järjepidevaks

Selliste saadaolevate hajutatud andmebaaside näited - Cassandra, Riak, Voldemort

Muidugi on ka teisi andmekogusid, mis eelistavad tugevamat järjepidevust - HBase, Couchbase, Redis, Zookeeper

CAP-teoreem väärib mitut artiklit eraldi - mõned on seotud sellega, kuidas saate süsteemi CAP-i omadusi kohandada sõltuvalt sellest, kuidas klient käitub, ja teised selle kohta, kuidas seda õigesti ei mõisteta.

Cassandra

Nagu eespool mainitud, on Cassandra hajutatud No-SQL andmebaas, mis eelistab AP omadusi CAP-ist välja, arveldades lõpuks järjepidevalt. Pean tunnistama, et see võib olla veidi eksitav, kuna Cassandra on väga konfigureeritav - saate selle ka järjepidevuse tagamiseks pakkuda kättesaadavuse arvelt, kuid see pole selle tavaline kasutus.

Cassandra kasutab järjepidevat räsimist, et teha kindlaks, millised teie klastri sõlmed peavad edastatavaid andmeid haldama. Te määrate replikatsiooniteguri , mis põhimõtteliselt ütleb, mitu sõlme soovite oma andmeid kopeerida.

Lugedes loete ainult nendest sõlmedest.

Cassandra on massiliselt skaleeritav, pakkudes absurdselt suurt kirjutusmahtu.

Kuigi see diagramm võib olla kallutatud ja näib, et võrreldakse Cassandrat andmebaasidega, mis on seatud tugeva järjepidevuse tagamiseks (muidu ei saa ma aru, miks MongoDB 4-lt 8-le uuemale versioonile üle viidud jõudlust langetaks), peaks see siiski näitama, mida õigesti seatud Cassandra klaster on võimeline.

Vaatamata sellele ei paku Cassandra hajutatud süsteemide kompromissis, mis võimaldab horisontaalset skaleerimist ja uskumatult suurt läbilaskvust, ACID andmebaaside mõningaid põhijooni - nimelt tehinguid.

Konsensus

Andmebaasi tehinguid on hajutatud süsteemides keeruline rakendada, kuna need nõuavad, et kõik sõlmed lepiksid kokku õiged toimingud (katkestamine või sooritamine). Seda nimetatakse konsensuseks ja see on hajutatud süsteemide põhiprobleem.

Tehingu sooritamise probleemi jaoks vajaliku tüüpi lepinguni jõudmine on lihtne, kui osalevad protsessid ja võrk on täiesti usaldusväärsed. Reaalsetes süsteemides on aga mitmeid võimalikke tõrkeid, näiteks protsessi krahhi, võrgu partitsiooni ning kadunud, moonutatud või dubleeritud sõnumeid.

See tekitab probleemi - on osutunud võimatuks tagada, et ebausaldusväärses võrgus piiritletud aja jooksul õige konsensus saavutatakse.

Praktikas on siiski olemas algoritme, mis saavutavad ebausaldusväärse võrgu osas üsna kiiresti üksmeele. Cassandra pakub tegelikult kergeid tehinguid, kasutades Paxose algoritmi hajutatud konsensuse saavutamiseks.

Hajutatud arvutus

Hajutatud andmetöötlus on viimastel aastatel nähtud suurandmete töötlemise sissevoolu võti. See on tohutu ülesande (nt koondage 100 miljardit kirjet), millest ükski arvuti pole iseseisvalt praktiliselt võimeline, jagamine paljudeks väiksemateks ülesanneteks, millest igaüks mahub ühte kaubamasinasse. Jagate oma tohutu ülesande paljudeks väiksemateks, lasete neil mitmel masinal paralleelselt täita, koondate andmed nõuetekohaselt kokku ja olete oma esialgse probleemi lahendanud. See lähenemine võimaldab teil jällegi horisontaalselt skaalata - kui teil on suurem ülesanne, lisage arvutusse lihtsalt rohkem sõlme.

Tuntud skaala - Folding @ Home'il oli 2012. aastal 160 000 aktiivset masinat

Varajane uuendaja selles ruumis oli Google, kes pidi oma suure andmehulga tõttu leiutama hajutatud arvutuste jaoks uue paradigma - MapReduce. Nad avaldasid selle kohta 2004. aastal töö ja avatud lähtekoodiga kogukond lõi selle põhjal hiljem Apache Hadoopi.

MapReduce

MapReduce saab lihtsalt määratleda kahe sammuna - andmete kaardistamine ja vähendamine millekski mõttekaks.

Vaatame seda uuesti ühe näitega:

Oletame, et oleme keskmised ja ladustasime oma tohutu teabe ladustamise eesmärgil teisesesse hajutatud andmebaasi. Tahame hankida andmeid, mis kajastavad kogu 2017. aasta aprilli (aasta tagasi) iga päev välja antud plaksutuste arvu.

See näide on võimalikult lühike, selge ja lihtne, kuid kujutage ette, et töötame paljude andmetega (nt analüüsime miljardeid plaksutusi). Me ei salvesta kogu seda teavet ilmselgelt ühte masinasse ja me ei analüüsi seda kõike ainult ühe masinaga. Samuti ei hakka me päringuid tegema tootmise andmebaasist, vaid pigem mõnest „ladu” andmebaasist, mis on loodud spetsiaalselt madala prioriteediga võrguühenduseta tööde jaoks.

Iga kaarditöö on eraldi sõlm, mis muudab nii palju andmeid kui võimalik. Iga töö läbib kõik antud salvestussõlmes olevad andmed ja kaardistab need lihtsa kuupäeva ja numbri kahega. Seejärel tehakse kolm vaheetappi (millest keegi ei räägi) - segamine, sorteerimine ja jaotamine. Põhimõtteliselt korrastavad nad andmeid ja kustutavad need sobivaks vähendamiseks. Kuna tegemist on suurandmetega, on meil igaüks Reduce-töö eraldatud, et töötada ainult ühel kuupäeval.

See on hea paradigma ja võimaldab üllataval kombel sellega palju ära teha - saate näiteks mitu MapReduce'i tööd aheldada.

Paremad tehnikad

MapReduce on tänapäeval mõnevõrra pärand ja toob sellega kaasa mõningaid probleeme. Kuna see töötab partiidena (töökohtadena), tekib probleem, kus töö ebaõnnestumisel peate kogu asja uuesti alustama. 2-tunnine töö ebaõnnestumine võib teie kogu andmetöötlustoimingut aeglustada ja te ei soovi seda vähemalt, eriti tipptundidel.

Teine küsimus on aeg, mil ootate tulemuste saamiseni. Reaalajas analüütilistes süsteemides (millel kõigil on suured andmed ja seega kasutatakse hajutatud arvutust) on oluline, et teie uusimad krupitud andmed oleksid võimalikult värsked ja kindlasti mitte mõne tunni tagused.

Sellisena on tekkinud ka teisi arhitektuure, mis neid probleeme lahendavad. Nimelt Lambda arhitektuur (paketttöötluse ja voo töötlemise segu) ja Kappa arhitektuur (ainult voo töötlemine). Need valdkonna edusammud on toonud neile uusi tööriistu - Kafka ojad, Apache Spark, Apache Storm, Apache Samza.

Hajutatud failisüsteemid

Hajutatud failisüsteeme võib pidada hajutatud andmekogudeks. Need on sama mis mõiste - suure hulga andmete salvestamine ja neile juurdepääs masinate klastris, mis kõik kuvatakse ühtsena. Tavaliselt käivad nad käsikäes hajutatud arvutitega.

Tuntud skaala - Yahoo on tuntud HDFS-i käitamise kaudu enam kui 42 000 sõlmel 600 petabaidise andmete salvestamiseks, tagasi 201. aastal

Vikipeedia määratleb erinevuse, et hajutatud failisüsteemid võimaldavad failidele juurde pääseda samade liideste ja semantika abil nagu kohalikud failid, mitte kohandatud API kaudu nagu Cassandra Query Language (CQL).

HDFS

Hadoopi hajutatud failisüsteem (HDFS) on hajutatud failisüsteem, mida kasutatakse hajutatud arvutusteks Hadoopi raamistiku kaudu. Laialdase kasutuselevõtu abil kasutatakse seda suurte (GB või TB suuruste) failide salvestamiseks ja paljundamiseks paljudes masinates.

Selle arhitektuur koosneb peamiselt NameNodes ja DataNodes . NameNodes vastutab klastri metaandmete hoidmise eest, näiteks milline sõlm sisaldab mis failiplokke. Nad toimivad võrgu koordinaatoritena, selgitades välja, kuhu faile kõige paremini salvestada ja kopeerida, jälgides süsteemi tervist. DataNodes lihtsalt salvestab faile ja täidab käske, näiteks faili paljundamine, uue kirjutamine ja teised.

Pole üllatav, et HDFS-i saab arvutamiseks kõige paremini kasutada koos Hadoopiga, kuna see annab arvutamistöödele andmeteadlikkuse. Nimetatud tööd käivitatakse seejärel andmeid salvestavate sõlmede peal. See võimendab andmete asukohta - optimeerib arvutusi ja vähendab võrgu kaudu liikluse hulka.

IPFS

Planeetidevaheline failisüsteem (IPFS) on hajutatud failisüsteemi jaoks põnev uus peer-to-peer protokoll / võrk. Kasutades Blockchaini tehnoloogiat, on sellel uhke täiesti detsentraliseeritud arhitektuur, millel pole ühtegi omanikku ega ebaõnnestumispunkti.

IPFS pakub IPNS-iks nimetussüsteemi (sarnane DNS-ile) ja võimaldab kasutajatel hõlpsasti teabele juurde pääseda. See salvestab faili ajaloolise versiooniga, sarnaselt Gitiga. See võimaldab juurdepääsu kõigile faili eelmistele olekutele.

See on veel läbi arenenud (v0.4 kirjutamise ajal), kuid on juba näinud projekte, kes on huvitatud selle ülesehitamisest (FileCoin).

Hajutatud sõnumside

Sõnumsüsteemid pakuvad keskset kohta sõnumite / sündmuste salvestamiseks ja levitamiseks teie süsteemis. Need võimaldavad teil lahutada oma rakendusloogika otse teiste süsteemidega rääkimisest.

Tuntud skaala - LinkedIni Kafka klaster töötles päevas 1 triljonit sõnumit, mille tipp oli 4,5 miljonit sekundis.

Lihtsamalt öeldes töötab sõnumside platvorm järgmiselt:

Sõnum edastatakse rakendusest, mis selle potentsiaalselt loob (nimetatakse tootjaks ), läheb platvormi ja seda loevad potentsiaalselt mitmed rakendused, kes on sellest huvitatud (nn tarbijad ).

Kui teil on vaja teatud sündmus mõnesse kohta salvestada (nt kasutajate loomine andmebaasi, lattu, e-posti saatmisteenus ja mis iganes muu välja mõelda), on sõnumiplatvorm kõige puhtam viis selle sõnumi levitamiseks.

Tarbijad saavad kas vahendajatelt teavet välja tõmmata (pull-mudel) või lasta maakleritel teavet otse tarbijatesse lükata (push-mudel).

Seal on paar populaarseimat tipp-sõnumiplatvormi:

RabbitMQ - sõnumivahendaja, mis võimaldab teil marsruutimisreeglite ja muude hõlpsasti konfigureeritavate sätete kaudu juhtida sõnumite trajektoore täpsemalt. Võib nimetada nutikaks maakleriks, kuna selles on palju loogikat ja ta jälgib tihedalt seda läbivaid sõnumeid. Annab seaded nii AP ja CP alates CAP . Tarbijatest teavitamiseks kasutab tõukemudelit.

Kafka - sõnumivahendaja (ja kõik platvormid), mis on natuke madalamal tasemel, kuna see ei jälgi loetud sõnumeid ega võimalda keerukat marsruutimisloogikat. See aitab saavutada hämmastavat jõudlust. Minu arvates on see suurim väljavaade selles ruumis koos avatud lähtekoodiga kogukonna aktiivse arendamise ja Confluenti meeskonna toetusega. Kafka on väidetavalt kõige levinum tipptehnoloogiaettevõtete kasutuses. Kirjutasin selle kohta põhjaliku sissejuhatuse, kus käsitlen üksikasjalikult kogu selle headust.

Apache ActiveMQ - hulgast vanim, pärit aastast 2004. Kasutab JMS API-d, mis tähendab, et see on suunatud Java EE rakendustele. See kirjutati ümber kui ActiveMQ Artemis, mis pakub silmapaistvat jõudlust Kafka tasemel.

Amazon SQS - sõnumiteenus, mida pakub AWS. Võimaldab selle kiiresti olemasolevate rakendustega integreerida ja kaob vajadus oma infrastruktuuriga ümber käia, mis võib olla suureks eeliseks, kuna selliste süsteemide nagu Kafka seadistamine on teadupärast keeruline. Amazon pakub ka kahte sarnast teenust - SNS ja MQ, millest viimane on põhiliselt ActiveMQ, kuid mida haldab Amazon.

Hajutatud rakendused

Kui koondate 5 Rails-serverit ühe koormuse tasakaalustaja taha, mis on kõik ühendatud ühe andmebaasiga, kas saaksite seda helistada hajutatud rakenduseks? Tuletage meelde minu definitsioon ülalt:

Hajutatud süsteem on rühm arvuteid, mis töötavad koos, kuvades lõppkasutajale ühe arvutina. Nendel masinatel on ühine olek, need töötavad samaaegselt ja võivad iseseisvalt ebaõnnestuda, mõjutamata kogu süsteemi tööaega.

Kui loete andmebaasi jagatud olekuks, võite väita, et seda saab liigitada hajutatud süsteemiks - kuid te eksite, kuna olete määratluse osa " Koostöö " vahele jätnud .

Süsteem jaotub ainult siis, kui sõlmed suhtlevad omavahel oma toimingute koordineerimiseks.

Seetõttu saab midagi sarnast rakenduse, mis töötab oma tagakoodiga peer-to-peer võrgus, paremini liigitada hajutatud rakenduseks. Sõltumata sellest on kõik asjatu liigitamine, millel pole mingit eesmärki, vaid see illustreerib, kui keerulised me asjade rühmitamisel oleme.

Tuntud skaala - BitTorrent, 193 000 sõlme, Troonide mängu episoodiks, aprill 2014

Erlangi virtuaalne masin

Erlang on funktsionaalne keel, millel on suurepärane samaaegsuse, jaotuse ja rikketaluvuse semantika. Erlangi virtuaalne masin haldab ise Erlangi rakenduse levitamist.

Selle mudel töötab paljude eraldatud kergete protsessidega , millel kõigil on võimalus üksteisega suhelda sõnumite edastamise sisseehitatud süsteemi kaudu. Seda nimetatakse näitlejamudeliksja Erlangi OTP raamatukogusid võib käsitleda hajutatud osalejate raamistikuna (JVMi jaoks Akka eeskujul).

Mudel on see, mis aitab tal saavutada lihtsat samaaegsust - protsessid on hajutatud neid käitava süsteemi olemasolevate tuumade vahel. Kuna seda ei saa eristada võrguseadist (peale sõnumite loobumise võimaluse), saab Erlangi VM-i ühendada teiste samas andmekeskuses või isegi teisel kontinendil töötavate Erlangi VM-idega. See virtuaalsete masinate parv käivitab ühe rakenduse ja haldab masina tõrkeid ülevõtmise kaudu (teine ​​sõlm saab plaanitud töötama).

Tegelikult lisati tõrketaluvuse tagamiseks keele hajutatud kiht. Ühes masinas töötaval tarkvaral on alati oht, et see üks masin sureb ja viib teie rakenduse võrguühenduseta. Paljudes sõlmedes töötav tarkvara võimaldab hõlpsamat riistvaratõrke käsitlemist, kui rakendus on seda üles ehitatud.

BitTorrent

BitTorrent on üks levinumaid protokolle suurte failide teisaldamiseks Interneti kaudu torrentide kaudu. Peamine mõte on hõlbustada failide edastamist võrgus erinevate eakaaslaste vahel, ilma et peaksite läbima põhiserverit.

BitTorrenti kliendi abil saate faili allalaadimiseks ühenduse luua mitme arvutiga kogu maailmas. .Torrenti faili avamisel loote ühenduse nn jälgijaga , mis on masin, mis toimib koordinaatorina. See aitab kaaslaste avastamisel, näidates teile võrgus olevaid sõlme, millel on soovitud fail.

Teil on kahte tüüpi kasutajad: leecher ja külvik . Leecher on kasutaja, kes laadib faili alla, ja seeder on kasutaja, kes laadib faili üles.

Peer-to-peer võrkude puhul on naljakas see, et teil on tavakasutajana võimalus võrguga liituda ja sellesse panustada.

BitTorrent ja selle eelkäijad (Gnutella, Napster) võimaldavad teil faile vabatahtlikult hostida ja teistele soovijatele üles laadida. Põhjus, miks BitTorrent on nii populaarne, on see, et see oli esimene omataoline, mis pakkus stiimuleid võrku panustamiseks. Varasemate failijagamisprotokollidega oli probleem vabasõit , kus kasutaja laadis alla ainult faile.

BitTorrent lahendas vabasõidu teatud määral, pannes külvikud rohkem üles laadima neile, kes pakuvad parimaid allalaadimismäärasid. See toimib nii, et motiveeritakse teid faili allalaadimise ajal üles laadima. Kahjuks ei sega miski pärast lõpetamist teid võrgus aktiivsena. See põhjustab võrgus külvikute puudumise, kellel on täielik fail ja kuna protokoll tugineb suuresti sellistele kasutajatele, tulid lahendused nagu erareklaamid. Privaatsed jälgijad eeldavad, et olete hajutatud võrgus osalemiseks kogukonna liige (sageli ainult kutsetega).

Pärast edusamme selles valdkonnas leiutati jälgimiseta torrentid. See oli BitTorrent-protokolli uuendus, mis ei tuginenud metaandmete kogumisel ja kaaslaste leidmisel tsentraliseeritud jälgijatele, vaid kasutas uusi algoritme. Üks selline näide on Kademlia (Mainline DHT), hajutatud räsitabel (DHT), mis võimaldab teil leida eakaaslasi teiste eakaaslaste kaudu. Tegelikult täidab iga kasutaja jälgija ülesandeid.

Jaotatud pearaamatud

Hajutatud pearaamatut võib pidada muutumatuks ainult liidetud andmebaasiks, mida paljundatakse, sünkroniseeritakse ja jagatakse jaotatud võrgu kõigi sõlmede vahel.

Tuntud skaala - Ethereumi võrgul oli 4. jaanuaril 2018 tipptasemel 1,3 miljonit tehingut päevas.

Need kasutavad sündmuste hankimise mustrit, võimaldades teil pearaamatu oleku selle ajaloos igal ajal taastada.

Blockchain

Blockchain on praegune hajutatud pearaamatute aluseks olev tehnoloogia, mis tegelikult tähistas nende algust. See uusim ja suurim uuendus hajutatud ruumis võimaldas luua kõigi aegade esimese tõeliselt hajutatud makseprotokolli - Bitcoini.

Blockchain on hajutatud pearaamat, mis kannab tellitud loendit kõikidest tema võrgus kunagi toimunud tehingutest. Tehingud on rühmitatud ja salvestatud plokkidena. Kogu plokiahel on sisuliselt lingitud plokkide loend (sellest ka nimi) . Nimetatud plokkide loomine on arvutuslikult kallis ja krüptograafia kaudu omavahel tihedalt seotud.

Lihtsamalt öeldes sisaldab iga plokk praeguse ploki sisu (Merkle puu kujul) spetsiaalset räsi (mis algab X summa nullist) pluss eelmise ploki räsi. Selle räsi tootmiseks on vaja palju protsessori võimsust, sest ainus viis selle saavutamiseks on toore jõu abil.

Kaevurid on sõlmed, kes üritavad räsi arvutada (bruteforce'i kaudu). Kaevurid konkureerivad omavahel, kes suudab välja mõelda juhusliku stringi (nn nonce ), mis koos sisuga toodab ülalnimetatud räsi. Kui keegi leiab õige nonce - ta edastab selle kogu võrku. Seejärel kinnitab nimetatud sõlme iga sõlm eraldi ja aktsepteerib oma ahelas.

See tähendab süsteemi, kus plokiahela muutmine on absurdselt kulukas ja absurdselt lihtne kontrollida, kas seda ei muudeta.

Bloki sisu muutmine on kulukas, sest see tooks teistsuguse räsi. Pidage meeles, et iga järgmise ploki räsi sõltub sellest. Kui muudaksite ülaltoodud pildi esimeses plokis tehingut - muudaksite Merkle juurt. See muudaks omakorda ploki räsi (tõenäoliselt ilma vajalike juhtnullideta) - see muudaks ploki nr 2 räsi ja nii edasi ja nii edasi. See tähendab, et peate iga ploki jaoks pärast muudetud plokki uue jõu kasutama.

Võrk usaldab ja kopeerib alati kõige pikemat kehtivat ahelat. Selleks petta süsteemi ja lõpuks saada pikem kett, mida vajate rohkem kui 50% kogu CPU võimsus, mida kasutavad kõik sõlmed.

Plokiahelat võib pidada tekkiva konsensuse hajutatud mehhanismiks . Otseselt konsensust ei saavutata - konsensuse saavutamiseks pole valimisi ega kindlat hetke. Selle asemel, konsensus on Tekkiva toote asünkroonse suhtlemise tuhandeid sõltumatu sõlmede kõik järgmised protokolli eeskirjadega.

Sellest enneolematust uuendusest on hiljuti saanud tehnoruumi buum, kus inimesed ennustavad, et see tähistab Web 3.0 loomist. See on kindlasti tarkvaratehnika maailmas praegu kõige põnevam ruum, mis on täidetud ülimalt keeruliste ja huvitavate lahendamist ootavate probleemidega.

Bitcoin

Varasematest jaotatud makseprotokollidest puudus võimalus kahekordse kulutamise probleemi reaalajas hajutatud viisil praktiliselt ära hoida. Uuringud on andnud huvitavaid ettepanekuid [1], kuid Bitcoin võttis esimesena kasutusele praktilise lahenduse, millel olid selged eelised teiste ees.

Topeltkulutuste probleem väidab, et näitleja (nt Bob) ei saa oma ühte ressurssi kulutada kahes kohas. Kui Bobil on 1 dollar, ei peaks ta saama seda nii Alice'ile kui ka Zackile anda - see on ainult üks vara, seda ei saa dubleerida. Selgub, et hajutatud süsteemis on selle garantii saavutamine tõesti keeruline. Enne plokiahelat on olemas huvitavaid leevendusmeetodeid, kuid need ei lahenda probleemi praktilisel viisil täielikult.

Topeltkulutused lahendab Bitcoin hõlpsalt, kuna korraga lisatakse ahelasse ainult üks plokk. Topelt kulutamine on ühe ploki piires võimatu, seega isegi siis, kui luuakse kaks plokki korraga - pikimasse ahelasse satub ainult üks.

Bitcoin tugineb protsessori võimsuse kogunemise raskusele.

Kui hääletamissüsteemis peab ründaja võrku lisama ainult sõlmed (mis on lihtne, kuna vaba juurdepääs võrgule on kujunduse sihtmärk), siis protsessori võimsuspõhises skeemis seisab ründaja silmitsi füüsilise piiranguga: juurdepääs üha enamale võimas riistvara.

See on ka põhjus, miks pahatahtlikud sõlmpunktide rühmad peavad edukate rünnakute elluviimiseks kontrollima üle 50% võrgu arvutusvõimsusest. Vähem kui see, ja ülejäänud võrk loob pikema plokiahela kiiremini.

Ethereum

Ethereumi võib mõelda kui programmeeritavat plokiahelal põhinevat tarkvaraplatvormi. Sellel on oma krüptoraha (eeter), mis toidab nutikate lepingute kasutuselevõttu oma plokiahelas.

Nutikad lepingud on kooditükk, mis on Ethereumi plokiahelas salvestatud ühe tehinguna. Koodi käivitamiseks peate tegema ainult tehingu, mille sihtkohaks on nutikas leping. See omakorda paneb kaevandussõlmed koodi ja mis tahes muudatusi see täitma. Kood täidetakse Ethereumi virtuaalses masinas.

Nutikate lepingute kirjutamiseks kasutatakse Ethereumi emakeelset programmeerimiskeelt Solidity . See on terviklik programmeerimiskeel, mis ühendab otseselt Ethereumi plokiahelat, võimaldades teil küsida olekut nagu saldosid või muid tarkade lepingutulemusi. Lõputute tsüklite vältimiseks nõuab koodi käivitamine teatud koguse eetrit.

Kuna blockchain võib tõlgendada kui rea seisund muutub , palju Distributed Applications (DApps) on ehitatud peal Ethereum jms platvormid.

Hajutatud pearaamatute edasine kasutamine

Olemasolu tõendav dokument - teenus anonüümselt ja turvaliselt tõendi olemasolu kohta, et teatud digitaalne dokument oli mingil ajahetkel olemas. Kasulik dokumendi terviklikkuse, omandiõiguse ja ajatempli tagamiseks.

Detsentraliseeritud autonoomsed organisatsioonid (DAO) - organisatsioonid, kes kasutavad plokiahelat konsensuse saavutamiseks organisatsiooni parenduspakkumiste osas. Näiteks on Dashi juhtimissüsteem, SmartCashi projekt

Detsentraliseeritud autentimine - salvestage oma identiteet plokiahelasse, võimaldades teil kõikjal ühekordse sisselogimise (SSO) kasutamist. Sovrin, kodanikuühiskond

Ja palju-palju muud. Hajutatud pearaamatu tehnoloogia avas tõesti lõputult võimalusi. Mõnda leiutatakse tõenäoliselt meie rääkimise ajal!

Kokkuvõte

Selle artikli lühikese aja jooksul õnnestus meil määratleda, mis on hajutatud süsteem, miks peaksite seda kasutama ja iga kategooriat veidi üle vaatama. Mõned olulised asjad, mida meeles pidada, on:

  • Hajutatud süsteemid on keerukad
  • Need valitakse mastaabi ja hinna vajaduse järgi
  • Nendega on raskem töötada
  • ÜPP teoreem - järjepidevuse / kättesaadavuse kompromiss
  • Neil on 6 kategooriat - andmekogud, andmetöötlus, failisüsteemid, sõnumsüsteemid, pearaamatud, rakendused

Ausalt öeldes oleme hajutatud süsteemides pinda vaevu puudutanud. Mul polnud võimalust põhjalikult lahendada ja selgitada põhiprobleeme, nagu konsensus, replikatsioonistrateegiad, sündmuste tellimine ja aeg, ebaõnnestumistaluvus, sõnumi edastamine võrgus ja teised.

Ettevaatust

Las ma jätan teile lahkumineku hoiatuse:

Hajutatud süsteemidest peate eemale minema nii palju kui võimalik. Nende endi jaoks tekitatud keerukus ei ole vaeva väärt, kui saate probleemi kas muul viisil lahendades või mõne muu pakendis oleva lahenduse abil vältida.

[1]

Topeltkulutuste vastane võitlus ühistuliste P2P-süsteemide abil, 25. – 27. Juuni 2007 - pakutud lahendus, mille puhul iga „münt” võib aeguda ja määrata selle kulutamisele tunnistaja (valideerija).

Bitgold , detsember 2005 - Bitcoini protokollidega äärmiselt sarnase protokolli kõrgetasemeline ülevaade. Öeldakse, et see on Bitcoini eelkäija.

Edasine jaotatud süsteemide lugemine:

Andmemahukate rakenduste kujundamine, Martin Kleppmann - suurepärane raamat, mis hõlmab kõike hajutatud süsteemides ja palju muud.

Pilvandmetöötluse spetsialiseerumine, Illinoisi ülikool, Coursera - pikk kursuste seeria (6), mis käsitleb jaotatud süsteemi kontseptsioone, rakendusi

Jepsen - Blog, mis selgitab paljusid levitatavaid tehnoloogiaid (ElasticSearch, Redis, MongoDB jne)

Täname, et leidsite aega selle pika (~ 5600 sõna) artikli läbi lugemiseks!

Kui leidsite selle informatiivse teabe või arvate, et see pakub teile väärtust, andke sellele kindlasti nii palju plaksutusi, mis teie arvates väärivad, ja kaaluge selle jagamist sõbraga, kes võiks kasutada selle suurepärase õppesuuna tutvustust.

~ Stanislav Kozlovski

Uuenda

Praegu töötan Confluentis. Confluent on Big Data ettevõte, mille asutasid Apache Kafka loojad ise! Olen tohutult tänulik võimaluse eest, mille nad mulle on andnud - töötan praegu Kafka enda kallal, mis on üle vinge! Meie Confluentis aitame kujundada kogu avatud lähtekoodiga Kafka ökosüsteemi, sealhulgas uut hallatavat Kafka-as-a-service pilvepakkumist.

Võtame tööle paljudele ametikohtadele (eriti SRE / tarkvarainseneridele) Euroopas ja USA-s! Kui olete huvitatud Kafka enda kallal töötamisest, uute võimaluste otsimisest või lihtsalt uudishimulik - saatke mulle kindlasti Twitteris sõnum ja ma jagan kõiki häid hüvesid, mis tekivad töötades lahepiirkonna ettevõttes.