En grundig introduktion til distribuerede systemer

Hvad er et distribueret system, og hvorfor er det så kompliceret?

Med den stadigt voksende teknologiske udvidelse i verden bliver distribuerede systemer mere og mere udbredt. De er et stort og komplekst felt inden for datalogi.

Denne artikel har til formål at introducere dig til distribuerede systemer på en grundlæggende måde, der viser dig et glimt af de forskellige kategorier af sådanne systemer, mens du ikke dykker dybt ned i detaljerne.

Hvad er et distribueret system?

Et distribueret system i sin mest enkle definition er en gruppe computere, der arbejder sammen for at fremstå som en enkelt computer for slutbrugeren.

Disse maskiner har en delt tilstand, fungerer samtidigt og kan fejle uafhængigt uden at påvirke hele systemets oppetid.

Jeg foreslår, at vi trinvis arbejder igennem et eksempel på distribution af et system, så du kan få en bedre fornemmelse af det hele:

Lad os gå med en database! Traditionelle databaser gemmes på filsystemet på en enkelt maskine, hver gang du vil hente / indsætte oplysninger i den - du taler direkte til den maskine.

For at vi kan distribuere dette databasesystem, skal vi have denne database kørt på flere maskiner på samme tid. Brugeren skal være i stand til at tale med hvilken maskine han vælger og skal ikke være i stand til at fortælle at han ikke taler til en enkelt maskine - hvis han indsætter en post i node nr. 1, skal node 3 være i stand til at returnere den post.

Hvorfor distribuere et system?

Systemer distribueres altid efter behov. Sandheden i sagen er - styring af distribuerede systemer er et komplekst emne, der er fyldt med faldgruber og landminer. Det er hovedpine at implementere, vedligeholde og fejle distribuerede systemer, så hvorfor gå der overhovedet?

Hvad et distribueret system giver dig mulighed for er at skalere vandret . Når vi går tilbage til vores tidligere eksempel på den enkelte databaseserver, er den eneste måde at håndtere mere trafik på at opgradere den hardware, som databasen kører på. Dette kaldes skalering lodret .

Skalering lodret er alt sammen godt, mens du kan, men efter et bestemt tidspunkt vil du se, at selv den bedste hardware ikke er tilstrækkelig til nok trafik, for ikke at nævne upraktisk at være vært.

Skalering vandret betyder simpelthen at tilføje flere computere i stedet for at opgradere hardwaren til en enkelt.

Det er betydeligt billigere end lodret skalering efter en bestemt tærskel, men det er ikke dets primære tilfælde for præference.

Lodret skalering kan kun bumpe din ydeevne op til den nyeste hardwarefunktioner. Disse muligheder viser sig at være utilstrækkelige for teknologiske virksomheder med moderat til stor arbejdsbyrde.

Det bedste ved vandret skalering er, at du ikke har nogen grænse for, hvor meget du kan skalere - når ydeevnen forringes, skal du blot tilføje en anden maskine op til uendelig potentielt.

Nem skalering er ikke den eneste fordel, du får fra distribuerede systemer. Fejltolerance og lav latenstid er også lige så vigtige.

Fejltolerance - en klynge på ti maskiner på tværs af to datacentre er i sagens natur mere fejltolerant end en enkelt maskine. Selvom et datacenter brænder, fungerer din ansøgning stadig.

Lav latens - Tiden for en netværkspakke til at rejse verden er fysisk begrænset af lysets hastighed. For eksempel er den kortest mulige tid til en anmodnings rundturstid (dvs. gå frem og tilbage) i et fiberoptisk kabel mellem New York til Sydney 160 ms. Distribuerede systemer giver dig mulighed for at have en node i begge byer, så trafik kan ramme den node, der er tættest på den.

For at et distribueret system skal fungere, skal du dog have softwaren, der kører på disse maskiner, specielt designet til at køre på flere computere på samme tid og håndtere de problemer, der følger med det. Dette viser sig ikke at være nogen let bedrift.

Skalering af vores database

Forestil dig, at vores webapplikation blev sindssygt populær. Forestil dig også, at vores database begyndte at få dobbelt så mange forespørgsler pr. Sekund, som den kan håndtere. Din applikation vil straks begynde at falde i ydeevne, og dette bliver bemærket af dine brugere.

Lad os arbejde sammen og lave vores databaseskala for at imødekomme vores høje krav.

I en typisk webapplikation læser du normalt oplysninger meget oftere, end du indsætter nye oplysninger eller ændrer gamle.

Der er en måde at øge læseevnen på, og det er ved den såkaldte Primary-Replica Replication- strategi. Her opretter du to nye databaseservere, der synkroniseres med den vigtigste. Fangsten er, at du kun kan læse fra disse nye forekomster.

Hver gang du indsætter eller ændrer oplysninger - taler du med den primære database. Det informerer igen asynkront replikerne om ændringen, og de gemmer den også.

Tillykke, du kan nu udføre 3x så mange læseforespørgsler! Er det ikke fantastisk?

