Az elosztott rendszerek alapos bemutatása

Mi az elosztott rendszer, és miért ilyen bonyolult?

A világ egyre növekvő technológiai terjeszkedésével az elosztott rendszerek egyre inkább elterjednek. Hatalmas és összetett tanulmányi terület a számítástechnikában.

Ennek a cikknek a célja az elosztott rendszerek alapvető megismertetése, bepillantást engedve az ilyen rendszerek különböző kategóriáiba, miközben nem merülünk el a részletek mélyén.

Mi az elosztott rendszer?

Az elosztott rendszer a legegyszerűbb meghatározásában egy olyan számítógépek csoportja, amelyek együtt dolgoznak, és egyetlen számítógépként jelennek meg a végfelhasználó számára.

Ezek a gépek megosztott állapotúak, egyidejűleg működnek és függetlenül is meghibásodhatnak anélkül, hogy befolyásolnák a teljes rendszer üzemidejét.

Azt javaslom, hogy fokozatosan dolgozzunk ki egy példát a rendszer terjesztésére, hogy jobban megérthesse az egészet:

Menjünk egy adatbázissal! A hagyományos adatbázisokat egyetlen gép fájlrendszerén tárolják, amikor információkat akar beolvasni / beszúrni - közvetlenül az adott géppel beszél.

Ahhoz, hogy ezt az adatbázis rendszert terjesszük, szükségünk van arra, hogy ezt az adatbázist egyszerre több gépen futtassuk. A felhasználónak képesnek kell lennie arra, hogy beszéljen bármelyik géppel, amelyet választ, és nem szabad azt mondania, hogy nem egyetlen géppel beszél - ha beilleszt egy rekordot az 1. csomópontba, akkor a 3. csomópontnak vissza kell tudnia adni azt.

Miért kell terjeszteni egy rendszert?

A rendszereket mindig szükség szerint osztják szét. Az igazság az, hogy - az elosztott rendszerek kezelése összetett téma, tele buktatókkal és aknákkal. Fejfájás az elosztott rendszerek telepítése, karbantartása és hibakeresése, miért is kellene egyáltalán oda menni?

Amit az elosztott rendszer lehetővé tesz, az vízszintes méretezés . Visszatérve az egyetlen adatbázis-kiszolgáló előző példájára, a nagyobb forgalom kezelésének egyetlen módja az lenne, ha frissítené az adatbázis futó hardverét. Ezt vertikális méretezésnek nevezzük .

A függőleges méretezés nagyon jó és jó, amíg lehet, de egy bizonyos pont után látni fogja, hogy a legjobb hardver sem elegendő a kellő forgalomhoz, nem is beszélve arról, hogy nem praktikus a gazda.

A vízszintes méretezés egyszerűen több számítógép hozzáadását jelenti, nem pedig egyetlen hardver frissítését.

Lényegesen olcsóbb, mint egy függőleges méretezés egy bizonyos küszöbérték után, de nem ez a fő eset a preferencia szempontjából.

A vertikális méretezés csak a legfrissebb hardver képességeinek felel meg. Ezek a képességek elégtelennek bizonyulnak a közepes vagy nagy terhelésű technológiai vállalatok számára.

A vízszintes méretezésnél az a legjobb, hogy nincs felső határa a méretezéshez - amikor a teljesítmény romlik, egyszerűen hozzá kell adnia egy másik gépet, a végtelenségig.

Az elosztott rendszerek nem csak az egyszerű méretezéssel járnak. A hibatűrés és az alacsony késés is ugyanolyan fontos.

Hibatűrés - egy két gépből álló tíz gépből álló klaszter eredendően hibatűrőbb, mint egyetlen gép. Az alkalmazás még akkor is működni fog, ha meggyullad egy adatközpont.

Alacsony késleltetés - A hálózati csomag világutazásának idejét fizikailag korlátozza a fénysebesség. Például a lehető legrövidebb idő egy kérés oda-vissza útjára (vagyis menjen előre és vissza) egy száloptikai kábelben New York és Sydney között 160 ms. Az elosztott rendszerek lehetővé teszik, hogy mindkét városban legyen csomópont, így a forgalom elérheti a hozzá legközelebb eső csomópontot.

Az elosztott rendszer működéséhez azonban szükség van az ezeken a gépeken futó szoftverre, amelyet kifejezetten úgy terveztek, hogy egyszerre több számítógépen fusson és kezelje a vele járó problémákat. Kiderült, hogy ez nem könnyű bravúr.

Az adatbázisunk méretezése

Képzelje el, hogy webes alkalmazásunk őrülten népszerű lett. Képzelje el azt is, hogy az adatbázisunk másodpercenként kétszer annyi lekérdezést kezdett kapni, mint amennyit képes kezelni. Az alkalmazás azonnal csökkenni kezd a teljesítményben, és ezt a felhasználók észreveszik.

Dolgozzunk együtt, és állítsuk össze adatbázis-skálánkat, hogy megfeleljen a magas követelményeknek.

Egy tipikus webalkalmazásban általában sokkal gyakrabban olvassa el az információkat, mint új információkat szúr be vagy módosít a régieket.

Van egy módszer az olvasási teljesítmény növelésére, ez az úgynevezett Elsődleges-replika replikációs stratégia. Itt két új adatbázis-kiszolgálót hoz létre, amelyek szinkronizálódnak a fővel. A fogás az, hogy csak ezekből az új példányokból tud olvasni .

Amikor információkat szúr be vagy módosít - beszéljen az elsődleges adatbázissal. Ez viszont aszinkron módon tájékoztatja a változás másolatait, és ők is elmentik.

Gratulálunk, most már háromszor annyi olvasott lekérdezést hajthat végre! Hát nem nagyszerű?

Csapda

