Temeljit uvod u distribuirane sustave

Što je distribuirani sustav i zašto je tako kompliciran?

Sa sve većom tehnološkom ekspanzijom svijeta, distribuirani sustavi postaju sve više i više rašireni. Oni su ogromno i složeno područje studija informatike.

Ovaj članak ima za cilj upoznati vas s distribuiranim sustavima na osnovni način, pokazujući vam uvid u različite kategorije takvih sustava, a pritom ne zaranjajući duboko u detalje.

Što je distribuirani sustav?

Distribuirani sustav u svojoj najjednostavnijoj definiciji je skupina računala koja rade zajedno kako bi se krajnjem korisniku prikazala kao jedno računalo.

Ovi strojevi imaju zajedničko stanje, rade istovremeno i mogu neovisno otkazati bez utjecaja na vrijeme rada cijelog sustava.

Predlažem da postupno radimo na primjeru distribucije sustava tako da možete bolje razumjeti sve to:

Krenimo s bazom podataka! Tradicionalne baze podataka pohranjuju se u datotečni sustav jednog stroja, kad god želite dohvatiti / umetnuti podatke u njega - izravno razgovarate s tim strojem.

Da bismo mogli distribuirati ovaj sustav baza podataka, trebali bismo pokretati ovu bazu podataka na više računala istovremeno. Korisnik mora biti u mogućnosti razgovarati s bilo kojim strojem koji odabere i ne smije moći reći da ne razgovara s jednim strojem - ako umetne zapis u čvor # 1, čvor # 3 mora moći vratiti taj zapis.

Zašto distribuirati sustav?

Sustavi se uvijek distribuiraju po potrebi. Istina je u tome što je upravljanje distribuiranim sustavima složena tema prepuna zamki i nagaznih mina. Glavobolja je postavljati, održavati i ispravljati pogreške u distribuiranim sustavima, pa zašto onda uopće ići tamo?

Ono što vam omogućuje distribuirani sustav jest vodoravno skaliranje . Vraćajući se na naš prethodni primjer jednog poslužitelja baze podataka, jedini način da se obradi veći promet bio bi nadogradnja hardvera na kojem radi baza podataka. To se naziva vertikalno skaliranje .

Vertikalno skaliranje je dobro i dobro dok možete, ali nakon određene točke vidjet ćete da čak ni najbolji hardver nije dovoljan za dovoljno prometa, a da ne spominjemo da je nepraktično hostirati.

Horizontalno skaliranje jednostavno znači dodavanje više računala, a ne nadogradnju hardvera jednog.

Znatno je jeftinije od vertikalnog skaliranja nakon određenog praga, ali to nije njegov glavni slučaj za prednost.

Vertikalno skaliranje može samo poboljšati vaše performanse do najnovijih hardverskih mogućnosti. Te se mogućnosti pokazuju nedovoljnima za tehnološke tvrtke s umjerenim do velikim radnim opterećenjem.

Najbolja stvar kod vodoravnog skaliranja je što nemate ograničenja koliko možete skalirati - kad god se performanse pogoršaju, jednostavno dodate još jedan stroj, do potencijalno beskonačnosti.

Jednostavno skaliranje nije jedina korist koju imate od distribuiranih sustava. Tolerancija grešaka i mala latencija također su jednako važni.

Tolerancija kvarova - klaster od deset strojeva u dva podatkovna centra u biti je otporniji na kvarove od jednog stroja. Čak i ako se jedan podatkovni centar zapali, vaša bi aplikacija i dalje radila.

Niska latencija - Vrijeme mrežnog paketa da putuje svijetom fizički je ograničeno brzinom svjetlosti. Primjerice, najkraće moguće vrijeme za povratno putovanje zahtjeva (odnosno kretanje naprijed-natrag) u svjetlovodnom kabelu između New Yorka i Sydneya iznosi 160 ms. Distribuirani sustavi omogućuju vam da imate čvor u oba grada, omogućujući prometu da pogodi čvor koji mu je najbliži.

Da bi distribuirani sustav funkcionirao, potreban vam je softver koji se izvodi na tim strojevima, posebno dizajniran za istodobno pokretanje na više računala i rješavanje problema koji dolaze s njim. Pokazalo se da to nije nimalo lak podvig.

Skaliranje naše baze podataka

Zamislite da je naša web aplikacija postala ludo popularna. Zamislite također da je naša baza podataka počela dobivati ​​dvostruko više upita u sekundi nego što može podnijeti. Izvedba vaše aplikacije odmah bi počela opadati, a to bi primijetili vaši korisnici.

Radimo zajedno i napravimo ljestvicu baze podataka kako bi udovoljila našim visokim zahtjevima.

U tipičnoj web aplikaciji informacije obično čitate puno češće nego što unosite nove ili mijenjate stare.

Postoji način za povećanje performansi čitanja, a to je takozvana strategija replikacije primarne replike . Ovdje stvarate dva nova poslužitelja baze podataka koji se sinkroniziraju s glavnim. Kvar je u tome što možete čitati samo s ovih novih primjeraka.

Kad god umetnete ili izmijenite informacije - razgovarate s primarnom bazom podataka. Ona zauzvrat asinkrono informira replike promjene i oni je također spremaju.

Čestitamo, sada možete izvršiti 3x više upita za čitanje! Nije li ovo sjajno?

Zamka