Faldgrube

Gotcha! Vi mistede straks C i vores relationsdatabases ACID- garantier, som står for konsistens.

Ser du, der findes nu en mulighed, hvor vi indsætter en ny post i databasen, straks derefter udsender en læseforespørgsel for den og får intet tilbage, som om den ikke eksisterede!

Formering af de nye oplysninger fra primær til replika sker ikke øjeblikkeligt. Der findes faktisk et tidsvindue, hvor du kan hente uaktuelle oplysninger. Hvis dette ikke var tilfældet, ville din skriveydelse lide, da den skulle vente synkront, indtil dataene blev formidlet.

Distribuerede systemer kommer med en håndfuld afvejninger. Dette særlige problem er et spørgsmål, du bliver nødt til at leve med, hvis du vil skalere tilstrækkeligt.

Fortsætter med at skalere

Ved hjælp af replika databasetilgang kan vi vandret skalere vores læste trafik til en vis grad. Det er fantastisk, men vi har ramt en mur med hensyn til vores skrivetrafik - det er stadig alt sammen på en server!

Vi har ikke mange muligheder her. Vi er simpelthen nødt til at opdele vores skrivetrafik i flere servere, da man ikke er i stand til at håndtere den.

En måde er at gå med en multi-primær replikeringsstrategi. Der, i stedet for replikaer, som du kun kan læse fra, har du flere primære noder, der understøtter læser og skriver. Desværre bliver dette kompliceret meget hurtigt, da du nu har evnen til at skabe konflikter (fx indsæt to poster med samme ID).

Lad os gå med en anden teknik kaldet sharding(også kaldet partitionering ).

Med sharding opdeler du din server i flere mindre servere, kaldet shards. Disse skår har alle forskellige poster - du opretter en regel for, hvilken slags poster der går i hvilken skår. Det er meget vigtigt at oprette reglen således, at dataene spredes på en ensartet måde .

En mulig tilgang til dette er at definere intervaller i henhold til nogle oplysninger om en post (f.eks. Brugere med navnet AD).

Denne sharding-nøgle skal vælges meget omhyggeligt, da belastningen ikke altid er ens baseret på vilkårlige kolonner. (f.eks. har flere et navn, der starter med C i stedet for Z ). En enkelt skår, der modtager flere anmodninger end andre, kaldes et hot spot og skal undgås. Når de er opdelt, bliver gendelegning af data utrolig dyre og kan forårsage betydelig nedetid, som det var tilfældet med FourSquares berygtede 11 timers afbrydelse.

For at holde vores eksempel simpelt skal du antage, at vores klient (Rails-appen) ved, hvilken database der skal bruges til hver post. Det er også værd at bemærke, at der er mange strategier for sharding, og dette er et simpelt eksempel for at illustrere konceptet.

Vi har vundet en hel del lige nu - vi kan øge vores skrivetrafik N gange, hvor N er antallet af skår. Dette giver os næsten ingen grænse - forestil dig, hvor fint kornet vi kan få med denne partitionering.

Faldgrube

Alt inden for Software Engineering er mere eller mindre en kompromis, og dette er ingen undtagelse. Sharding er ingen enkel bedrift og undgås bedst indtil det virkelig er nødvendigt.

Vi har nu foretaget forespørgsler ved hjælp af nøglerbortset fra den partitionerede nøgle utroligt ineffektiv (de skal gennem alle skårene). SQL- JOINforespørgsler er endnu værre, og komplekse bliver næsten ubrugelige.

Decentraliseret vs Distribueret

Inden vi går videre, vil jeg gerne skelne mellem de to termer.

Selvom ordene lyder ens og kan konkluderes at betyde det samme logisk, har deres forskel en betydelig teknologisk og politisk indvirkning.

Decentraliseret distribueres stadigi teknisk forstand, men hele decentrale systemer ejes ikke af en aktør. Ingen virksomheder kan eje et decentraliseret system, ellers ville det ikke længere være decentraliseret.

Dette betyder, at de fleste systemer, vi vil gennemgå i dag, kan betragtes som distribuerede centraliserede systemer - og det er, hvad de er lavet til at være.

Hvis du tænker over det - er det sværere at oprette et decentraliseret system, for så skal du håndtere sagen, hvor nogle af deltagerne er ondsindede. Dette er ikke tilfældet med normalt distribuerede systemer, da du ved, at du ejer alle knudepunkter.

Bemærk: Denne definition er blevet debatteret meget og kan forveksles med andre (peer-to-peer, federated). I den tidlige litteratur er det også blevet defineret anderledes. Uanset hvad jeg gav dig som definition er, hvad jeg føler, er den mest anvendte nu, da blockchain og kryptokurver populariserede udtrykket.

Distribuerede systemkategorier

Vi skal nu gennem et par distribuerede systemkategorier og liste deres største offentligt kendte produktionsanvendelse. Husk, at de fleste af disse viste tal er forældede og sandsynligvis er betydeligt større fra det tidspunkt, du læser dette.

Distribuerede databutikker