Megvagy! A relációs adatbázisunk ACID- garanciáiban azonnal elveszítettük a C- t , ami a következetességet jelenti.

Látja, most fennáll a lehetőség, hogy új rekordot illesztünk be az adatbázisba, azonnal utána kiadunk egy olvasási lekérdezést, és semmit sem kapunk vissza, mintha nem is létezne!

Az új információk terjesztése az elsődlegesről a replikára nem azonnal történik. Valójában létezik egy időablak, amelyből elavult információkat szerezhet be. Ha nem ez lenne a helyzet, akkor az írási teljesítménye megsérülne, mivel szinkron módon kell várnia az adatok terjesztését.

Az elosztott rendszerek egy sor kompromisszummal járnak. Ez a bizonyos kérdés, amellyel meg kell élnie, ha megfelelően méretezni akar.

A skála folytatása

A replika adatbázis megközelítés segítségével bizonyos mértékig vízszintesen méretezhetjük olvasási forgalmunkat. Ez nagyszerű, de falat vertünk az írási forgalom tekintetében - ez még mindig egy szerveren van!

Nincs sok lehetőségünk itt. Egyszerűen fel kell osztanunk az írási forgalmat több szerverre, mivel az egyik nem képes kezelni.

Az egyik út egy többprimer primer replikációs stratégia alkalmazása. Csak a másolatok helyett, amelyekből csak olvashat, több elsődleges csomópont van, amelyek támogatják az olvasást és írást. Sajnos ez gyorsan bonyolódik, mivel most konfliktusokat tud létrehozni (pl. Két azonos azonosítójú rekordot beilleszteni).

Menjünk egy másik technikával, amit szilánkosításnak hívunk( partíciónak is nevezik ).

A szilánkosítással a kiszolgálót több kisebb szerverre osztja, úgynevezett szilánkokra. Ezek a szilánkok mind különböző rekordokat tartanak - létrehoz egy szabályt arra vonatkozóan, hogy melyik szilánkba milyen rekordok kerülnek. Nagyon fontos olyan szabályt létrehozni, hogy az adatok egységes módon terjedjenek .

Ennek lehetséges megközelítése a tartományok meghatározása a rekordokkal kapcsolatos információk alapján (pl. AD nevű felhasználók).

Ezt az aprító kulcsot nagyon körültekintően kell megválasztani, mivel a tetszőleges oszlopok alapján a terhelés nem mindig egyenlő. (pl. több embernek neve C- vel kezdődik, nem pedig Z-vel ). Egyetlen szilánk, amelynél több kérés érkezik, mint mások, forró pontnak nevezik, és el kell kerülni. A felosztás után az adatok újrapróbálása hihetetlenül drágává válik, és jelentős leállást okozhat, mint például a FourSquare hírhedt 11 órás kiesése.

A példánk egyszerűsége érdekében tegyük fel, hogy ügyfelünk (a Rails alkalmazás) tudja, hogy melyik adatbázist használja az egyes rekordokhoz. Érdemes megjegyezni azt is, hogy a szilánkosításra számos stratégia létezik, és ez egy egyszerű példa a koncepció szemléltetésére.

Most elég sokat nyertünk - N- szer növelhetjük írási forgalmunkat, ahol N a szilánkok száma. Ez gyakorlatilag szinte semmilyen korlátot nem jelent számunkra - képzelje el, milyen finom szemcsésséget kaphatunk ezzel a particionálással.

Csapda

A szoftvertervezésben minden többé-kevésbé kompromisszum, és ez sem kivétel. A megosztás nem egyszerű bravúr, és a legjobb elkerülni, amíg valóban nincs rá szükség.

Most kulcsokkal kérdeztünka particionált kulcs kivételével hihetetlenül hatékony (az összes szilánkot át kell menniük). Az SQL JOINlekérdezések még rosszabbak, és a komplexek gyakorlatilag használhatatlanná válnak.

Decentralizált és elosztott

Mielőtt továbbmennénk, szeretnék különbséget tenni a két kifejezés között.

Annak ellenére, hogy a szavak hasonlóan hangzanak, és megállapítható, hogy logikailag ugyanazt jelentik, eltérésük jelentős technológiai és politikai hatást vált ki.

A decentralizált technikai értelembenmég mindig elosztott , de az egész decentralizált rendszert nem egy szereplő birtokolja. Egy vállalat sem birtokolhat decentralizált rendszert, különben már nem lenne decentralizált.

Ez azt jelenti, hogy a legtöbb olyan rendszert, amelyen ma át fogunk menni, elosztott központosított rendszernek lehet felfogni - és erre is készülnek.

Ha belegondolunk - nehezebb létrehozni egy decentralizált rendszert, mert akkor kezelnie kell azt az esetet, amikor a résztvevők egy része rosszindulatú. A normál elosztott rendszerek esetében ez nem így van, mivel tudja, hogy Ön az összes csomópont tulajdonosa.

Megjegyzés: Ez a meghatározás sokat vitatott, és összetéveszthető másokkal (peer-to-peer, föderált). A korai szakirodalomban másként definiálták. Ettől függetlenül, amit definícióként adtam meg, azt érzem, hogy a legszélesebb körben használom most, amikor a blokklánc és a kriptovaluták népszerűsítették ezt a kifejezést.

Elosztott rendszerkategóriák

Most néhány elosztott rendszerkategórián megyünk keresztül, és felsoroljuk azok legnagyobb nyilvánosan ismert gyártási felhasználását. Ne feledje, hogy a legtöbb ilyen szám elavult, és valószínűleg lényegesen nagyobb, amikor ezt olvassa.

Elosztott adattárolók

Az elosztott adattárolókat a legszélesebb körben használják és elosztott adatbázisként ismerik el. A legtöbb elosztott adatbázis NoSQL nem relációs adatbázis, amelyek kulcsérték-szemantikára korlátozódnak. Hihetetlen teljesítményt és méretezhetőséget biztosítanak a konzisztencia vagy a rendelkezésre állás árán.