Imam te! Odmah smo izgubili C u jamstvu ACID-a naše relacijske baze podataka , što znači dosljednost.

Vidite, sada postoji mogućnost da umetnemo novi zapis u bazu podataka, odmah potom izdamo upit za čitanje i ne dobijemo ništa natrag, kao da ne postoji!

Proširivanje novih podataka s primarne na repliku ne događa se trenutno. Zapravo postoji vremenski prozor u kojem možete dohvatiti zastarjele informacije. Da to nije slučaj, vaša bi izvedba upisa patila, jer bi morala sinhrono čekati širenje podataka.

Distribuirani sustavi dolaze s pregršt kompromisa. Ovo je posebno pitanje s kojim ćete morati živjeti ako želite adekvatno skalirati.

Nastavak skaliranja

Koristeći pristup bazi podataka replika, možemo donekle vodoravno prilagoditi čitani promet. To je sjajno, ali pogodili smo zid u odnosu na naš promet pisanja - i dalje je sve na jednom poslužitelju!

Ovdje nam ne preostaje puno mogućnosti. Jednostavno moramo svoj promet pisanja podijeliti na više poslužitelja jer jedan nije u mogućnosti to riješiti.

Jedan od načina je ići s multi-primarnom strategijom replikacije. Tamo, umjesto replika s kojih možete samo čitati, imate više primarnih čvorova koji podržavaju čitanje i pisanje. Nažalost, ovo se vrlo brzo zakomplicira jer sada imate mogućnost stvaranja sukoba (npr. Umetnite dva zapisa s istim ID-om).

Krenimo s drugom tehnikom koja se naziva oštrenje(naziva se i particioniranje ).

Shardingom podijelite svoj poslužitelj na više manjih poslužitelja, koji se nazivaju krhotine. Sve ove krhotine sadrže različite zapise - vi stvarate pravilo o tome u koju vrstu zapisa ulaze neke krhotine. Vrlo je važno stvoriti pravilo tako da se podaci šire na jedinstven način .

Mogući pristup ovome je definiranje raspona prema nekim informacijama o zapisu (npr. Korisnici s imenom AD).

Ovaj ključ za oštrenje treba odabrati vrlo pažljivo, jer opterećenje nije uvijek jednako na temelju proizvoljnih stupaca. (npr. više ljudi ima imena koja počinju s C umjesto Z ). Pojedinačna krhotina koja primi više zahtjeva od ostalih naziva se žarišnom točkom i mora se izbjegavati. Jednom podijeljeni, ponovno oštrenje podataka postaje nevjerojatno skupo i može prouzročiti znatan zastoj, kao što je bio slučaj s neslavnim prekidom rada tvrtke FourSquare od 11 sati.

Da bi naš primjer bio jednostavan, pretpostavimo da naš klijent (aplikacija Rails) zna koju bazu podataka koristiti za svaki zapis. Također je vrijedno napomenuti da postoji mnogo strategija za oštrenje i ovo je jednostavan primjer koji ilustrira koncept.

Trenutno smo poprilično osvojili - možemo povećati promet upisa N puta, gdje je N broj krhotina. To nam praktički ne daje gotovo nikakvo ograničenje - zamislite koliko sitnozrnatog možemo dobiti ovom pregradom.

Zamka

Sve je u softverskom inženjerstvu manje-više kompromis i to nije iznimka. Oštrenje nije jednostavan podvig i najbolje ga je izbjegavati dok stvarno ne zatreba.

Sad smo izvršili upite po ključevimaosim pregrađenog ključa nevjerojatno neučinkovit (trebaju proći kroz sve krhotine). SQL JOINupiti su još gori, a složeni postaju praktički neupotrebljivi.

Decentralizirano u odnosu na distribuirano

Prije nego što nastavimo dalje, želio bih napraviti razliku između ta dva pojma.

Iako riječi zvuče slično i može se zaključiti da logično isto znače, njihova razlika ima značajan tehnološki i politički utjecaj.

Decentralizirani se još uvijek distribuira u tehničkom smislu, ali cijeli decentralizirani sustav nije u vlasništvu jednog aktera. Niti jedna tvrtka ne može posjedovati decentralizirani sustav, inače više ne bi bila decentralizirana.

To znači da većinu sustava koje ćemo danas razmotriti možemo smatrati distribuiranim centraliziranim sustavima - a to je ono što su stvoreni.

Ako dobro razmislite - teže je stvoriti decentralizirani sustav jer tada trebate riješiti slučaj kada su neki od sudionika zlonamjerni. To nije slučaj s normalnim distribuiranim sustavima, jer znate da ste vlasnik svih čvorova.

Napomena: O ovoj se definiciji puno raspravljalo i može se zamijeniti s drugima (peer-to-peer, federated). U ranoj literaturi također je drugačije definirano. Bez obzira na to, ono što sam vam dao kao definiciju je ono što smatram da se najčešće koristi sada kad su blockchain i kriptovalute popularizirali taj pojam.

Kategorije distribuiranog sustava

Sada ćemo proći kroz nekoliko distribuiranih kategorija sustava i navesti njihovu najveću javno poznatu proizvodnju. Imajte na umu da je većina prikazanih brojeva zastarjela i najvjerojatnije je znatno veća u vrijeme kada ovo čitate.

Distribuirane pohrane podataka