Distribuerede databutikker bruges mest og anerkendes som distribuerede databaser. De fleste distribuerede databaser er NoSQL ikke-relationelle databaser, begrænset til nøgleværdisemantik. De giver utrolig ydeevne og skalerbarhed på bekostning af konsistens eller tilgængelighed.

Kendt skala - Apple er kendt for at bruge 75.000 Apache Cassandra-noder, der lagrer over 10 petabyte data tilbage i 2015

Vi kan ikke gå ind i diskussioner af distribuerede datalagre uden først at indføre CAP-sætningen.

CAP-sætning

Bevist helt tilbage i 2002 siger CAP-sætningen, at et distribueret datalager ikke samtidig kan være konsistent, tilgængeligt og partitionstolerant.

Nogle hurtige definitioner:

  • Konsistens - Hvad du læser og skriver i rækkefølge er, hvad der forventes (husk gotcha med databasereplikering for et par afsnit siden?)
  • Tilgængelighed - hele systemet dør ikke - hver ikke-svigtende node returnerer altid et svar.
  • Partitionstolerant - Systemet fortsætter med at fungere og opretholde dets konsistens / tilgængelighedsgarantier på trods af netværkspartitioner

I virkeligheden skal partitionstolerance være givet for enhver distribueret datalager. Som nævnt mange steder, hvoraf den ene denne store artikel, kan du ikke have konsistens og tilgængelighed uden partitionstolerance.

Tænk over det: hvis du har to noder, der accepterer information, og deres forbindelse dør - hvordan vil de begge være tilgængelige og samtidig give dig konsistens? De har ingen måde at vide, hvad den anden knude gør, og som sådan kan de enten blive offline (utilgængelige) eller arbejde med uaktuelle oplysninger (inkonsekvente) .

I sidste ende er du tilbage til at vælge, om dit system skal være stærkt konsistent eller meget tilgængeligt under en netværkspartition .

Øvelse viser, at de fleste applikationer værdsætter tilgængeligheden mere. Du har ikke nødvendigvis altid brug for stærk konsistens. Selv da sker denne kompromis ikke nødvendigvis, fordi du har brug for 100% tilgængelighedsgaranti, men snarere fordi netværkslatens kan være et problem, når du skal synkronisere maskiner for at opnå stærk konsistens. Disse og flere faktorer gør, at applikationer typisk vælger løsninger, der tilbyder høj tilgængelighed.

Sådanne databaser afregner med den svageste konsistensmodel - eventuel konsistens (stærk vs eventuel konsistensforklaring) . Denne model garanterer, at hvis der ikke foretages nye opdateringer til en given vare, vil alle adganger til den vare i sidste ende returnere den senest opdaterede værdi.

Disse systemer leverer BASE- egenskaber (i modsætning til traditionelle databases ACID)

  • B asisk A tilgængelig - Systemet returnerer altid et svar
  • S ofte tilstand - Systemet kan ændre sig over tid, selv i tider uden input (på grund af eventuel konsistens)
  • E ventual konsistens - I mangel af input, vil data spredt sig til alle noder før eller senere - og bliver således konsekvent

Eksempler på sådanne tilgængelige distribuerede databaser - Cassandra, Riak, Voldemort

Selvfølgelig er der andre datalagre, der foretrækker stærkere konsistens - HBase, Couchbase, Redis, Zookeeper

CAP-sætningen er værd at have flere artikler alene - nogle om, hvordan du kan tilpasse et systems CAP-egenskaber afhængigt af, hvordan klienten opfører sig, og andre om, hvordan det ikke forstås ordentligt.

Cassandra

Cassandra, som nævnt ovenfor, er en distribueret No-SQL-database, der foretrækker AP-egenskaberne ud af CAP og afregner med en eventuel konsistens. Jeg må indrømme, at dette kan være lidt vildledende, da Cassandra er meget konfigurerbar - du kan få det til at give stærk konsistens på bekostning af tilgængelighed, men det er ikke dets almindelige brugssag.

Cassandra bruger ensartet hashing til at bestemme, hvilke noder ud af din klynge, der skal styre de data, du sender ind. Du indstiller en replikationsfaktor , der grundlæggende angiver, hvor mange noder du vil replikere dine data.

Når du læser, læser du kun fra disse noder.

Cassandra er masserbart skalerbar og giver absurd høj gennemstrømning.

Selvom dette diagram måske er forudindtaget, og det ser ud til, at det sammenligner Cassandra med databaser, der er indstillet til at give stærk konsistens (ellers kan jeg ikke se, hvorfor MongoDB ville tabe ydeevne, når de blev opgraderet fra 4 til 8 noder), skal dette stadig vise, hvad der er korrekt indstillet op Cassandra klynge er i stand til.

Uanset hvad, i de kompromiser med distribuerede systemer, der muliggør vandret skalering og utrolig høj kapacitet, giver Cassandra ikke nogle grundlæggende funktioner i ACID-databaser - nemlig transaktioner.

Konsensus