Ismert skála - az Apple köztudottan 75 000 Apache Cassandra csomópontot használ, amelyek több mint 10 petabájt adatot tárolnak, még 2015-ben

Nem mehetünk el az elosztott adattárházak megbeszélésein a CAP-tétel bevezetése nélkül .

KAP-tétel

2002-ben bevált CAP-tétel kimondja, hogy az elosztott adattár nem lehet egyszerre következetes, elérhető és partíciót toleráns.

Néhány gyors definíció:

  • Következetesség - Amit egymás után olvas és ír, az elvárható (emlékszel a néhány bekezdés előtti adatbázis-replikációval kapott getchára?)
  • Elérhetőség - az egész rendszer nem hal meg - minden nem hibás csomópont mindig ad választ.
  • Partíciótűrő - A rendszer a hálózati partíciók ellenére továbbra is működik, és fenntartja következetességi / rendelkezésre állási garanciáit

A valóságban minden elosztott adattároló esetében meg kell adni a partíció toleranciáját. Mint sok helyen említettük, amelyek közül az egyik ez a nagyszerű cikk, nem lehet következetes és elérhető a partíciótűrés nélkül.

Gondoljon bele: ha van két csomópontja, amelyek elfogadják az információkat, és a kapcsolatuk megszűnik - hogyan lesznek mindketten elérhetőek, és egyúttal konzisztenciát nyújtanak? Nincs módjuk tudni, hogy mit csinál a másik csomópont, és mint ilyenek offline állapotba kerülhetnek (nem érhetők el), vagy elavult információkkal dolgozhatnak (inkonzisztensek) .

Végül azt kell választania, hogy erősen konzisztens-e vagy erősen elérhető-e a rendszere egy hálózati partíció alatt .

A gyakorlat azt mutatja, hogy a legtöbb alkalmazás jobban értékeli a rendelkezésre állást. Nem feltétlenül kell mindig erős következetesség. A kompromisszum akkor sem feltétlenül azért történik, mert szüksége van a 100% -os rendelkezésre állási garanciára, hanem azért, mert a hálózati késés problémát jelenthet, amikor a gépeket szinkronizálni kell az erős konzisztencia elérése érdekében. Ezek és még több tényező arra készteti az alkalmazásokat, hogy a magas rendelkezésre állás lehetőségét kínálják.

Az ilyen adatbázisok a leggyengébb konzisztencia modellel számolnak - az esetleges konzisztenciával (erős kontra az esetleges konzisztencia magyarázata) . Ez a modell garantálja, hogy ha nincs új frissítéseket, amelyeket egy adott tárgy, végül minden fér ebben az elem visszakerül a legújabb frissített érték.

Ezek a rendszerek BASE tulajdonságokat nyújtanak (szemben a hagyományos adatbázisok ACID-jével)

  • B asically A vailable - A rendszer mindig ad választ
  • S gyakran állapot - A rendszer idővel megváltozhat, még akkor is, amikor nincs bemenet (az esetleges konzisztencia miatt)
  • E ventuális konzisztencia - Bevitel hiányában az adatok előbb-utóbb minden csomópontra eljutnak - ezáltal konzisztenssé válnak

Példák ilyen elérhető elosztott adatbázisokra - Cassandra, Riak, Voldemort

Természetesen vannak más adattárak, amelyek az erősebb konzisztenciát kedvelik - HBase, Couchbase, Redis, Zookeeper

A CAP-tétel önmagában több cikket is megérdemel - némelyek arra vonatkoznak, hogy miként módosíthatjuk a rendszer CAP-tulajdonságait attól függően, hogy az ügyfél hogyan viselkedik, mások pedig attól, hogy azt miért nem értik megfelelően.

Cassandra

A Cassandra, mint fent említettük, egy elosztott No-SQL adatbázis, amely előnyben részesíti az AP tulajdonságokat a CAP-ból, és végül következetességgel rendezi. El kell ismernem, hogy ez kissé félrevezető lehet, mivel a Cassandra nagyon jól konfigurálható - a rendelkezésre állás rovására is erős konzisztenciát nyújthat, de nem ez a gyakori használati esete.

A Cassandra következetes kivonatolással határozza meg, hogy a fürtből mely csomópontoknak kell kezelniük az átadott adatokat. Beállít egy replikációs tényezőt , amely alapvetően azt állítja, hogy hány csomópontra kívánja replikálni az adatait.

Olvasáskor csak azokból a csomópontokból fog olvasni.

A Cassandra tömegesen skálázható, abszurd módon nagy írási teljesítményt nyújt.

Annak ellenére, hogy ez a diagram elfogult lehet, és úgy tűnik, hogy összehasonlítja a Cassandrát az erős konzisztencia biztosítása érdekében beállított adatbázisokkal (különben nem tudom, hogy a MongoDB miért esne vissza a teljesítményről, ha 4-ről 8 csomópontra frissítenénk), ennek mégiscsak meg kell mutatnia, hogy mi a helyesen beállított fel Cassandra klaszter képes.

Ettől függetlenül az elosztott rendszerek kompromisszumában, amely lehetővé teszi a horizontális méretezést és a hihetetlenül nagy áteresztőképességet, a Cassandra nem biztosítja az ACID adatbázisok néhány alapvető jellemzőjét - nevezetesen a tranzakciókat.

Konszenzus

Az adatbázis-tranzakciókat bonyolult megvalósítani az elosztott rendszerekben, mivel megkövetelik, hogy az egyes csomópontok állapodjanak meg a megfelelő teendőkről (megszakítás vagy elkövetés). Ezt konszenzusnak nevezik, és ez alapvető probléma az elosztott rendszerekben.