Distribuirane pohrane podataka najčešće se koriste i prepoznaju kao distribuirane baze podataka. Većina distribuiranih baza podataka su NoSQL nerelacijske baze podataka, ograničene na semantiku ključ / vrijednost. Pružaju nevjerojatne performanse i skalabilnost po cijenu dosljednosti ili dostupnosti.

Poznata skala - poznato je da Apple koristi 2015. godinu 75.000 čvorova Apache Cassandra za pohranu više od 10 petabajta podataka

Ne možemo ulaziti u rasprave o distribuiranim spremištima podataka bez prethodnog uvođenja CAP teorema.

Teorem KAPE

Dokazano još 2002. godine, CAP teorem kaže da distribuirana pohrana podataka ne može istovremeno biti dosljedna, dostupna i tolerantna na particije.

Neke brze definicije:

  • Dosljednost - Ono što čitate i pišete uzastopno je ono što se očekuje (sjetite se problema s replikacijom baze podataka prije nekoliko odlomaka?)
  • Dostupnost - cijeli sustav ne umire - svaki čvor koji ne otkaže uvijek vraća odgovor.
  • Tolerantno na particije - Sustav nastavlja funkcionirati i održava svoja jamstva za dosljednost / dostupnost unatoč mrežnim particijama

U stvarnosti, tolerancija particije mora biti dana za bilo koju distribuiranu pohranu podataka. Kao što je spomenuto na mnogim mjestima, od kojih je jedan sjajan članak, ne možete imati dosljednost i dostupnost bez tolerancije particija.

Razmislite o tome: ako imate dva čvora koji prihvaćaju informacije i njihova veza umire - kako će oba biti dostupna i istovremeno vam pružiti dosljednost? Oni nikako ne mogu znati što drugi čvor radi i kao takvi mogu ili postati izvanmrežni (nedostupni) ili raditi sa zastarjelim informacijama (nedosljedni) .

Na kraju vam preostaje da odaberete želite li da vaš sustav bude čvrsto konzistentan ili visoko dostupan na mrežnoj particiji .

Praksa pokazuje da većina aplikacija više cijeni dostupnost. Nije vam uvijek potrebna snažna dosljednost. Čak i tada taj kompromis nije nužno napravljen jer vam je potrebno 100% jamstvo dostupnosti, već zato što mrežna kašnjenja mogu predstavljati problem kada morate sinkronizirati strojeve da biste postigli snažnu dosljednost. Ovi i više čimbenika čine da se aplikacije obično odlučuju za rješenja koja nude visoku dostupnost.

Takve baze podataka podmiruju se s najslabijim modelom dosljednosti - eventualnom dosljednošću (objašnjenje jake vs eventualne dosljednosti) . Ovaj model jamči da će, ako se ne izvrše nova ažuriranja određene stavke, na kraju svi pristupi toj stavci vratiti najnoviju ažuriranu vrijednost.

Ti sustavi pružaju BASE svojstva (za razliku od tradicionalnih baza podataka 'ACID')

  • B asically zicije Raspolo - Sustav uvijek vraća odgovor
  • S često stanje - Sustav može se mijenjati tijekom vremena, čak i za vrijeme bez unosa (zbog eventualnog konzistencije)
  • E ventual dosljednost - U nedostatku unosa, podaci će se širiti na svakom čvoru prije ili kasnije - na taj način postaju dosljedni

Primjeri takvih dostupnih distribuiranih baza podataka - Cassandra, Riak, Voldemort

Naravno, postoje i druge pohrane podataka kojima je draža dosljednost - HBase, Couchbase, Redis, Zookeeper

CAP teorem sam po sebi zaslužuje više članaka - neki o tome kako možete podesiti svojstva CAP-a sustava ovisno o ponašanju klijenta, a drugi o tome kako se ne razumije ispravno.

Cassandra

Cassandra, kao što je gore spomenuto, distribuirana je baza podataka bez SQL-a koja preferira AP svojstva izvan CAP-a, rješavajući se eventualnom dosljednošću. Moram priznati da ovo može biti malo zavaravajuće, jer se Cassandra vrlo može konfigurirati - možete je stvoriti snažnom dosljednošću i na štetu dostupnosti, ali to nije uobičajeni slučaj.

Cassandra koristi dosljedno raspršivanje kako bi utvrdila koji čvorovi izvan klastera moraju upravljati podacima koje prosljeđujete. Postavljate faktor replikacije koji u osnovi navodi na koliko čvorova želite replicirati vaše podatke.

Tijekom čitanja čitati ćete samo s tih čvorova.

Cassandra je masivno skalabilna, pružajući apsurdno veliku propusnost pisanja.

Iako bi ovaj dijagram mogao biti pristran i čini se da uspoređuje Cassandru s bazama podataka postavljenim za pružanje snažne dosljednosti (inače ne mogu vidjeti zašto bi MongoDB padao u performansama kada se nadogradi s 4 na 8 čvorova), to bi ipak trebalo pokazati što je pravilno postavljeno gore grozd Cassandra je sposoban za.

Bez obzira na to, u kompromisu distribuiranih sustava koji omogućuje horizontalno skaliranje i nevjerojatno veliku propusnost, Cassandra ne pruža neke temeljne značajke ACID baza podataka - naime, transakcije.

Konsenzus

Transakcije baze podataka vrlo je teško implementirati u distribuiranim sustavima jer zahtijevaju da se svaki čvor dogovori o ispravnoj radnji (prekida ili urezivanja). To je poznato kao konsenzus i temeljni je problem u distribuiranim sustavima.