Databasetransaktioner er vanskelige at implementere i distribuerede systemer, da de kræver, at hver node er enige om den rigtige handling at tage (afbryde eller begå). Dette er kendt som konsensus, og det er et grundlæggende problem i distribuerede systemer.

At nå den type aftale, der er nødvendig for "transaktionsforpligtelsesproblemet", er ligetil, hvis de deltagende processer og netværket er helt pålidelige. Imidlertid er reelle systemer genstand for en række mulige fejl, såsom procesnedbrud, netværkspartitionering og mistede, forvrængede eller duplikerede meddelelser.

Dette udgør et problem - det har vist sig umuligt at garantere, at der opnås en korrekt konsensus inden for en afgrænset tidsramme på et ikke-pålideligt netværk.

I praksis er der dog algoritmer, der når konsensus om et ikke-pålideligt netværk temmelig hurtigt. Cassandra leverer faktisk lette transaktioner ved hjælp af Paxos-algoritmen til distribueret konsensus.

Distribueret databehandling

Distribueret databehandling er nøglen til tilstrømningen af ​​Big Data-behandling, vi har set i de seneste år. Det er teknikken til at opdele en enorm opgave (f.eks. Samlet 100 milliarder poster), hvoraf ingen enkelt computer praktisk taget er i stand til at udføre alene, i mange mindre opgaver, som hver kan passe ind i en enkelt varemaskine. Du deler din enorme opgave i mange mindre, får dem til at udføre på mange maskiner parallelt, samler dataene korrekt, og du har løst dit oprindelige problem. Denne tilgang giver dig igen mulighed for at skalere vandret - når du har en større opgave, skal du blot inkludere flere noder i beregningen.

Kendt skala - Folding @ Home havde 160.000 aktive maskiner i 2012

En tidlig innovator i dette rum var Google, som på grund af deres store datamængder måtte opfinde et nyt paradigme til distribueret beregning - MapReduce. De offentliggjorde et papir om det i 2004, og open source-samfundet oprettede senere Apache Hadoop baseret på det.

MapReduce

MapReduce kan simpelthen defineres som to trin - kortlægning af data og reduktion af dem til noget meningsfuldt.

Lad os tage fat på det med et eksempel igen:

Sig, at vi er Medium, og vi lagrede vores enorme oplysninger i en sekundær distribueret database til lagerformål. Vi ønsker at hente data, der repræsenterer antallet af klapper, der udstedes hver dag i hele april 2017 (for et år siden).

Dette eksempel holdes så kort, klart og simpelt som muligt, men forestil dig, at vi arbejder med masser af data (f.eks. Analyserer milliarder af klapper). Vi lagrer naturligvis ikke alle disse oplysninger på en maskine, og vi analyserer ikke alt dette kun med en maskine. Vi spørger heller ikke om produktionsdatabasen, men snarere om en "lager" -database, der er bygget specielt til offlineopgaver med lav prioritet.

Hvert kortjob er en separat knude, der omdanner så mange data som muligt. Hvert job krydser alle dataene i den givne lagerknude og kortlægger det til en simpel tuple af datoen og nummer et. Derefter udføres tre mellemliggende trin (som ingen taler om) - Bland, sorter og partition. De ordner grundlæggende yderligere dataene og sletter dem til det passende reduceringsjob. Da vi har at gøre med store data, har vi hver især reduceret job adskilt til kun at arbejde på en enkelt dato.

Dette er et godt paradigme og giver dig overraskende mulighed for at gøre meget med det - du kan f.eks. Kæde flere MapReduce-job.

Bedre teknikker

MapReduce er noget arv i dag og bringer nogle problemer med det. Fordi det fungerer i batches (job), opstår der et problem, hvis dit job mislykkes - du skal genstarte det hele. Et 2-timers jobfejl kan virkelig bremse hele din databehandlingsrørledning, og det ønsker du ikke i det mindste, især i spidsbelastningstider.

Et andet problem er det tidspunkt, du venter, indtil du modtager resultater. I realtidsanalysesystemer (som alle har store data og dermed bruger distribueret computing) er det vigtigt at have dine nyeste knuste data så ferske som muligt og bestemt ikke for et par timer siden.

Som sådan er der opstået andre arkitekturer, der løser disse problemer. Nemlig Lambda Architecture (blanding af batchbehandling og stream-behandling) og Kappa Architecture (kun stream-behandling). Disse fremskridt i marken har bragt nye værktøjer, der muliggør dem - Kafka Streams, Apache Spark, Apache Storm, Apache Samza.

Distribuerede filsystemer

Distribuerede filsystemer kan betragtes som distribuerede datalagre. De er de samme ting som et koncept - lagring og adgang til en stor mængde data på tværs af en klynge af maskiner, der alle vises som en. De går typisk hånd i hånd med Distribueret databehandling.

Kendt skala - Yahoo er kendt for at køre HDFS på over 42.000 noder til lagring af 600 petabyte data, helt tilbage i 201