A „tranzakció lekötése” problémához szükséges megállapodástípus elérése egyszerű, ha a résztvevő folyamatok és a hálózat teljesen megbízhatóak. A valós rendszerek azonban számos lehetséges hibának vannak kitéve, mint például a folyamat összeomlása, a hálózati particionálás és az elveszett, torz vagy duplikált üzenetek.

Ez problémát vet fel - bebizonyosodott, hogy nem garantálható, hogy a nem konszenzusos hálózaton belül korlátozott időkereten belül sikerül helyes konszenzust elérni.

A gyakorlatban azonban vannak olyan algoritmusok, amelyek elég gyorsan konszenzusra jutnak egy nem megbízható hálózaton. A Cassandra valójában könnyű tranzakciókat biztosít a Paxos algoritmus használatával az elosztott konszenzus érdekében.

Elosztott számítástechnika

Az elosztott számítás a kulcsa a Big Data feldolgozás beáramlásának, amelyet az elmúlt években tapasztaltunk. Hatalmas feladat (pl. Összesít 100 milliárd rekordot) felosztása, amelynek egyetlen számítógép sem képes önmagában gyakorlatilag végrehajtani sok kisebb feladatot, amelyek mindegyike elfér egyetlen árucikkben. Hatalmas feladatát sok kisebbre osztja, sok gépen párhuzamosan hajtja végre, megfelelően összesíti az adatokat, és megoldotta a kezdeti problémát. Ez a megközelítés ismét lehetővé teszi, hogy vízszintesen méretezzen - ha nagyobb feladata van, egyszerűen vegyen fel több csomópontot a számításba.

Ismert skála - A Folding @ Home 160 ezer aktív géppel rendelkezett 2012-ben

Korai újítónak számított ezen a téren a Google, amelynek nagy mennyiségű adata miatt új paradigmát kellett kitalálnia az elosztott számításhoz - MapReduce. 2004-ben publikáltak róla egy cikket, és a nyílt forráskódú közösség később ennek alapján hozta létre az Apache Hadoopot.

MapReduce

A MapReduce egyszerűen két lépésként definiálható - az adatok feltérképezése és valami értelmessé redukálása.

Nézzük meg újra egy példával:

Tegyük fel, hogy közepesek vagyunk, és óriási információinkat egy másodlagos elosztott adatbázisban raktározási célokra tároltuk. 2017 áprilisában (egy évvel ezelőtt) minden nap kiadott tapsok számát képviselő adatokat szeretnénk lekérni.

Ez a példa a lehető legrövidebb, világosabb és egyszerűbb, de képzelje el, hogy rengeteg adattal dolgozunk (pl. Több milliárd taps elemzésével). Nem tároljuk mindezeket az információkat nyilvánvalóan egy gépen, és nem elemezzük mindezt egyetlen géppel. Ezenkívül nem a termelési adatbázist fogjuk lekérdezni, hanem inkább egy „raktári” adatbázist, amelyet kifejezetten alacsony prioritású offline munkákhoz készítettek.

Minden Map-feladat külön csomópont, amely a lehető legtöbb adatot átalakítja. Minden feladat bejárja az összes adatot az adott tároló csomópontban, és a dátum és az első egyszerű duplájára térképezi fel. Ezután három közbenső lépést hajtanak végre (amelyekről senki sem beszél) - keverés, rendezés és particionálás. Alapvetően tovább rendezik az adatokat, és törlik őket a megfelelő csökkentési munkára. Mivel nagy adatokkal foglalkozunk, mindegyik Reduce-feladatot elkülönítettük, hogy csak egyetlen dátumon dolgozzunk.

Ez egy jó paradigma, és meglepő módon lehetővé teszi, hogy sokat tegyen vele - például több MapReduce feladatot is láncolhat.

Jobb technikák

A MapReduce manapság kissé örökölt és problémákat okoz. Mivel kötegelt formában (munkaként) működik, felmerül egy probléma, amikor a munkája kudarcot vall - újra kell indítania az egészet. A 2 órás munka sikertelensége valóban lelassíthatja a teljes adatfeldolgozási folyamatot, és ezt a legkevésbé sem szeretné, különösen a csúcsidőben.

Egy másik kérdés az az idő, amikor megvárja, amíg megkapja az eredményeket. Valós idejű analitikai rendszerekben (amelyek mindegyikének nagy adatai vannak, és így elosztott számítástechnikát használnak) fontos, hogy a legfrissebb adatok a lehető legfrissebbek legyenek, és természetesen ne néhány órával ezelőtt.

Mint ilyen, más architektúrák jelentek meg, amelyek ezeket a kérdéseket kezelik. Nevezetesen a Lambda Architecture (a kötegelt feldolgozás és a stream feldolgozás keveréke) és a Kappa Architecture (csak a stream feldolgozása). A terület ezen előrelépései új eszközöket hoztak létre, amelyek lehetővé teszik számukra - Kafka-patakok, Apache Spark, Apache Storm, Apache Samza.

Elosztott fájlrendszerek

Az elosztott fájlrendszerek elosztott adattárolóknak tekinthetők. Ugyanazt jelentik, mint egy koncepció - nagy mennyiségű adat tárolása és elérése az összes egységként megjelenő gépcsoportban. Jellemzően együtt járnak az elosztott számítástechnikával.

Ismert skála - A Yahoo ismert arról, hogy több mint 42 000 csomóponton futtat HDFS-t 600 petabájtos adat tárolására, még 201-ben

A Wikipedia meghatározza azt a különbséget, hogy az elosztott fájlrendszerek lehetővé teszik a fájlok elérését ugyanazokkal a felületekkel és szemantikával, mint a helyi fájlok, nem pedig egy olyan egyedi API-n keresztül, mint a Cassandra Query Language (CQL).