Postizanje vrste sporazuma potrebnog za problem „izvršavanje transakcije“ jednostavno je ako su procesi koji sudjeluju i mreža potpuno pouzdani. Međutim, stvarni sustavi podložni su brojnim mogućim greškama, poput padova procesa, particija mreže i izgubljenih, iskrivljenih ili dupliciranih poruka.

To postavlja pitanje - dokazano je da je nemoguće jamčiti da se u ograničenom vremenskom okviru na nepouzdanoj mreži postigne točan konsenzus.

U praksi, međutim, postoje algoritmi koji prilično brzo postižu konsenzus o nepouzdanoj mreži. Cassandra zapravo pruža lagane transakcije korištenjem Paxos algoritma za distribuirani konsenzus.

Distribuirano računarstvo

Distribuirano računanje ključno je za priljev obrade velikih podataka koji smo vidjeli posljednjih godina. To je tehnika razdvajanja golemog zadatka (npr. Ukupnih 100 milijardi zapisa), od kojeg niti jedno računalo nije u stanju izvršiti samo sebe, na mnogo manjih zadataka, od kojih se svaki može uklopiti u jedan robni stroj. Svoj ogromni zadatak podijelite na mnogo manjih, paralelno ih izvršite na mnogim strojevima, prikladno prikupite podatke i riješili ste svoj početni problem. Ovaj vam pristup ponovno omogućuje horizontalno skaliranje - kada imate veći zadatak, jednostavno uključite više čvorova u izračun.

Poznati Scale - Folding @ Home imao je 160.000 aktivnih strojeva u 2012. godini

Rani inovator u ovom prostoru bio je Google koji je zbog velike količine podataka morao izmisliti novu paradigmu za distribuirano računanje - MapReduce. O tome su objavili 2004. godine, a zajednica otvorenog koda kasnije je stvorila Apache Hadoop na temelju njega.

MapReduce

MapReduce se može jednostavno definirati kao dva koraka - mapiranje podataka i njihovo smanjivanje na nešto značajno.

Krenimo s primjerom opet:

Recimo da smo srednji i da smo svoje ogromne podatke pohranili u sekundarnu distribuiranu bazu podataka za potrebe skladištenja. Želimo prikupiti podatke koji predstavljaju broj pljeska koji se izdaju svakog dana tijekom travnja 2017. (prije godinu dana).

Ovaj se primjer drži što je moguće kraćim, jasnijim i jednostavnijim, ali zamislite da radimo s mnoštvom podataka (npr. Analizirajući milijarde pljeska). Nećemo očito pohraniti sve ove podatke na jednom stroju i nećemo sve to analizirati samo na jednom stroju. Također nećemo postavljati upite u produkcijsku bazu podataka, već u neku bazu podataka "skladišta" izrađenu posebno za offline poslove niskog prioriteta.

Svaki je posao mape zaseban čvor koji transformira što više podataka. Svaki posao prelazi sve podatke u danom čvoru za pohranu i preslikava ih u jednostavni skup datuma i broja jedan. Zatim se rade tri posrednička koraka (o kojima nitko ne govori) - izmjena, sortiranje i particija. U osnovi dalje uređuju podatke i brišu ih na odgovarajući posao smanjenja. Kako se bavimo velikim podacima, svaki posao Smanji razdvojimo za rad samo na jedan datum.

Ovo je dobra paradigma i iznenađujuće vam omogućuje da puno toga učinite - na primjer, možete povezati više poslova MapReduce.

Bolje tehnike

MapReduce je danas donekle naslijeđen i donosi neke probleme. Budući da djeluje u serijama (poslovima), pojavljuje se problem kada, ako vaš posao propadne - morate ponovno pokrenuti cijelu stvar. Dvosatni neuspjeh posla može usporiti čitav vaš cjevovod za obradu podataka, a to ne želite ni najmanje, posebno u vršnim satima.

Drugo je pitanje vrijeme u kojem čekate dok ne dobijete rezultate. U analitičkim sustavima u stvarnom vremenu (koji svi imaju velike podatke i na taj način koriste raspodijeljeno računanje) važno je da vaši najnoviji usitnjeni podaci budu što svježiji, a sigurno ne od prije nekoliko sati.

Kao takve, pojavile su se druge arhitekture koje se bave tim pitanjima. Naime, Lambda Architecture (mješavina šaržne obrade i strujne obrade) i Kappa Architecture (samo stream obrada). Ova dostignuća na terenu donijela su nove alate koji ih omogućavaju - Kafka Streams, Apache Spark, Apache Storm, Apache Samza.

Distribuirani datotečni sustavi

Distribuirani datotečni sustavi mogu se smatrati distribuiranim skladištima podataka. Oni su ista stvar kao i koncept - pohranjivanje i pristup velikoj količini podataka kroz skup strojeva koji se svi čine kao jedno. Oni obično idu ruku pod ruku s distribuiranim računarstvom.

Poznata skala - Yahoo je poznat po pokretanju HDFS-a na preko 42.000 čvorova za pohranu 600 Petabajta podataka, još 201.

Wikipedia definira razliku u tome što distribuirani datotečni sustavi omogućuju pristup datotekama koristeći se istim sučeljima i semantikom kao i lokalne datoteke, a ne putem prilagođenog API-ja poput Cassandra Query Language (CQL).