Wikipedia definerer forskellen ved, at distribuerede filsystemer tillader adgang til filer ved hjælp af de samme grænseflader og semantik som lokale filer, ikke gennem en brugerdefineret API som Cassandra Query Language (CQL).

HDFS

Hadoop Distributed File System (HDFS) er det distribuerede filsystem, der bruges til distribueret computing via Hadoop-rammen. Med stor udbredelse er det brugt til at gemme og replikere store filer (GB eller TB i størrelse) på tværs af mange maskiner.

Dens arkitektur består hovedsageligt af NameNodes og DataNodes . NameNodes er ansvarlige for at opbevare metadata om klyngen, som hvilken node der indeholder hvilke filblokke. De fungerer som koordinatorer for netværket ved at finde ud af, hvor det er bedst at gemme og replikere filer, ved at spore systemets helbred. DataNodes gemmer simpelthen filer og udfører kommandoer som at replikere en fil, skrive en ny og andre.

Ikke overraskende bruges HDFS bedst med Hadoop til beregning, da det giver dataforståelse til beregningsjobberne. De nævnte job køres derefter på de noder, der lagrer dataene. Dette udnytter datalokalitet - optimerer beregninger og reducerer mængden af ​​trafik over netværket.

IPFS

Interplanetary File System (IPFS) er en spændende ny peer-to-peer-protokol / netværk til et distribueret filsystem. Ved at udnytte Blockchain-teknologien kan den prale af en helt decentral arkitektur uden en enkelt ejer eller et fejlpunkt.

IPFS tilbyder et navngivningssystem (svarende til DNS) kaldet IPNS og giver brugerne let adgang til information. Den gemmer filen via historisk version, svarende til hvordan Git gør. Dette giver adgang til alle filens tidligere tilstande.

Det er stadig under hård udvikling (v0.4 i skrivende stund), men har allerede set projekter, der er interesseret i at bygge over det (FileCoin).

Distribueret besked

Meddelelsessystemer giver et centralt sted for lagring og formidling af meddelelser / begivenheder inde i dit samlede system. De giver dig mulighed for at afkoble din applikationslogik fra direkte at tale med dine andre systemer.

Kendt skala - LinkedIn's Kafka-klynge behandlede 1 billioner beskeder om dagen med toppe på 4,5 millioner meddelelser i sekundet.

Kort sagt, en messaging-platform fungerer på følgende måde:

En meddelelse udsendes fra applikationen, som potentielt opretter den (kaldet en producent ), går ind på platformen og læses af potentielt flere applikationer, der er interesserede i den (kaldet forbruger ).

Hvis du har brug for at gemme en bestemt begivenhed et par steder (f.eks. Oprettelse af brugere i database, lager, e-mail-afsendelsestjeneste og hvad du ellers kan komme med), er en meddelelsesplatform den reneste måde at sprede denne besked på.

Forbrugerne kan enten trække information ud af mæglerne (pull-modellen) eller få mæglerne til at skubbe information direkte ind i forbrugerne (push-modellen).

Der er et par populære førsteklasses messaging-platforme:

RabbitMQ - Meddelelsesmægler, der giver dig mere detaljeret kontrol over beskedbaner via routingregler og andre let konfigurerbare indstillinger. Kan kaldes en smart mægler, da den har meget logik og holder nøje styr på meddelelser, der passerer igennem den. Indeholder indstillinger for både AP og CP fra CAP . Bruger en push-model til at underrette forbrugerne.

Kafka - Meddelelsesmægler (og hele platformen), som er lidt lavere niveau, da den ikke holder styr på, hvilke meddelelser der er blevet læst og ikke tillader kompleks routinglogik. Dette hjælper det med at opnå fantastiske præstationer. Efter min mening er dette det største udsyn i dette rum med aktiv udvikling fra open source-samfundet og støtte fra Confluent-teamet. Kafka har uden tvivl den mest udbredte brug fra topteknologiske virksomheder. Jeg skrev en grundig introduktion til dette, hvor jeg går i detaljer om al dets godhed.

Apache ActiveMQ - Den ældste af gruppen, der stammer fra 2004. Bruger JMS API, hvilket betyder, at den er rettet mod Java EE-applikationer. Det blev omskrevet som ActiveMQ Artemis, som giver enestående præstationer på niveau med Kafka.

Amazon SQS - En messaging-tjeneste leveret af AWS. Giver dig mulighed for hurtigt at integrere det med eksisterende applikationer og eliminere behovet for at håndtere din egen infrastruktur, hvilket kan være en stor fordel, da systemer som Kafka er notorisk vanskelige at opsætte. Amazon tilbyder også to lignende tjenester - SNS og MQ, hvor sidstnævnte grundlæggende er ActiveMQ men administreret af Amazon.

Distribuerede applikationer

Hvis du ruller op 5 Rails-servere bag en enkelt belastningsbalancer, der alle er forbundet til en database, kan du så kalde det et distribueret program? Husk min definition ovenfra:

Et distribueret system er en gruppe computere, der arbejder sammen for at fremstå som en enkelt computer for slutbrugeren. Disse maskiner har en delt tilstand, fungerer samtidigt og kan fejle uafhængigt uden at påvirke hele systemets oppetid.

Hvis du tæller databasen som en delt tilstand, kan du argumentere for, at dette kan klassificeres som et distribueret system - men du ville være forkert, da du har gået glip af den " arbejder sammen " del af definitionen.

Et system distribueres kun, hvis noderne kommunikerer med hinanden for at koordinere deres handlinger.

Derfor kan noget som et program, der kører sin back-end-kode på et peer-to-peer-netværk, bedre klassificeres som et distribueret program. Uanset hvad er dette alt unødvendigt klassificering, der ikke tjener noget formål, men illustrerer, hvor kræsen vi er ved at gruppere ting sammen.

Kendt skala - BitTorrent sværm med 193.000 noder til en episode af Game of Thrones, april 2014

Erlang virtuel maskine

Erlang er et funktionelt sprog, der har stor semantik for samtidighed, distribution og fejltolerance. Erlang Virtual Machine håndterer selv distributionen af ​​en Erlang-applikation.

Dens model fungerer ved at have mange isolerede lette processer, alle med evnen til at tale med hinanden via et indbygget system til meddelelsesoverførsel. Dette kaldes Actor Modelog Erlang OTP-bibliotekerne kan betragtes som en distribueret aktørramme (i retning af Akka for JVM).

Modellen er, hvad der hjælper det med at opnå stor samtidighed ganske enkelt - processerne er spredt over de tilgængelige kerner i systemet, der kører dem. Da dette ikke skelnes fra en netværksindstilling (bortset fra muligheden for at droppe beskeder), kan Erlangs VM oprette forbindelse til andre Erlang VM'er, der kører i det samme datacenter eller endda på et andet kontinent. Denne sværm af virtuelle maskiner kører en enkelt applikation og håndterer maskinfejl via overtagelse (en anden node bliver planlagt til at køre).

Faktisk blev det distribuerede sproglag tilføjet for at give fejltolerance. Software, der kører på en enkelt maskine, er altid i fare for at få den eneste maskine til at dø og tage din applikation offline. Software, der kører på mange noder, giver lettere håndtering af hardwarefejl, forudsat at applikationen blev bygget med det i tankerne.

BitTorrent

BitTorrent er en af ​​de mest anvendte protokoller til overførsel af store filer over internettet via torrents. Hovedideen er at lette filoverførsel mellem forskellige jævnaldrende i netværket uden at skulle gå gennem en hovedserver.

Ved hjælp af en BitTorrent-klient opretter du forbindelse til flere computere over hele verden for at downloade en fil. Når du åbner en .torrent-fil, opretter du forbindelse til en såkaldt tracker , som er en maskine, der fungerer som en koordinator. Det hjælper med peer discovery og viser dig de noder i netværket, der har den ønskede fil.

Du har forestillingerne om to typer brugere, en leecher og en såmaskine . En leecher er den bruger, der downloader en fil, og en såmaskine er den bruger, der uploader den nævnte fil.

Det sjove ved peer-to-peer-netværk er, at du som almindelig bruger har evnen til at deltage og bidrage til netværket.

BitTorrent og dets forløbere (Gnutella, Napster) giver dig mulighed for frivilligt at være vært for filer og uploade til andre brugere, der ønsker dem. Årsagen til, at BitTorrent er så populær, er at det var den første af sin art, der gav incitamenter til at bidrage til netværket. Freeriding , hvor en bruger kun ville downloade filer, var et problem med de tidligere fildelingsprotokoller.

BitTorrent løste freeriding i et omfang ved at lade seeders uploade mere til dem, der giver de bedste downloadhastigheder. Det virker ved at tilskynde dig til at uploade, mens du downloader en fil. Desværre, efter at du er færdig, får intet dig til at forblive aktiv i netværket. Dette medfører mangel på seedere i netværket, der har den fulde fil, og da protokollen er stærkt afhængig af sådanne brugere, kom løsninger som private trackere til at virke. Private trackere kræver, at du er medlem af et community (ofte kun invitation) for at kunne deltage i det distribuerede netværk.

Efter fremskridt i marken blev sporløse torrents opfundet. Dette var en opgradering til BitTorrent-protokollen, der ikke stod på centraliserede trackere til at samle metadata og finde jævnaldrende, men i stedet bruge nye algoritmer. En sådan forekomst er Kademlia (Mainline DHT), en distribueret hash-tabel (DHT), der giver dig mulighed for at finde jævnaldrende gennem andre jævnaldrende. I virkeligheden udfører hver bruger en trackers opgaver.

Distribuerede ledgers

En distribueret hovedbog kan betragtes som en uforanderlig database, der kun er tilføjet, der replikeres, synkroniseres og deles på tværs af alle noder i det distribuerede netværk.

Kendt skala - Ethereum Network havde et højdepunkt på 1,3 millioner transaktioner om dagen den 4. januar 2018.