HDFS

A Hadoop Distributed File System (HDFS) az elosztott fájlrendszer, amelyet a Hadoop keretrendszeren keresztül osztott számításhoz használnak. Széles körű elfogadással büszkélkedhet, nagy gépek (GB vagy TB méretű) fájlok tárolására és replikálására használják sok gépen.

Architektúrája főleg NameNodes és DataNodes áll . A NameNodes felelős a fürt metaadatainak megőrzéséért, például arról, hogy melyik csomópont melyik fájlblokkokat tartalmazza. Koordinátorokként működnek a hálózaton azzal, hogy kitalálják, hol tárolják és replikálják a fájlokat a legjobban, nyomon követve a rendszer állapotát. A DataNodes egyszerűen tárolja a fájlokat, és parancsokat hajt végre, például replikál egy fájlt, újat és másokat ír.

Nem meglepő, hogy a HDFS-t a Hadoop-tal lehet a legjobban használni a számításhoz, mivel az adattudatosságot biztosít a számítási feladatok számára. Ezeket a feladatokat az adatok tároló csomópontokon futtatják. Ez kihasználja az adat lokalitását - optimalizálja a számításokat és csökkenti a hálózat forgalmának mennyiségét.

IPFS

Az Interplanetary File System (IPFS) egy izgalmas új peer-to-peer protokoll / hálózat az elosztott fájlrendszer számára. A Blockchain technológiát felhasználva teljesen decentralizált architektúrával büszkélkedhet, egyetlen tulajdonos és kudarcpont nélkül.

Az IPFS egy IPNS nevű (a DNS-hez hasonló) névadási rendszert kínál, amely lehetővé teszi a felhasználók számára az információk egyszerű elérését. A fájlt a korábbi verziókban tárolja, hasonlóan a Githez. Ez lehetővé teszi a fájl összes korábbi állapotának elérését.

Még mindig súlyos fejlesztéseken megy keresztül (a v0.4 az írás idején), de már látott olyan projekteket, amelyek érdekelték a felépítését (FileCoin).

Elosztott üzenetküldés

Az üzenetkezelő rendszerek központi helyet biztosítanak az üzenetek / események tárolásához és terjesztéséhez a teljes rendszeren belül. Lehetővé teszik az alkalmazások logikájának leválasztását a többi rendszerrel való közvetlen beszélgetéstől.

Ismert skála - a LinkedIn Kafka-fürtje napi 1 billió üzenetet dolgozott fel, másodpercenként 4,5 millió üzenet csúcsával.

Egyszerűen fogalmazva: az üzenetküldő platform a következő módon működik:

Egy üzenetet sugároznak abból az alkalmazásból, amely potenciálisan létrehozza (nevezik gyártónak ), bemegy a platformra, és potenciálisan több alkalmazás is elolvassa, amelyek érdeklődnek iránta (úgynevezett fogyasztói ).

Ha egy bizonyos eseményt el kell mentenie néhány helyre (pl. Felhasználó létrehozása az adatbázisba, a raktárba, az e-mail küldő szolgáltatás és bármi más, amire csak lehet), akkor az üzenetkezelő platform a legtisztább módszer az üzenet terjesztésére.

A fogyasztók vagy kihúzhatják az információkat a brókerekből (pull modell), vagy pedig azt, hogy a brókerek az információkat közvetlenül a fogyasztókba tolják (push modell).

Van néhány népszerű csúcsminőségű üzenetküldő platform:

RabbitMQ - Üzenet-közvetítő, amely lehetővé teszi az üzenet pályáinak finomabb ellenőrzését útválasztási szabályok és más, könnyen konfigurálható beállítások segítségével. Nevezhető okos brókernek, mivel sok logika van benne, és szorosan nyomon követi az azon áthaladó üzeneteket. Beállításokat kínál, mind az AP és a CP származó CAP . Push modellt használ a fogyasztók értesítésére.

Kafka - Üzenet-közvetítő (és minden platform), amely valamivel alacsonyabb szintű, mivel nem követi nyomon, mely üzeneteket olvasta el, és nem teszi lehetővé az összetett útválasztási logikát. Ez segít elképesztő teljesítmény elérésében. Véleményem szerint ez a legnagyobb kilátás ezen a téren, a nyílt forráskódú közösség aktív fejlesztésével és a Confluent csapat támogatásával. A Kafka vitathatatlanul a legelterjedtebb technológiát alkalmazza a csúcstechnológiai vállalatok részéről. Ehhez alapos bevezetőt írtam, ahol részletesen bemutatom annak minden jóságát.

Apache ActiveMQ - A legrégebbi a csomagból, 2004-ből származik. A JMS API-t használja, ami azt jelenti, hogy a Java EE alkalmazásokhoz igazodik. ActiveMQ Artemis néven írták át, amely kiemelkedő teljesítményt nyújt Kafkával egyenértékűen.

Amazon SQS - Az AWS által nyújtott üzenetküldő szolgáltatás. Lehetővé teszi, hogy gyorsan integrálja a meglévő alkalmazásokba, és feleslegessé válik a saját infrastruktúrájának kezelése, ami nagy előny lehet, mivel a Kafka-hoz hasonló rendszerek felállítása köztudottan trükkös. Az Amazon két hasonló szolgáltatást is kínál - az SNS-t és az MQ-t, amelyek közül az utóbbi alapvetően ActiveMQ, de az Amazon kezeli.

Elosztott alkalmazások

Ha 5 Rails kiszolgálót állít össze egyetlen terheléselosztó mögé, amelyek mindegyike egy adatbázishoz kapcsolódik, akkor ezt elosztott alkalmazásnak hívhatja? Emlékezzünk a fenti definíciómra:

Az elosztott rendszer olyan számítógépek csoportja, amelyek együtt dolgoznak, és egyetlen számítógépként jelennek meg a végfelhasználó számára. Ezek a gépek megosztott állapotúak, egyidejűleg működnek és függetlenül is meghibásodhatnak anélkül, hogy befolyásolnák a rendszer teljes üzemidejét.

Ha megosztott állapotnak számít az adatbázis, akkor azzal érvelhet, hogy ez elosztott rendszernek minősíthető - de tévedne, mivel elmulasztotta a definíció „ együtt dolgozni ” részét.

A rendszer csak akkor oszlik meg, ha a csomópontok kommunikálnak egymással, hogy összehangolják tevékenységeiket.

Ezért olyasmi, mint egy alkalmazás, amelynek háttérkódját peer-to-peer hálózaton futtatják, jobban osztályozható elosztott alkalmazásként. Ettől függetlenül ez mind felesleges besorolás, amely semmilyen célt nem szolgál, de szemlélteti, hogy mennyire nyűgösek vagyunk a dolgok csoportosításában.

Ismert skála - a BitTorrent 193 000 csomópontból áll a Trónok játéka epizódja számára, 2014. április

Erlang virtuális gép

Az erlang egy funkcionális nyelv, amely nagy szemantikával rendelkezik az egyidejűség, eloszlás és hibatűrés szempontjából. Az Erlang virtuális gép maga kezeli az Erlang alkalmazás terjesztését.

Modellje úgy működik, hogy sok elszigetelt, könnyű folyamat van, amelyek mind képesek egymással beszélgetni a beépített üzenetátviteli rendszeren keresztül. Ezt színészi modellnek hívjákaz Erlang OTP könyvtárak pedig elosztott szereplői keretrendszerként tekinthetők (Akka mentén a JVM számára).

A modell az, ami egyszerűen egyszerűvé teszi a nagy párhuzamosság elérését - a folyamatok el vannak osztva az őket futtató rendszer elérhető magjain. Mivel ez nem különböztethető meg a hálózati beállítástól (az üzenetek eldobásának lehetőségétől eltekintve), az Erlang virtuális gépe csatlakozni tud más, ugyanabban az adatközpontban vagy akár egy másik kontinensen futó Erlang virtuális gépekhez. Ez a virtuális gépek rajza egyetlen alkalmazást futtat, és átveszi a gép hibáit (egy másik csomópont futását ütemezik).

Valójában a nyelv elosztott rétegét adták hozzá a hibatűrés biztosítása érdekében. Az egyetlen gépen futó szoftvereket mindig annak a veszélye fenyegeti, hogy az egyetlen gép meghal, és offline állapotba hozza az alkalmazást. A sok csomóponton futó szoftver megkönnyíti a hardverhibák kezelését, feltéve, hogy az alkalmazást erre gondolták.

BitTorrent

A BitTorrent az egyik legszélesebb körben használt protokoll nagy fájlok interneten keresztüli átviteléhez torrenteken keresztül. A fő gondolat az, hogy megkönnyítse a fájlok átvitelét a hálózat különböző társai között anélkül, hogy át kellene mennie egy fő szerveren.

A BitTorrent kliens használatával világszerte több számítógéphez csatlakozik egy fájl letöltéséhez. Amikor megnyit egy .torrent fájlt, csatlakozik egy úgynevezett trackerhez , amely koordinátorként működő gép. Segít a társak felfedezésében, megmutatja a hálózat azon csomópontjait, amelyek rendelkeznek a kívánt fájllal.

Kétféle felhasználói elképzelésed van: egy pióca és egy magvető . Leecher az a felhasználó, aki fájlt tölt le, és a seeder az a felhasználó, aki feltölti a fájlt.

A peer-to-peer hálózatokban az a vicces, hogy Ön, mint egyszerű felhasználó, képes csatlakozni és hozzájárulni a hálózathoz.

A BitTorrent és prekurzorai (Gnutella, Napster) lehetővé teszik a fájlok önkéntes tárolását és feltöltését más felhasználóknak, akik szeretnék őket. A BitTorrent annyira népszerű oka, hogy elsőként ösztönözte a hálózathoz való hozzájárulást. A korábbi fájlmegosztási protokollok problémája volt a freeriding , ahol a felhasználó csak fájlokat töltött le.

A BitTorrent bizonyos mértékben megoldotta a freeridinget azáltal, hogy a vetőgépek többet töltöttek fel azoknak, akik a legjobb letöltési arányt nyújtják. Ez úgy működik, hogy arra ösztönzi Önt, hogy töltsön fel egy fájl letöltése közben. Sajnos, miután végzett, semmi sem teszi aktívvá a hálózatban. Ez azt jelenti, hogy hiányzik a hálózatból a teljes fájl birtokában lévő vetőgép, és mivel a protokoll nagymértékben az ilyen felhasználókra támaszkodik, megvalósultak olyan megoldások, mint a privát nyomkövetők. A privát nyomkövetők egy elosztott hálózatban való részvételhez megkövetelik, hogy egy közösség tagja legyen (gyakran csak meghívásos).

A területen történt előrelépések után tracker nélküli torrenteket találtak ki. Ez a BitTorrent protokoll frissítése volt, amely nem a központi nyomkövetőkre támaszkodott a metaadatok összegyűjtésében és a társak felkutatásában, hanem új algoritmusokat használt. Ilyen például a Kademlia (Mainline DHT), egy elosztott hash-tábla (DHT), amely lehetővé teszi, hogy társait megtalálja más társakon keresztül. Valójában minden felhasználó elvégzi a nyomkövető feladatait.

Elosztott nagykönyvek

Az elosztott főkönyv változhatatlan, csak függelékként létrehozott adatbázisnak tekinthető, amelyet replikálnak, szinkronizálnak és megosztanak az elosztott hálózat összes csomópontján.