HDFS

Hadoop distribuirani datotečni sustav (HDFS) distribuirani je datotečni sustav koji se koristi za distribuirano računanje putem Hadoop okvira. Pohvali se širokim prihvaćanjem, koristi se za pohranu i umnožavanje velikih datoteka (veličine GB ili TB) na mnogim računalima.

Njegova se arhitektura uglavnom sastoji od NameNodes i DataNodes . NameNodes su odgovorni za čuvanje metapodataka o klasteru, poput toga koji čvor sadrži blokove datoteka. Djeluju kao koordinatori mreže otkrivajući gdje je najbolje pohraniti i replicirati datoteke, prateći zdravstveno stanje sustava. DataNodes jednostavno spremaju datoteke i izvršavaju naredbe poput repliciranja datoteke, pisanja nove i drugih.

Ne iznenađuje da se HDFS najbolje koristi s Hadoop-om za izračunavanje jer pruža svijest o podacima računalnim poslovima. Spomenuti poslovi zatim se pokreću na čvorovima za pohranu podataka. Ovo iskorištava lokalitet podataka - optimizira izračunavanja i smanjuje količinu prometa preko mreže.

IPFS

Interplanetarni datotečni sustav (IPFS) uzbudljiv je novi peer-to-peer protokol / mreža za distribuirani datotečni sustav. Koristeći Blockchain tehnologiju, može se pohvaliti potpuno decentraliziranom arhitekturom bez ijednog vlasnika ili točke kvara.

IPFS nudi sustav imenovanja (sličan DNS-u) koji se naziva IPNS i omogućuje korisnicima lak pristup informacijama. Datoteku pohranjuje putem povijesnih verzija, slično kao što to radi Git. To omogućuje pristup svim prethodnim stanjima datoteke.

Još uvijek je u teškom razvoju (v0.4 od trenutka pisanja), ali već je vidio projekte koji su zainteresirani za njegovu izgradnju (FileCoin).

Distribuirane poruke

Sustavi za razmjenu poruka pružaju centralno mjesto za pohranu i širenje poruka / događaja unutar vašeg cjelokupnog sustava. Omogućuju vam da razdvojite logiku aplikacije od izravnog razgovora s drugim sustavima.

Poznata skala - LinkedInov klaster Kafka obrađivao je 1 bilijun poruka dnevno s maksimumom od 4,5 milijuna poruka u sekundi.

Jednostavno rečeno, platforma za razmjenu poruka funkcionira na sljedeći način:

Poruka se emitira iz aplikacije koja je potencijalno može stvoriti (nazvana proizvođač ), ulazi u platformu i čita je potencijalno više aplikacija koje su za nju zainteresirane (nazvane potrošači ).

Ako određeni događaj trebate spremiti na nekoliko mjesta (npr. Stvaranje korisnika u bazu podataka, skladište, uslugu slanja e-pošte i sve drugo što možete smisliti), platforma za razmjenu poruka najčišći je način širenja te poruke.

Potrošači mogu ili izvući informacije iz posrednika (model izvlačenja) ili ih mogu izravno ugurati u potrošače (potisnuti model).

Postoji nekoliko popularnih vrhunskih platformi za razmjenu poruka:

RabbitMQ - posrednik poruka koji vam omogućuje preciznije upravljanje putanjama poruka putem pravila usmjeravanja i drugih lako podesivih postavki. Može se nazvati pametnim posrednikom, jer u sebi ima puno logike i čvrsto prati poruke koje kroz njega prolaze. Pruža postavke za AP i CP s CAP-a . Koristi push model za obavještavanje potrošača.

Kafka - Posrednik poruka (i sve out platforme) koji je nešto niži nivo, jer u njemu nije evidentirano koje su poruke pročitane i ne dopušta složenu logiku usmjeravanja. To mu pomaže postići nevjerojatne performanse. Po mom mišljenju, ovo je najveća perspektiva na ovom prostoru s aktivnim razvojem zajednice otvorenog koda i podrškom tima Confluent. Kafka je vjerojatno najrasprostranjenija od vrhunskih tehnoloških tvrtki. Napisao sam temeljit uvod u ovo, gdje detaljno opisujem svu njegovu dobrotu.

Apache ActiveMQ - Najstariji iz skupine, datiran iz 2004. godine. Koristi JMS API, što znači da je usmjeren prema Java EE aplikacijama. Prepisan je pod nazivom ActiveMQ Artemis, koji pruža izvanredne performanse u rangu s Kafkom.

Amazon SQS - usluga razmjene poruka koju pruža AWS. Omogućuje vam brzu integraciju s postojećim aplikacijama i uklanja potrebu za rukovanjem vlastitom infrastrukturom, što bi moglo biti velika korist, jer je sustave poput Kafke notorno nezgodno postaviti. Amazon nudi i dvije slične usluge - SNS i MQ, od kojih je potonja u osnovi ActiveMQ, ali kojom Amazon upravlja.

Distribuirane aplikacije

Ako umotate 5 Rails poslužitelja iza jednog uravnoteživača opterećenja koji su svi povezani s jednom bazom podataka, možete li to nazvati distribuiranom aplikacijom? Prisjetite se moje definicije od gore:

Distribuirani sustav je skupina računala koja rade zajedno kako bi se krajnjem korisniku prikazala kao jedno računalo. Ovi strojevi imaju zajedničko stanje, rade istovremeno i mogu neovisno otkazati bez utjecaja na vrijeme rada cijelog sustava.

Ako računate bazu podataka kao zajedničko stanje, mogli biste tvrditi da se to može klasificirati kao distribuirani sustav - ali pogriješili biste jer ste propustili dio " zajedničkog rada " u definiciji.

Sustav se distribuira samo ako čvorovi međusobno komuniciraju radi koordiniranja svojih radnji.

Stoga se nešto poput aplikacije koja izvodi svoj pozadinski kôd na peer-to-peer mreži može bolje klasificirati kao distribuiranu aplikaciju. Bez obzira na sve, ovo je sve nepotrebno razvrstavanje koje nema svrhu, ali ilustrira koliko smo nervozni u grupiranju stvari.

Poznata skala - BitTorrent roj od 193.000 čvorova za epizodu Igre prijestolja, travanj 2014.

Virtualni stroj Erlang

Erlang je funkcionalan jezik koji ima sjajnu semantiku za istodobnost, distribuciju i toleranciju kvarova. Virtualni stroj Erlang sam upravlja distribucijom aplikacije Erlang.

Njegov model djeluje tako što ima mnoge izolirane lagane procese, sve s mogućnošću međusobnog razgovora putem ugrađenog sustava prosljeđivanja poruka. To se naziva Model glumcaa Erlang OTP knjižnice mogu se smatrati raspodijeljenim okvirom glumca (po uzoru na Akka za JVM).

Model je ono što mu pomaže da postigne veliku podudarnost prilično jednostavno - procesi su raspoređeni po dostupnim jezgrama sustava koji ih pokreće. Budući da se to ne razlikuje od mrežne postavke (osim mogućnosti ispuštanja poruka), Erlangov VM može se povezati s drugim Erlangovim VM-ovima koji se izvode u istom podatkovnom centru ili čak na drugom kontinentu. Ovaj roj virtualnih strojeva pokreće jednu aplikaciju i rješava kvarove računala putem preuzimanja (planira se izvođenje drugog čvora).

Zapravo je dodan distribuirani sloj jezika kako bi se osigurala tolerancija kvarova. Softver pokrenut na jednom stroju uvijek je u opasnosti da taj jedan stroj umre i odvede vašu aplikaciju van mreže. Softver pokrenut na mnogim čvorovima omogućuje lakše rješavanje hardverskih kvarova, pod uvjetom da je aplikacija izgrađena s tim u vidu.

BitTorrent

BitTorrent je jedan od najčešće korištenih protokola za prijenos velikih datoteka putem weba putem bujica. Glavna ideja je olakšati prijenos datoteka između različitih vršnjaka u mreži bez potrebe za prolazom kroz glavni poslužitelj.

Pomoću BitTorrent klijenta povezujete se s više računala širom svijeta kako biste preuzeli datoteku. Kada otvorite .torrent datoteku, povežete se s takozvanim tracker-om , koji je stroj koji djeluje kao koordinator. Pomaže u otkrivanju vršnjaka, pokazujući vam čvorove u mreži koji imaju željenu datoteku.

Imate pojmove dvije vrste korisnika, pijavicu i sijačicu . Pijavica je korisnik koji preuzima datoteku, a sijačica je korisnik koji prenosi spomenutu datoteku.

Smiješna stvar peer-to-peer mreža je ta da se vi, kao obični korisnik, možete pridružiti mreži i doprinijeti joj.

BitTorrent i njegovi prethodnici (Gnutella, Napster) omogućuju vam dobrovoljno hostiranje datoteka i prijenos drugim korisnicima koji ih žele. Razlog zbog kojeg je BitTorrent toliko popularan je taj što je prvi takve vrste pružio poticaje za doprinos mreži. Freeriding , gdje bi korisnik samo preuzimao datoteke, bio je problem s prethodnim protokolima za dijeljenje datoteka.

BitTorrent je do neke mjere riješio freeriding tako što je sadilice prenijele više onima koji pružaju najbolje stope preuzimanja. Djeluje tako što vas potiče na prijenos prilikom preuzimanja datoteke. Nažalost, nakon što završite, ništa vas više ne tjera da ostanete aktivni u mreži. To uzrokuje nedostatak sijača u mreži koji imaju cijelu datoteku, a kako se protokol u velikoj mjeri oslanja na takve korisnike, rješenja poput privatnih tragača došla su do kraja. Privatni tragači zahtijevaju da budete član zajednice (često samo s pozivima) kako biste sudjelovali u distribuiranoj mreži.

Nakon napretka na terenu, izumljene su bujice bez tragova. Ovo je nadogradnja protokola BitTorrent koji se nije oslanjao na centralizirane programe za praćenje za prikupljanje metapodataka i pronalaženje vršnjaka, već je koristio nove algoritme. Jedan od takvih primjera je Kademlia (Mainline DHT), distribuirana hash tablica (DHT) koja vam omogućuje pronalaženje vršnjaka putem drugih vršnjaka. U stvari, svaki korisnik izvršava dužnosti tragača.

Distribuirane glavne knjige

Distribuirana knjiga može se smatrati nepromjenjivom bazom podataka koja se samo dodaje, koja se replicira, sinkronizira i dijeli na svim čvorovima u distribuiranoj mreži.