De udnytter begivenhedssourcingmønsteret, så du kan genopbygge hovedstatens tilstand når som helst i dens historie.

Blockchain

Blockchain er den nuværende underliggende teknologi, der bruges til distribuerede hovedbøger og markerede faktisk deres start. Denne seneste og største innovation i det distribuerede rum muliggjorde oprettelsen af ​​den første nogensinde virkelig distribuerede betalingsprotokol - Bitcoin.

Blockchain er en distribueret hovedbog med en ordnet liste over alle transaktioner, der nogensinde har fundet sted i dets netværk. Transaktioner grupperes og opbevares i blokke. Hele blockchain er i det væsentlige en sammenkædet liste over blokke (deraf navnet) . Nævnte blokke er beregningsmæssigt dyre at oprette og er tæt knyttet til hinanden gennem kryptografi.

Simpelthen sagt, hver blok indeholder en speciel hash (der starter med X-antal nuller) af den aktuelle blocks indhold (i form af et Merkle Tree) plus den forrige blocks hash. Denne hash kræver, at der produceres meget CPU-strøm, fordi den eneste måde at komme op med den er ved hjælp af brute-force.

Minearbejdere er de knudepunkter, der prøver at beregne hashen (via bruteforce). Minearbejderne konkurrerer alle med hinanden for, hvem der kan komme med en tilfældig streng (kaldet en nonce ), der, når den kombineres med indholdet, producerer den førnævnte hash. Når nogen finder den rigtige nonce - sender han den til hele netværket. Nævnte streng bekræftes derefter af hver knude alene og accepteres i deres kæde.

Dette oversættes til et system, hvor det er absurd dyrt at ændre blockchain og absurd let at kontrollere, at det ikke er manipuleret med.

Det er dyrt at ændre en blok indhold, fordi det ville producere en anden hash. Husk, at hver efterfølgende blocks hash er afhængig af det. Hvis du skulle ændre en transaktion i den første blok på billedet ovenfor - ville du ændre Merkle-roden. Dette ville igen ændre blokens hash (sandsynligvis uden de nødvendige ledende nuller) - det ville ændre blok # 2's hash og så videre og så videre. Dette betyder, at du bliver nødt til at brute-force en ny nonce for hver blok efter den, du lige har ændret.

Netværket stoler altid på og replikerer den længste gyldige kæde. For at snyde systemet og til sidst producere en længere kæde, har du brug for mere end 50% af den samlede CPU-effekt, der bruges af alle knudepunkter.

Blockchain kan betragtes som en distribueret mekanisme til fremvoksende konsensus . Konsensus opnås ikke eksplicit - der er intet valg eller fast øjeblik, hvor konsensus opstår. I stedet er konsensus et fremvoksende produkt af den asynkrone interaktion mellem tusindvis af uafhængige noder, alt sammen efter protokolregler.

Denne hidtil usete innovation er for nylig blevet et boom i det tekniske rum med folk, der forudsiger, at det vil markere oprettelsen af ​​Web 3.0. Det er bestemt det mest spændende rum i softwareteknologiverdenen lige nu, fyldt med ekstremt udfordrende og interessante problemer, der venter på at blive løst.

Bitcoin

Hvad tidligere distribuerede betalingsprotokoller manglede, var en måde at praktisk talt forhindre dobbeltforbrugsproblemet i realtid på en distribueret måde. Forskning har produceret interessante forslag [1], men Bitcoin var den første til at implementere en praktisk løsning med klare fordele i forhold til andre.

Det dobbelte udgiftsproblem angiver, at en skuespiller (f.eks. Bob) ikke kan bruge sin eneste ressource to steder. Hvis Bob har $ 1, skal han ikke være i stand til at give det til både Alice og Zack - det er kun et aktiv, det kan ikke duplikeres. Det viser sig, at det er virkelig svært at virkelig opnå denne garanti i et distribueret system. Der er nogle interessante afbødningsmetoder forud for blockchain, men de løser ikke problemet fuldstændigt på en praktisk måde.

Dobbeltforbrug løses let af Bitcoin, da kun en blok føjes til kæden ad gangen. Dobbeltforbrug er umuligt inden for en enkelt blok, derfor selvom der oprettes to blokke på samme tid - vil kun en være i den eventuelt længste kæde.

Bitcoin er afhængig af vanskeligheden ved at akkumulere CPU-strøm.

Mens et angriber i et stemmesystem kun behøver at tilføje noder til netværket (hvilket er let, da fri adgang til netværket er et designmål), står en angriber i en CPU-strømbaseret ordning over for en fysisk begrænsning: at få adgang til mere og mere kraftfuld hardware.

Dette er også grunden til, at ondsindede grupper af noder har brug for at kontrollere over 50% af netværkets beregningskraft for faktisk at udføre et vellykket angreb. Mindre end det, og resten af ​​netværket vil skabe en længere blockchain hurtigere.

Ethereum

Ethereum kan betragtes som en programmerbar blockchain-baseret softwareplatform. Det har sin egen kryptokurrency (Ether), der fremmer implementeringen af smarte kontrakter på sin blockchain.