Ismert skála - Az Ethereum Network csúcsa napi 1,3 millió tranzakció volt 2018. január 4-én.

Kihasználják az Eseményforrás mintát, amely lehetővé teszi, hogy a történelem bármikor újjáépítse a főkönyv állapotát.

Blockchain

A Blockchain az elosztott főkönyveknél használt jelenlegi alaptechnológia, amely valójában a kezdetüket jelentette. Ez a legújabb és legnagyobb újítás az elosztott térben lehetővé tette az első valóban elosztott fizetési protokoll - a Bitcoin - létrehozását.

A Blockchain egy elosztott főkönyv, amely a hálózatában valaha történt összes tranzakció megrendelt listáját tartalmazza. A tranzakciókat blokkokban csoportosítják és tárolják. Az egész blokklánc lényegében a blokkok összekapcsolt listája (innen a név) . Az említett blokkok létrehozása számítási szempontból drága, és a kriptográfia révén szorosan kapcsolódik egymáshoz.

Egyszerűen szólva, minden blokk tartalmaz egy speciális kivonatot (amely X összegű nullával kezdődik) az aktuális blokk tartalmáról (Merkle-fa formájában), valamint az előző blokk hash-jával. Ez a hash sok CPU-energiát igényel, mert a nyers erővel csak így lehet előállni.

A bányászok azok a csomópontok, akik megpróbálják kiszámítani a kivonatot (bruteforce-on keresztül). A bányászok mind versenyeznek egymással azért, hogy ki tudjon találni egy véletlenszerű karakterláncot (úgynevezett nonce-t ), amely a tartalommal kombinálva előállítja a fent említett kivonatot. Miután valaki megtalálta a megfelelő nonce-t, azt az egész hálózatra sugározza. Az említett húrokat ezután minden csomópont önmagában ellenőrzi, és elfogadja a láncukba.

Ez olyan rendszerré alakul, ahol abszurd módon költséges módosítani a blokkláncot, és abszurd módon könnyű ellenőrizni, hogy nem hamisították-e meg.

A blokk tartalmának megváltoztatása költséges, mert az más kivonatot eredményezne. Ne feledje, hogy minden következő blokk hashja attól függ. Ha a fenti kép első blokkjában változtatna egy tranzakciót - megváltoztatná a Merkle gyökerét. Ez viszont megváltoztatná a blokk kivonatát (nagy valószínűséggel a szükséges vezető nullák nélkül) - ez megváltoztatná a 2. blokk hashját és így tovább, és így tovább. Ez azt jelenti, hogy minden blokkhoz egy új nonce-t kell kényszerítenie az imént módosított után.

A hálózat mindig bízik és megismétli a leghosszabb érvényes láncot. Annak érdekében, hogy kijátsszák a rendszert, és végül készítsen egy hosszabb szénláncú meg kéne több, mint 50% -át a CPU által használt összes csomópontot.

A blokklánc a felmerülő konszenzus elosztott mechanizmusának tekinthető . A konszenzust nem érik el kifejezetten - nincsenek választások vagy rögzített pillanat, amikor a konszenzus bekövetkezik. Ehelyett a konszenzus a független csomópontok ezreinek aszinkron interakciójának egy új terméke, amelyek mind a protokoll szabályait követik.

Ez a példátlan innováció a közelmúltban a technológiai tér fellendülésévé vált, és az emberek azt jósolták, hogy ez a Web 3.0 létrehozását fogja jelenteni. A szoftvergyártás világának mindenképpen ez a legizgalmasabb hely, tele rendkívül kihívást jelentő és érdekes megoldásra váró problémákkal.

Bitcoin

A korábbi elosztott fizetési protokollokból hiányzott az a módszer, hogy valós időben, elosztott módon megakadályozzuk a kettős kiadási problémát. A kutatások érdekes javaslatokat hoztak létre [1], de a Bitcoin elsőként vezetett be gyakorlati megoldást, amelynek egyértelmű előnyei voltak a többiekkel szemben.

A kettős kiadási probléma azt állítja, hogy egy színész (pl. Bob) egyetlen forrását nem költheti el két helyen. Ha Bobnak 1 dollárja van, akkor nem kellene képes azt odaadni Alice-nek és Zacknek is - ez csak egy eszköz, nem másolható. Kiderült, hogy nagyon nehéz ezt a garanciát valóban elosztott rendszerben megvalósítani. Van néhány érdekes enyhítési megközelítés, amely megelőzi a blokkláncot, de gyakorlati úton nem oldják meg teljesen a problémát.

A kettős költést a Bitcoin könnyen megoldja, mivel egyszerre csak egy blokk kerül a láncba. A kettős kiadás lehetetlen egyetlen blokkon belül, ezért még akkor is, ha egyszerre két blokkot hoznak létre - csak egy kerül a leghosszabb láncra.

A Bitcoin a CPU-energia felhalmozásának nehézségeire támaszkodik.

Míg egy szavazási rendszerben a támadónak csak csomópontokat kell hozzáadnia a hálózathoz (ami egyszerű, mivel a hálózathoz való szabad hozzáférés tervezési célpont), addig a CPU energiaalapú sémájában a támadó fizikai korlátokkal szembesül: egyre többhez férhet hozzá. erős hardver.

Ez az oka annak is, hogy a csomópontok rosszindulatú csoportjainak a hálózat számítási teljesítményének 50% -át kell irányítaniuk ahhoz, hogy valóban sikeres támadást hajtsanak végre. Ennél kevesebb, és a hálózat többi része gyorsabban hoz létre egy hosszabb blokkláncot.

Ethereum

Az Ethereum programozható blokklánc-alapú szoftverplatformnak tekinthető. Saját kriptovalutával (Ether) rendelkezik, amely az intelligens szerződések telepítését táplálja blokkláncán.