Poznata skala - mreža Ethereum imala je maksimum od 1,3 milijuna transakcija dnevno 4. siječnja 2018.

Oni koriste obrazac Izvori događaja, omogućujući vam obnovu stanja knjige u bilo kojem trenutku u njezinoj povijesti.

Blockchain

Blockchain je trenutna temeljna tehnologija koja se koristi za raspodijeljene knjige i zapravo je označila njihov početak. Ova najnovija i najveća inovacija u distribuiranom prostoru omogućila je stvaranje prvog istinski distribuiranog protokola plaćanja - Bitcoin.

Blockchain je raspodijeljena knjiga koja sadrži poredani popis svih transakcija koje su se ikad dogodile u njegovoj mreži. Transakcije se grupiraju i pohranjuju u blokove. Čitav blockchain u osnovi je povezani popis blokova (otuda i naziv) . Spomenuti blokovi računski su skupi za stvaranje i usko su povezani kriptografijom.

Jednostavno rečeno, svaki blok sadrži posebno raspršivanje (koje započinje s X količinom nula) sadržaja trenutnog bloka (u obliku stabla Merkle) plus raspršivanje prethodnog bloka. Za ovaj hash potrebno je proizvesti puno procesorske snage, jer je jedini način da se dođe do njega gruba sila.

Rudari su čvorovi koji pokušavaju izračunati hash (putem bruteforcea). Svi se rudari međusobno natječu tko će smisliti slučajni niz (nazvan nonce ) koji, kada se kombinira sa sadržajem, stvara gore spomenuti hash. Jednom kad netko pronađe točan nonce - emitira ga na cijelu mrežu. Spomenuti niz tada svaki čvor samostalno provjerava i prihvaća u svoj lanac.

To prelazi u sustav u kojem je apsurdno skupo mijenjati blockchain, a apsurdno je lako provjeriti da se u njemu ne radi.

Skupo je mijenjati sadržaj bloka jer bi to stvorilo drugačiji hash. Imajte na umu da hash svakog sljedećeg bloka ovisi o njemu. Ako biste promijenili transakciju u prvom bloku gornje slike - promijenili biste Merkleov korijen. To bi zauzvrat promijenilo hash bloka (najvjerojatnije bez potrebnih vodećih nula) - to bi promijenilo hash bloka # 2 i tako dalje i tako dalje. To znači da ćete morati grubo forsirati novi nonce za svaki blok nakon onog koji ste upravo izmijenili.

Mreža uvijek vjeruje i replicira najduži valjani lanac. Da biste prevarili sustav i na kraju stvorili duži lanac, trebat će vam više od 50% ukupne CPU snage koju koriste svi čvorovi.

Blockchain se može smatrati distribuiranim mehanizmom za hitni konsenzus . Konsenzus se ne postiže eksplicitno - ne postoje izbori niti fiksni trenutak kada se konsenzus dogodi. Umjesto toga, konsenzus je pojavni proizvod asinkrone interakcije tisuća nezavisnih čvorova, a sve nakon pravilima protokola.

Ova inovacija bez presedana nedavno je postala procvat u tehnološkom prostoru, a ljudi predviđaju da će označiti stvaranje Weba 3.0. To je zasigurno najuzbudljiviji prostor u svijetu softverskog inženjerstva, ispunjen izuzetno izazovnim i zanimljivim problemima koji čekaju svoje rješenje.

Bitcoin

Ono što je nedostajalo prethodnim distribuiranim protokolima plaćanja bio je način da se u stvarnom vremenu, na distribuirani način, praktički spriječi problem dvostruke potrošnje. Istraživanja su iznijela zanimljive prijedloge [1], ali Bitcoin je prvi primijenio praktično rješenje s jasnim prednostima u odnosu na druge.

Problem dvostruke potrošnje navodi da glumac (npr. Bob) ne može potrošiti svoj pojedinačni resurs na dva mjesta. Ako Bob ima 1 USD, ne bi ga mogao dati Alice i Zacku - to je samo jedno sredstvo, ne može se duplicirati. Ispostavilo se da je stvarno teško istinski postići ovo jamstvo u distribuiranom sustavu. Postoje neki zanimljivi pristupi ublažavanju koji prethode blockchainu, ali oni ne rješavaju u potpunosti problem na praktičan način.

Dvostruku potrošnju Bitcoin lako rješava jer se u lanac istovremeno dodaje samo jedan blok. Dvostruko trošenje nije moguće unutar jednog bloka, pa čak i ako se istovremeno stvore dva bloka - samo će jedan biti na eventualno najdužem lancu.

Bitcoin se oslanja na poteškoće u akumuliranju procesorske snage.

Iako u sustavu za glasanje napadač treba samo dodati čvorove u mrežu (što je lako, jer je besplatni pristup mreži cilj dizajna), u shemi temeljenoj na napajanju procesora napadač se suočava s fizičkim ograničenjima: dobivanje pristupa sve više i više moćan hardver.

To je također razlog zbog kojeg zlonamjerne skupine čvorova trebaju kontrolirati preko 50% računske snage mreže da bi zapravo mogle provesti bilo koji uspješan napad. Manje od toga, a ostatak mreže će brže stvoriti duži blockchain.

Ethereum

Ethereum se može smatrati programabilnom softverskom platformom koja se temelji na blockchainu. Ima vlastitu kriptovalutu (Ether) koja potiče postavljanje pametnih ugovora na svom blockchainu.