Smarte kontrakter er et stykke kode, der er gemt som en enkelt transaktion i Ethereum-blockchain. For at køre koden er alt hvad du skal gøre, at udstede en transaktion med en smart kontrakt som destination. Dette får minearbejderne til at udføre koden og de ændringer, den medfører. Koden udføres inde i Ethereum Virtual Machine.

Solidity , Ethereums oprindelige programmeringssprog, er det, der bruges til at skrive smarte kontrakter. Det er et turing-komplet programmeringssprog, der direkte grænseflader med Ethereum blockchain, så du kan forespørge om status som saldi eller andre smarte kontraktresultater. For at forhindre uendelige sløjfer kræver kørsel af koden en vis mængde Ether.

Da blockchain kan fortolkes som en række tilstandsændringer , er der blevet bygget mange Distribuerede applikationer (DApps) oven på Ethereum og lignende platforme.

Yderligere anvendelser af distribuerede hovedbøger

Bevis for eksistens - En tjeneste, der anonymt og sikkert gemmer bevis for, at et bestemt digitalt dokument eksisterede på et eller andet tidspunkt. Nyttig til at sikre dokumentintegritet, ejerskab og tidsstempling.

Decentraliserede autonome organisationer (DAO) - organisationer, der bruger blockchain som et middel til at nå konsensus om organisationens forbedringsforslag. Eksempler er Dashs ledelsessystem, SmartCash-projektet

Decentral godkendelse - Gem din identitet i blockchain, så du kan bruge single sign-on (SSO) overalt. Sovrin, Civic

Og mange, mange flere. Den distribuerede hovedbogsteknologi åbnede virkelig uendelige muligheder. Nogle opfindes sandsynligvis, mens vi taler!

Resumé

I den korte periode af denne artikel lykkedes det os at definere, hvad et distribueret system er, hvorfor du bruger et og går lidt over hver kategori. Nogle vigtige ting at huske er:

  • Distribuerede systemer er komplekse
  • De vælges efter nødvendighed af størrelse og pris
  • De er sværere at arbejde med
  • CAP-sætning - afvejning af konsistens / tilgængelighed
  • De har 6 kategorier - datalagre, computing, filsystemer, messaging-systemer, ledgers, applikationer

For at være ærlig har vi næppe berørt overfladen på distribuerede systemer. Jeg havde ikke chancen for grundigt at tackle og forklare kerneproblemer som konsensus, replikeringsstrategier, begivenhedsbestilling og tid, fiaskontolerance, udsendelse af en besked over hele netværket og andre.

Advarsel

Lad mig efterlade dig med en afskedsadvarsel:

Du skal afvige fra distribuerede systemer så meget som muligt. Kompleksiteten overhead, de pådrager sig selv, er ikke en anstrengelse værd, hvis du kan undgå problemet ved enten at løse det på en anden måde eller en anden løsning uden for boksen.

[1]

Bekæmpelse af dobbeltforbrug ved hjælp af samarbejdsvillige P2P-systemer, 25. - 27. juni 2007 - en foreslået løsning, hvor hver 'mønt' kan udløbe og tildeles et vidne (validator), som den bruges.

Bitgold , december 2005 - En oversigt på højt niveau af en protokol, der er meget lig Bitcoins. Det siges, at dette er forløberen for Bitcoin.

Yderligere distribution af distribuerede systemer:

Design af dataintensive applikationer, Martin Kleppmann - En fantastisk bog, der går over alt inden for distribuerede systemer og mere.

Cloud Computing Specialization, University of Illinois, Coursera - En lang række kurser (6), der går over distribuerede systemkoncepter, applikationer

Jepsen - Blog, der forklarer mange distribuerede teknologier (ElasticSearch, Redis, MongoDB osv.)

Tak, fordi du tog dig tid til at læse denne lange artikel (~ 5600 ord) igennem!

Hvis du med en chance fandt denne informative eller troede, at den gav dig værdi, skal du sørge for at give den så mange klapper, som du mener, den fortjener, og overveje at dele med en ven, der kunne bruge en introduktion til dette vidunderlige felt.

~ Stanislav Kozlovski

Opdatering

Jeg arbejder i øjeblikket hos Confluent. Confluent er et Big Data-firma grundlagt af skaberne af Apache Kafka selv! Jeg er utrolig taknemmelig for den mulighed, de har givet mig - jeg arbejder i øjeblikket på selve Kafka, hvilket er fantastisk! Vi hos Confluent hjælper med at forme hele open source Kafka-økosystemet, inklusive et nyt administreret Kafka-as-a-service-skyudbud.

Vi ansætter mange stillinger (især SRE / Software Engineers) i Europa og USA! Hvis du er interesseret i at arbejde på Kafka selv, på udkig efter nye muligheder eller bare nysgerrig - sørg for at sende en besked til mig på Twitter, så vil jeg dele alle de store frynsegoder, der kommer fra at arbejde i et firma i et område.