Az intelligens szerződések egy kódrészlet, amelyet egyetlen tranzakcióként tárolnak az Ethereum blokkláncban. A kód futtatásához mindössze annyit kell tennie, hogy tranzakciót kell kiállítania intelligens szerződéssel, amelynek célja. Ez pedig arra készteti a bányász csomópontokat, hogy végrehajtják a kódot, és bármilyen változással jár is. A kód az Ethereum virtuális gépen belül kerül végrehajtásra.

A szilárdság , az Ethereum anyanyelvi programnyelve, az okos szerződések megírására szolgál. Ez egy teljes programozási nyelv, amely közvetlenül kapcsolódik az Ethereum blokklánchoz, lehetővé téve az állapot lekérdezését, például egyenlegeket vagy más intelligens szerződéses eredményeket. A végtelen hurkok megakadályozása érdekében a kód futtatásához bizonyos mennyiségű éterre van szükség.

Mivel a blokklánc állapotváltozások sorozataként értelmezhető, rengeteg elosztott alkalmazást (DApps) építettek az Ethereum és hasonló platformok tetejére.

Az elosztott főkönyvek további felhasználása

A létezés igazolása - Anonim módon és biztonságosan tárolt szolgáltatás annak bizonyítására, hogy egy bizonyos digitális dokumentum létezett valamikor. Hasznos a dokumentum integritásának, tulajdonjogának és időbélyegzésének biztosításához.

Decentralizált Autonóm Szervezetek (DAO) - olyan szervezetek, amelyek blokkláncot használnak a konszenzus elérésének eszközeként a szervezet fejlesztési javaslataival kapcsolatban. Ilyen például a Dash irányítási rendszere, a SmartCash projekt

Decentralizált hitelesítés - Tárolja identitását a blokkláncon, lehetővé téve az egyszeri bejelentkezés (SSO) használatát mindenhol. Sovrin, Polgári

És még sokan. Az elosztott főkönyvi technológia valóban végtelen lehetőségeket nyitott meg. Néhányat valószínűleg most találunk ki, amikor beszélünk!

Összegzés

A cikk rövid szakaszában sikerült meghatároznunk, hogy mi az elosztott rendszer, miért használna egyet, és kicsit átnézné az egyes kategóriákat. Néhány fontos dolog, amire emlékezni kell:

  • Az elosztott rendszerek összetettek
  • A méret és az ár szükségessége alapján választják meg őket
  • Nehezebb velük dolgozni
  • KAP-tétel - konzisztencia / elérhetőség kompromisszum
  • 6 kategóriájuk van - adattárak, számítástechnika, fájlrendszerek, üzenetküldő rendszerek, főkönyvek, alkalmazások

Hogy őszinte legyek, alig értünk az elosztott rendszerek felületéhez. Nem volt alkalmam alaposan megoldani és megmagyarázni azokat az alapvető problémákat, mint a konszenzus, a replikációs stratégiák, az események sorrendje és ideje, a hibatűrés, az üzenet közvetítése a hálózaton keresztül és mások.

Vigyázat

Hadd hagyjak önöket egy elváló előrejelzéssel:

Amennyire lehet, el kell térnie az elosztott rendszerektől. Az önmagukkal járó bonyolult rezsi nem éri meg az erőfeszítéseket, ha elkerülheted a problémát akár más módon, akár más dobozon kívüli megoldással.

[1]

A kettős kiadások leküzdése a szövetkezeti P2P rendszerek használatával, 2007. június 25–27. - egy javasolt megoldás, amelyben az egyes „érmék” lejárhatnak, és tanúkat (validátorokat) rendelhetnek hozzájuk.

Bitgold , 2005. december - A Bitcoin protokolljaihoz rendkívül hasonló protokoll magas szintű áttekintése. Állítólag ez a Bitcoin előfutára.

További elosztott rendszerek olvasása:

Adatintenzív alkalmazások tervezése, Martin Kleppmann - Remek könyv, amely mindent áttekint az elosztott rendszerekben és még sok minden mást.

Felhőalapú számítástechnika szakirány, Illinoisi Egyetem, Coursera - Hosszú tanfolyamok (6), amelyek áttekintik az elosztott rendszer koncepcióit, az alkalmazásokat

Jepsen - Blog, amely sok elosztott technológiát ismertet (ElasticSearch, Redis, MongoDB stb.)

Köszönjük, hogy szánt időt arra, hogy átolvassa ezt a hosszú (~ 5600 szó) cikket!

Ha véletlenül megtalálta ezt az informatív információt, vagy úgy gondolta, hogy értéket nyújt Önnek, kérjük, győződjön meg arról, hogy annyi tapsot ad neki, amiről úgy gondolja, hogy megérdemli, és fontolja meg, hogy megossza azt egy barátjával, aki bevezetheti ezt a csodálatos tanulmányi területet.

~ Stanislav Kozlovski

Frissítés

Jelenleg a Confluentnél dolgozom. A Confluent egy Big Data vállalat, amelyet maguk az Apache Kafka alkotói alapítottak! Rendkívül hálás vagyok a lehetőségért, amelyet kaptak - jelenleg magán a Kafkán dolgozom, ami túl fantasztikus! Mi a Confluent-nél segítünk a teljes nyílt forráskódú Kafka ökoszisztéma alakításában, beleértve egy új, felügyelt Kafka-as-a-service felhő kínálatot is.

Nagyon sok pozíciót (főleg SRE / Software Engineers) veszünk fel Európában és az USA-ban! Ha érdekel, hogy maga a Kafka dolgozik, új lehetőségeket keres, vagy egyszerűen kíváncsi - mindenképpen küldjön üzenetet a Twitteren, és megosztom az összes nagyszerű juttatást, ami egy öböl környéki társaságban végzett munkából származik.