Pametni ugovori su dio koda pohranjen kao jedna transakcija u Ethereum blockchainu. Da biste pokrenuli kod, potrebno je samo izdati transakciju s pametnim ugovorom kao odredištem. To zauzvrat čini da čvorovi rudara izvršavaju kôd i sve njegove promjene. Kôd se izvršava unutar Ethereum Virtual Machine.

Solidnost , materinski programski jezik Ethereuma, ono je što se koristi za pisanje pametnih ugovora. To je turing-cjelovit programski jezik koji se izravno povezuje s Ethereum blockchainom, omogućujući vam da ispitujete stanje poput stanja ili drugih rezultata pametnih ugovora. Da biste spriječili beskonačne petlje, pokretanje koda zahtijeva određenu količinu Etera.

Kako se blockchain može protumačiti kao niz promjena stanja , puno Distribuiranih aplikacija (DApps) izgrađeno je na vrhu Ethereuma i sličnih platformi.

Daljnja upotreba raspodijeljenih knjiga

Dokaz o postojanju - Usluga za anonimno i sigurno pohranjivanje dokaza da je određeni digitalni dokument u određenom trenutku postojao. Korisno za osiguravanje integriteta, vlasništva i vremenskog označavanja dokumenata.

Decentralizirane autonomne organizacije (DAO) - organizacije koje koriste blockchain kao način postizanja konsenzusa o prijedlozima za poboljšanje organizacije. Primjeri su Dashov sustav upravljanja, projekt SmartCash

Decentralizirana provjera autentičnosti - pohranite svoj identitet na blockchainu, omogućujući vam svugdje upotrebu jedinstvene prijave (SSO). Sovrin, Građanski

I mnogo, puno više. Tehnologija distribuirane knjige zaista je otvorila beskrajne mogućnosti. Neki su najvjerojatnije izmišljeni dok razgovaramo!

Sažetak

U kratkom rasponu ovog članka uspjeli smo definirati što je distribuirani sustav, zašto biste ga koristili i malo prešli preko svake kategorije. Neke važne stvari koje treba zapamtiti su:

  • Distribuirani sustavi su složeni
  • Biraju se prema potrebi razmjera i cijene
  • S njima je teže raditi
  • Teorem CAP - Kompromis dosljednosti / dostupnosti
  • Imaju 6 kategorija - pohrane podataka, računarstvo, datotečni sustavi, sustavi za razmjenu poruka, glavne knjige, aplikacije

Da budem iskren, jedva smo dodirnuli površinu distribuiranih sustava. Nisam imao priliku temeljito se pozabaviti i objasniti ključne probleme poput konsenzusa, replikacijskih strategija, rasporeda događaja i vremena, tolerancije neuspjeha, emitiranja poruke putem mreže i drugih.

Oprez

Dopustite mi da vas upozorim na rastanak:

Morate se udaljiti od distribuiranih sustava koliko god možete. Složenost troškova koju sami sebi nanose nije vrijedna truda ako problem možete izbjeći rješavanjem na drugačiji način ili nekim drugim izvanmrežnim rješenjem.

[1]

Borba protiv dvostrukog trošenja korištenjem zadružnih P2P sustava, 25. - 27. lipnja 2007. - predloženo rješenje u kojem svaki 'novčić' može isteći te mu se dodijeli svjedok (validator) koji se troši.

Bitgold , prosinac 2005. - Pregled protokola na visokoj razini izuzetno sličan Bitcoinovom. Kaže se da je ovo preteča Bitcoina.

Daljnje čitanje distribuiranih sustava:

Dizajniranje aplikacija intenzivnih podataka, Martin Kleppmann - Sjajna knjiga koja obuhvaća sve u distribuiranim sustavima i još mnogo toga.

Cloud Computing Specijalizacija, Sveučilište Illinois, Coursera - Duga serija tečajeva (6) koji prelaze koncepte distribuiranog sustava, aplikacije

Jepsen - Blog koji objašnjava puno distribuiranih tehnologija (ElasticSearch, Redis, MongoDB, itd.)

Hvala što ste odvojili vrijeme za čitanje ovog dugog (~ 5600 riječi) članka!

Ako ste kojim slučajem pronašli ovu informativnu informaciju ili smatrate da vam ona daje vrijednost, pobrinite se da joj date onoliko pljeska za koje smatrate da zaslužuje i razmislite o tome da je podijelite s prijateljem koji bi mogao koristiti uvod u ovo predivno područje studija.

~ Stanislav Kozlovski

ažuriranje

Trenutno radim u Confluentu. Confluent je tvrtka za velike podatke koju su osnovali sami tvorci Apache Kafke! Neizmjerno sam zahvalan na prilici koju su mi pružili - trenutno radim na samoj Kafki, što je izvanredno! Mi u Confluentu pomažemo u oblikovanju cijelog ekosustava Kafka s otvorenim kodom, uključujući novu upravljanu ponudu oblaka Kafka kao usluga.

Zapošljavamo na puno radnih mjesta (posebno SRE / softverskih inženjera) u Europi i SAD-u! Ako ste zainteresirani za rad na samoj Kafki, tražite nove mogućnosti ili ste jednostavno znatiželjni - obavezno mi pošaljite poruku na Twitter i podijelit ću sve sjajne pogodnosti proizašle iz rada u tvrtki u zaljevu.