En grundlig introduktion till distribuerade system

Vad är ett distribuerat system och varför är det så komplicerat?

Med den ständigt växande tekniska expansionen i världen blir distribuerade system mer och mer utbredda. De är ett stort och komplext studieområde inom datavetenskap.

Den här artikeln syftar till att introducera dig till distribuerade system på ett grundläggande sätt, vilket visar dig en glimt av de olika kategorierna av sådana system utan att dyka djupt in i detaljerna.

Vad är ett distribuerat system?

Ett distribuerat system i sin enklaste definition är en grupp datorer som arbetar tillsammans för att visas som en enda dator för slutanvändaren.

Dessa maskiner har delat tillstånd, fungerar samtidigt och kan misslyckas oberoende utan att det påverkar hela systemets driftstid.

Jag föreslår att vi stegvis arbetar igenom ett exempel på att distribuera ett system så att du kan få en bättre känsla av allt:

Låt oss gå med en databas! Traditionella databaser lagras på filsystemet på en enda maskin, när du vill hämta / infoga information i den - du pratar direkt med den maskinen.

För att vi ska kunna distribuera detta databassystem måste vi ha den här databasen körd på flera datorer samtidigt. Användaren måste kunna prata med vilken maskin han väljer och bör inte kunna säga att han inte pratar med en enda maskin - om han sätter in en post i nod nr 1 måste nod # 3 kunna returnera den posten.

Varför distribuera ett system?

System distribueras alltid efter behov. Sanningen är att hantera distribuerade system är ett komplext ämne full av fallgropar och landminor. Det är en huvudvärk att distribuera, underhålla och felsöka distribuerade system, så varför alls gå dit?

Vad ett distribuerat system gör att du kan göra är att skala horisontellt . Om vi ​​går tillbaka till vårt tidigare exempel på den enda databasservern, skulle det enda sättet att hantera mer trafik vara att uppgradera hårdvaran som databasen körs på. Detta kallas skalning vertikalt .

Att skala vertikalt är bra och bra medan du kan, men efter en viss punkt kommer du att se att även den bästa hårdvaran inte räcker för tillräckligt med trafik, för att inte tala om opraktiskt att vara värd.

Att skala horisontellt betyder helt enkelt att man lägger till fler datorer i stället för att uppgradera maskinvaran för en enda.

Det är betydligt billigare än vertikal skalning efter en viss tröskel men det är inte dess huvudsakliga fall för preferens.

Vertikal skalning kan bara stöta på din prestanda upp till den senaste hårdvarans funktioner. Dessa funktioner visar sig vara otillräckliga för teknologiföretag med måttlig till stor arbetsbelastning.

Det bästa med horisontell skalning är att du inte har något tak på hur mycket du kan skala - när prestanda försämras lägger du helt enkelt till en annan maskin, upp till oändligt.

Enkel skalning är inte den enda fördelen du får från distribuerade system. Feltolerans och låg latens är också lika viktigt.

Feltolerans - ett kluster av tio maskiner över två datacenter är i sig mer feltolerant än en enda maskin. Även om ett datacenter tänds skulle din ansökan fortfarande fungera.

Låg latens - Tiden för ett nätverkspaket att resa världen är fysiskt begränsad av ljusets hastighet. Till exempel är kortast möjliga tid för en förfrågnings rundturstid (det vill säga fram och tillbaka) i en fiberoptisk kabel mellan New York till Sydney 160 ms. Distribuerade system gör att du kan ha en nod i båda städerna, så att trafiken kan träffa den nod som ligger närmast den.

För att ett distribuerat system ska fungera behöver du dock att programvaran som körs på dessa maskiner ska utformas specifikt för att köras på flera datorer samtidigt och hantera de problem som följer med den. Detta visar sig inte vara något enkelt.

Skalar vår databas

Tänk dig att vår webbapplikation blev vansinnigt populär. Tänk dig också att vår databas började få dubbelt så många frågor per sekund som den klarar. Din applikation skulle omedelbart börja försämras i prestanda och detta kommer att märkas av dina användare.

Låt oss arbeta tillsammans och göra vår databasskala för att möta våra höga krav.

I en typisk webbapplikation läser du normalt information mycket oftare än du infogar ny information eller ändrar gammal.

Det finns ett sätt att öka läsprestandan och det är den så kallade Primary-Replica Replication- strategin. Här skapar du två nya databasservrar som synkroniseras med den huvudsakliga. Fångsten är att du bara kan läsa från dessa nya instanser.

När du infogar eller ändrar information - pratar du med den primära databasen. Det informerar i sin tur om kopiorna av förändringen asynkront och de sparar den också.

Grattis, nu kan du utföra tre gånger så många läsfrågor! Är det inte bra?

Fälla

Fick dig! Vi förlorade omedelbart C i vår relationsdatabas ACID- garantier, som står för Consistency.

Du ser, det finns nu en möjlighet där vi infogar en ny post i databasen, omedelbart efteråt ger en läsfråga för den och får ingenting tillbaka, som om den inte fanns!

Att sprida den nya informationen från primär till replik sker inte direkt. Det finns faktiskt ett tidsfönster där du kan hämta inaktuell information. Om detta inte var fallet skulle din skrivprestanda drabbas, eftersom det måste vänta synkront på att data sprids.

Distribuerade system kommer med en handfull avvägningar. Denna specifika fråga är en fråga som du måste leva med om du vill skala tillräckligt.

Fortsätter att skala

Med hjälp av replikdatabasmetoden kan vi i viss utsträckning skala upp vår lästrafik horisontellt. Det är fantastiskt men vi har träffat en mur när det gäller vår skrivtrafik - det är fortfarande allt på en server!

Vi har inte många alternativ här. Vi behöver helt enkelt dela upp vår skrivtrafik i flera servrar eftersom en inte kan hantera den.

Ett sätt är att gå med en multi-primär replikeringsstrategi. Där, istället för repliker som du bara kan läsa från, har du flera primära noder som stöder läser och skriver. Tyvärr blir det snabbt komplicerat eftersom du nu har möjlighet att skapa konflikter (t.ex. infoga två poster med samma ID).

Låt oss gå med en annan teknik som kallas skärning(även kallad partitionering ).

Med sharding delar du upp din server i flera mindre servrar, kallade shards. Dessa skärvor har alla olika poster - du skapar en regel om vilken typ av poster som går in i vilken skärva. Det är mycket viktigt att skapa regeln så att data sprids på ett enhetligt sätt .

En möjlig metod för detta är att definiera intervall enligt viss information om en post (t.ex. användare med namn AD).

Denna skärningsnyckel bör väljas mycket noggrant, eftersom belastningen inte alltid är lika baserat på godtyckliga kolumner. (t.ex. fler människor har ett namn som börjar med C snarare än Z ). En enda skärva som tar emot fler förfrågningar än andra kallas en hot spot och måste undvikas. När den delats upp, blir omdelning av data oerhört dyrt och kan orsaka betydande stillestånd, vilket var fallet med FourSquares ökända 11 timmars avbrott.

För att hålla vårt exempel enkelt, anta att vår klient (Rails-appen) vet vilken databas som ska användas för varje post. Det är också värt att notera att det finns många strategier för skärning och detta är ett enkelt exempel för att illustrera konceptet.

Vi har vunnit en hel del just nu - vi kan öka vår skrivtrafik N gånger där N är antalet skärvor. Detta ger oss nästan ingen gräns - föreställ dig hur finkornigt vi kan få med denna partitionering.

Fälla

Allt inom mjukvaruteknik är mer eller mindre en avvägning och detta är inget undantag. Sharding är ingen enkel bedrift och undviks bäst tills det verkligen behövs.

Vi har nu gjort frågor med nycklarannat än den partitionerade nyckeln otroligt ineffektiv (de måste gå igenom alla skärvorna). SQL- JOINfrågor är ännu värre och komplexa blir praktiskt taget oanvändbara.

Decentraliserad vs Distribuerad

Innan vi går vidare vill jag skilja på de två termerna.

Trots att orden låter lika och kan slutsatsen att de betyder samma logiskt, har deras skillnad en betydande teknisk och politisk inverkan.

Decentraliserat distribueras fortfarandei teknisk mening, men hela decentraliserade system ägs inte av en aktör. Inget företag kan äga ett decentraliserat system, annars skulle det inte vara decentraliserat längre.

Det betyder att de flesta system vi kommer att gå igenom idag kan betraktas som distribuerade centraliserade system - och det är vad de är gjorda för att vara.

Om du tänker på det - är det svårare att skapa ett decentraliserat system för då måste du hantera fallet där några av deltagarna är skadliga. Detta är inte fallet med normalt distribuerade system, eftersom du vet att du äger alla noder.

Obs! Denna definition har diskuterats mycket och kan förväxlas med andra (peer-to-peer, federated). I tidig litteratur har det också definierats annorlunda. Oavsett vad jag gav dig som en definition är vad jag tycker är det mest använda nu när blockchain och kryptovalutor populariserade termen.

Distribuerade systemkategorier

Vi kommer nu att gå igenom ett par distribuerade systemkategorier och lista deras största allmänt kända produktionsanvändning. Tänk på att de flesta sådana siffror som visas är föråldrade och troligtvis är betydligt större när du läser detta.

Distribuerade databutiker

Distribuerade databutiker används mest och erkänns som distribuerade databaser. De flesta distribuerade databaser är NoSQL icke-relationsdatabaser, begränsade till nyckel-värde-semantik. De ger otrolig prestanda och skalbarhet till priset av konsistens eller tillgänglighet.

Känd skala - Apple är känt för att använda 75 000 Apache Cassandra-noder som lagrar över 10 petabyte data, redan 2015

Vi kan inte gå in i diskussioner om distribuerade datalagrar utan att först införa CAP Theorem.

CAP-satsen

Bevisat redan 2002, säger CAP-satsen att ett distribuerat datalager inte samtidigt kan vara konsekvent, tillgängligt och partitionstolerant.

Några snabba definitioner:

  • Konsistens - Vad du läser och skriver i följd är vad som förväntas (kom ihåg gotcha med databasreplikering för några stycken sedan?)
  • Tillgänglighet - hela systemet dör inte - varje icke-felande nod returnerar alltid ett svar.
  • Partition Tolerant - Systemet fortsätter att fungera och upprätthålla dess konsistens / tillgänglighetsgarantier trots nätverkspartitioner

I verkligheten måste partitionstolerans ges för alla distribuerade datalagrar. Som nämnts på många ställen, varav den här fantastiska artikeln, kan du inte ha konsistens och tillgänglighet utan partitionstolerans.

Tänk på det: om du har två noder som accepterar information och deras anslutning dör - hur kommer de båda att vara tillgängliga och samtidigt ge dig konsekvens? De har inget sätt att veta vad den andra noden gör och som sådan kan de antingen bli offline (otillgängliga) eller arbeta med gammal information (inkonsekvent) .

Till slut får du välja om du vill att ditt system ska vara starkt konsekvent eller mycket tillgängligt under en nätverkspartition .

Övning visar att de flesta applikationer värdesätter tillgängligheten mer. Du behöver inte nödvändigtvis alltid ha stark konsistens. Även då görs inte detta avvägning för att du behöver 100% tillgänglighetsgaranti, utan snarare för att nätverksfördröjning kan vara ett problem när du måste synkronisera maskiner för att uppnå stark konsistens. Dessa och fler faktorer gör att applikationer vanligtvis väljer lösningar som erbjuder hög tillgänglighet.

Sådana databaser överensstämmer med den svagaste konsistensmodellen - eventuell konsistens (stark kontra eventuell konsistensförklaring) . Denna modell garanterar att om inga nya uppdateringar görs för ett visst objekt, så småningom kommer alla åtkomster till det objektet tillbaka det senaste uppdaterade värdet.

Dessa system tillhandahåller BASE- egenskaper (i motsats till traditionella databassers ACID)

  • B asically A vailable - Systemet returnerar alltid ett svar
  • S oft staten - Systemet kan förändras över tid, även under tider av ingen ingång (på grund av eventuell konsistens)
  • E ventual konsistens - I avsaknad av input, kommer data att sprida sig till varje nod förr eller senare - och därmed bli konsekvent

Exempel på sådana tillgängliga distribuerade databaser - Cassandra, Riak, Voldemort

Naturligtvis finns det andra datalagrar som föredrar starkare konsistens - HBase, Couchbase, Redis, Zookeeper

CAP-satsen är värd flera artiklar på egen hand - vissa om hur du kan justera ett systems CAP-egenskaper beroende på hur klienten beter sig och andra om hur det inte förstås ordentligt.

Cassandra

Cassandra, som nämnts ovan, är en distribuerad No-SQL-databas som föredrar AP-egenskaperna utifrån CAP, och avgör med eventuell konsistens. Jag måste erkänna att detta kan vara lite vilseledande, eftersom Cassandra är mycket konfigurerbar - du kan få den att ge stark konsistens på bekostnad av tillgänglighet också, men det är inte dess vanliga användningsfall.

Cassandra använder konsekvent hashing för att avgöra vilka noder ur klustret som måste hantera data du skickar in. Du ställer in en replikeringsfaktor som i princip anger hur många noder du vill kopiera dina data.

När du läser läser du bara från dessa noder.

Cassandra är massivt skalbar och ger absurd hög genomströmning.

Även om detta diagram kan vara partiskt och det ser ut som att det jämför Cassandra med databaser som är inställda för att ge stark konsistens (annars kan jag inte se varför MongoDB skulle släppa prestanda när de uppgraderas från 4 till 8 noder), detta bör fortfarande visa vad som är korrekt inställt upp Cassandra kluster kan.

Oavsett, i de avvägda distribuerade systemen som möjliggör horisontell skalning och otroligt hög genomströmning, tillhandahåller Cassandra inte några grundläggande funktioner i ACID-databaser - nämligen transaktioner.

Konsensus

Databastransaktioner är svåra att implementera i distribuerade system eftersom de kräver att varje nod är överens om rätt åtgärd att vidta (avbryta eller begå). Detta kallas konsensus och det är ett grundläggande problem i distribuerade system.

Att nå den typ av avtal som behövs för problemet med "transaktionsåtagande" är enkelt om de deltagande processerna och nätverket är helt pålitliga. Men verkliga system är föremål för ett antal möjliga fel, såsom processkrascher, nätverkspartitionering och förlorade, förvrängda eller duplicerade meddelanden.

Detta utgör ett problem - det har visat sig omöjligt att garantera att ett korrekt samförstånd uppnås inom en begränsad tidsram i ett icke-tillförlitligt nätverk.

I praktiken finns det dock algoritmer som når enighet om ett icke-tillförlitligt nätverk ganska snabbt. Cassandra tillhandahåller faktiskt lätta transaktioner genom användning av Paxos-algoritmen för distribuerad konsensus.

Distribuerad databehandling

Distribuerad databehandling är nyckeln till inflödet av Big Data-bearbetning som vi har sett de senaste åren. Det är tekniken att dela upp en enorm uppgift (t.ex. sammanlagt 100 miljarder poster), av vilken ingen enskild dator praktiskt taget kan utföra på egen hand, i många mindre uppgifter, som var och en kan passa in i en enda maskin. Du delar upp din enorma uppgift i många mindre, låter dem utföra på många maskiner parallellt, sammanställer data på rätt sätt och du har löst ditt ursprungliga problem. Det här tillvägagångssättet gör det möjligt för dig att skala horisontellt - när du har en större uppgift, helt enkelt inkludera fler noder i beräkningen.

Känd skala - Folding @ Home hade 160 000 aktiva maskiner 2012

En tidig innovatör i detta utrymme var Google, som med nödvändighet av deras stora mängder data var tvungen att uppfinna ett nytt paradigm för distribuerad beräkning - MapReduce. De publicerade ett dokument om det 2004 och öppen källkod skapade senare Apache Hadoop baserat på det.

MapReduce

MapReduce kan enkelt definieras som två steg - kartlägga data och reducera den till något meningsfullt.

Låt oss ta itu med ett exempel igen:

Säg att vi är Medium och vi har lagrat vår enorma information i en sekundär distribuerad databas för lagerändamål. Vi vill hämta data som representerar antalet klappar som utfärdas varje dag under hela april 2017 (för ett år sedan).

Detta exempel hålls så kort, tydligt och enkelt som möjligt, men tänk dig att vi arbetar med massor av data (t.ex. analysera miljarder klappar). Vi kommer naturligtvis inte att lagra all denna information på en maskin och vi kommer inte att analysera allt detta med endast en maskin. Vi kommer inte heller att fråga efter produktionsdatabasen utan snarare någon ”lager” -databas byggd speciellt för offline-jobb med låg prioritet.

Varje kartjobb är en separat nod som omvandlar så mycket data som möjligt. Varje jobb spårar all data i den angivna lagringsnoden och kartlägger den till en enkel tupel av datumet och nummer ett. Därefter görs tre mellansteg (som ingen talar om) - Blanda, sortera och partitionera. De ordnar i grund och botten informationen och tar bort den till lämpligt reduceringsjobb. Eftersom vi har att göra med stora data har vi varje Reducera jobb separerat så att det bara fungerar på ett enda datum.

Detta är ett bra paradigm och gör det överraskande möjligt att göra mycket med det - du kan till exempel kedja flera MapReduce-jobb.

Bättre tekniker

MapReduce är något arv nuförtiden och ger vissa problem med det. Eftersom det fungerar i satser (jobb) uppstår ett problem där om ditt jobb misslyckas - du måste starta om hela saken. Ett 2-timmarsjobb som misslyckas kan verkligen sakta ner hela din databehandlingsrörledning och det vill du inte alls, särskilt under högtimmar.

En annan fråga är den tid du väntar tills du får resultat. I realtidsanalyssystem (som alla har stora data och därmed använder distribuerad databehandling) är det viktigt att dina senaste knäckta data är så färska som möjligt och absolut inte för några timmar sedan.

Som sådan har andra arkitekturer dykt upp som behandlar dessa frågor. Nämligen Lambda Architecture (blandning av batchbearbetning och streambearbetning) och Kappa Architecture (endast streambearbetning). Dessa framsteg inom fältet har gett nya verktyg som möjliggör dem - Kafka Streams, Apache Spark, Apache Storm, Apache Samza.

Distribuerade filsystem

Distribuerade filsystem kan betraktas som distribuerade datalagrar. De är samma sak som ett koncept - lagring och åtkomst till en stor mängd data över ett kluster av maskiner som alla visas som en. De går vanligtvis hand i hand med Distribuerad databehandling.

Känd skala - Yahoo är känt för att köra HDFS på över 42 000 noder för lagring av 600 petabyte data, långt tillbaka i 201

Wikipedia definierar skillnaden att distribuerade filsystem tillåter att filer kan nås med samma gränssnitt och semantik som lokala filer, inte genom ett anpassat API som Cassandra Query Language (CQL).

HDFS

Hadoop Distributed File System (HDFS) är det distribuerade filsystemet som används för distribuerad databehandling via Hadoop-ramverket. Med en omfattande användning används den för att lagra och replikera stora filer (GB eller TB i storlek) över många maskiner.

Dess arkitektur består huvudsakligen av NameNodes och DataNodes . Namnoder är ansvariga för att hålla metadata om klustret, som vilken nod som innehåller vilka filblock. De fungerar som koordinatorer för nätverket genom att ta reda på var det är bäst att lagra och replikera filer och spåra systemets hälsa. DataNodes lagrar bara filer och kör kommandon som att replikera en fil, skriva en ny och andra.

Inte överraskande, HDFS används bäst med Hadoop för beräkning eftersom det ger datakännedom till beräkningsjobben. Nämnda jobb körs sedan på noder som lagrar data. Detta utnyttjar datalokalitet - optimerar beräkningar och minskar trafiken över nätverket.

IPFS

Interplanetary File System (IPFS) är ett spännande nytt peer-to-peer-protokoll / nätverk för ett distribuerat filsystem. Genom att utnyttja Blockchain-tekniken har den en helt decentraliserad arkitektur utan en enda ägare eller felpunkt.

IPFS erbjuder ett namngivningssystem (liknande DNS) som heter IPNS och låter användare enkelt komma åt information. Den lagrar filen via historisk version, liknande hur Git gör. Detta möjliggör åtkomst till alla tidigare filers tillstånd.

Det genomgår fortfarande kraftig utveckling (v0.4 i skrivande stund) men har redan sett projekt som är intresserade av att bygga över det (FileCoin).

Distribuerade meddelanden

Meddelandesystem är en central plats för lagring och spridning av meddelanden / händelser i ditt totala system. De låter dig koppla från din applikationslogik från att direkt prata med dina andra system.

Känd skala - LinkedIn Kafka-kluster behandlade 1 biljoner meddelanden per dag med toppar på 4,5 miljoner meddelanden per sekund.

Enkelt uttryckt fungerar en meddelandeplattform på följande sätt:

Ett meddelande sänds från applikationen som potentiellt skapar det (kallas en producent ), går in i plattformen och läses av potentiellt flera applikationer som är intresserade av det (kallas konsument s).

Om du behöver spara en viss händelse på några ställen (t.ex. skapande av användare till databas, lager, e-posttjänst och vad du än kan komma på) är en meddelandeplattform det renaste sättet att sprida det meddelandet.

Konsumenter kan antingen hämta information från mäklarna (pull-modellen) eller låta mäklarna skicka information direkt till konsumenterna (push-modellen).

Det finns ett par populära toppmeddelandeplattformar:

RabbitMQ - Meddelandemäklare som ger dig mer detaljerad kontroll över meddelandebanor via dirigeringsregler och andra lätt konfigurerbara inställningar. Kan kallas en smart mäklare, eftersom den har mycket logik i sig och håller ordentligt koll på meddelanden som passerar genom den. Ger inställningar för både AP och CP från CAP . Använder en push-modell för att meddela konsumenterna.

Kafka - Meddelandemäklare (och hela plattformen) som är lite lägre, eftersom den inte håller reda på vilka meddelanden som har lästs och inte möjliggör komplex routinglogik. Detta hjälper det att uppnå fantastiska prestanda. Enligt min mening är detta det största utsikterna i detta utrymme med aktiv utveckling från open source-communityn och stöd från Confluent-teamet. Kafka har förmodligen den mest utbredda användningen från toppteknologiföretag. Jag skrev en grundlig introduktion till detta, där jag går i detalj om all dess godhet.

Apache ActiveMQ - Den äldsta i gruppen, från 2004. Använder JMS API, vilket innebär att den är inriktad på Java EE-applikationer. Det blev omskrivet som ActiveMQ Artemis, vilket ger enastående prestanda i nivå med Kafka.

Amazon SQS - En meddelandetjänst som tillhandahålls av AWS. Låter dig snabbt integrera den med befintliga applikationer och eliminerar behovet av att hantera din egen infrastruktur, vilket kan vara en stor fördel, eftersom system som Kafka är notoriskt knepiga att installera. Amazon erbjuder också två liknande tjänster - SNS och MQ, den senare är i grunden ActiveMQ men hanteras av Amazon.

Distribuerade applikationer

Om du rullar upp 5 Rails-servrar bakom en enda belastningsutjämnare som alla är anslutna till en databas, kan du kalla det en distribuerad applikation? Minns min definition uppifrån:

Ett distribuerat system är en grupp datorer som arbetar tillsammans för att visas som en enda dator för slutanvändaren. Dessa maskiner har delat tillstånd, fungerar samtidigt och kan misslyckas oberoende utan att det påverkar hela systemets driftstid.

Om du räknar databasen som ett delat tillstånd kan du argumentera för att detta kan klassificeras som ett distribuerat system - men du skulle ha fel, eftersom du har missat den " samarbetande " delen av definitionen.

Ett system distribueras endast om noderna kommunicerar med varandra för att samordna sina handlingar.

Därför kan något som ett program som kör sin back-end-kod i ett peer-to-peer-nätverk bättre klassificeras som en distribuerad applikation. Oavsett, allt detta är onödig klassificering som inte tjänar något syfte men illustrerar hur noga vi är med att gruppera saker.

Känd skala - BitTorrent-svärm med 193 000 noder för ett avsnitt av Game of Thrones, april 2014

Erlang virtuell maskin

Erlang är ett funktionellt språk som har stor semantik för samtidighet, distribution och feltolerans. Erlang Virtual Machine själv hanterar distributionen av en Erlang-applikation.

Dess modell fungerar genom att ha många isolerade lätta processer, alla med förmågan att prata med varandra via ett inbyggt system för meddelandeöverföring. Detta kallas Actor Modeloch Erlang OTP-bibliotek kan ses som ett ramverk för distribuerad aktör (i linje med Akka för JVM).

Modellen är det som hjälper det att uppnå stor samtidighet ganska enkelt - processerna är spridda över de tillgängliga kärnorna i systemet som kör dem. Eftersom detta inte går att skilja från en nätverksinställning (förutom möjligheten att släppa meddelanden) kan Erlangs virtuella dator ansluta till andra Erlang-virtuella datorer som körs i samma datacenter eller till och med på en annan kontinent. Denna svärm av virtuella maskiner kör en enda applikation och hanterar maskinfel via övertagande (en annan nod planeras att köras).

I själva verket har det distribuerade språket lagts till för att ge feltolerans. Programvara som körs på en enskild maskin riskerar alltid att den enskilda maskinen dör och tar din applikation offline. Programvara som körs på många noder möjliggör enklare hantering av maskinvarufel, förutsatt att applikationen byggdes med detta i åtanke.

BitTorrent

BitTorrent är ett av de mest använda protokollen för att överföra stora filer över nätet via torrents. Huvudidén är att underlätta filöverföring mellan olika kamrater i nätverket utan att behöva gå igenom en huvudserver.

Med hjälp av en BitTorrent-klient ansluter du till flera datorer över hela världen för att ladda ner en fil. När du öppnar en .torrent-fil ansluter du till en så kallad tracker , som är en maskin som fungerar som en samordnare. Det hjälper till med peer discovery och visar noder i nätverket som har filen du vill ha.

Du har föreställningar om två typer av användare, en leecher och en såmaskin . En leecher är användaren som laddar ner en fil och en såmaskin är den användare som laddar upp filen.

Det roliga med peer-to-peer-nätverk är att du som vanlig användare har möjlighet att gå med och bidra till nätverket.

BitTorrent och dess föregångare (Gnutella, Napster) låter dig frivilligt vara värd för filer och ladda upp till andra användare som vill ha dem. Anledningen till att BitTorrent är så populär är att det var den första i sitt slag som gav incitament för att bidra till nätverket. Freeriding , där en användare bara skulle ladda ner filer, var ett problem med tidigare fildelningsprotokoll.

BitTorrent löste freeriding i viss utsträckning genom att låta seeders ladda upp mer till de som ger de bästa nedladdningshastigheterna. Det fungerar genom att stimulera dig att ladda upp medan du laddar ner en fil. Tyvärr, efter att du är klar, får ingenting dig att vara aktiv i nätverket. Detta orsakar brist på seeders i nätverket som har hela filen och eftersom protokollet är starkt beroende av sådana användare, kom lösningar som privata spårare till verkan. Privata spårare kräver att du är medlem i ett community (ofta bara inbjudande) för att kunna delta i det distribuerade nätverket.

Efter framsteg inom fältet uppfanns spårlösa strömmar. Detta var en uppgradering till BitTorrent-protokollet som inte förlitade sig på centraliserade trackers för att samla in metadata och hitta kamrater utan istället använda nya algoritmer. En sådan instans är Kademlia (Mainline DHT), en distribuerad hash-tabell (DHT) som låter dig hitta kamrater genom andra kamrater. I själva verket utför varje användare en trackers uppgifter.

Distribuerade ledgers

En distribuerad huvudbok kan betraktas som en oföränderlig, endast tilläggsdatabas som replikeras, synkroniseras och delas över alla noder i det distribuerade nätverket.

Känd skala - Ethereum Network hade en topp på 1,3 miljoner transaktioner per dag den 4 januari 2018.

De utnyttjar Event Sourcing-mönstret, så att du kan återuppbygga huvudbokens tillstånd när som helst i dess historia.

Blockchain

Blockchain är den nuvarande underliggande tekniken som används för distribuerade huvudböcker och markerade faktiskt deras start. Den senaste och största innovationen inom distribuerat utrymme möjliggjorde skapandet av det första riktigt distribuerade betalningsprotokollet - Bitcoin.

Blockchain är en distribuerad huvudbok med en beställd lista över alla transaktioner som någonsin har skett i dess nätverk. Transaktioner grupperas och lagras i block. Hela blockchain är i huvudsak en länkad lista över block (därav namnet) . Nämnda block är beräkningsmässigt dyra att skapa och är tätt kopplade till varandra genom kryptografi.

Enkelt sagt innehåller varje block en speciell hash (som börjar med X-antal nollor) av det aktuella blockets innehåll (i form av ett Merkle Tree) plus föregående blockets hash. Denna hash kräver mycket CPU-kraft för att produceras eftersom det enda sättet att komma på det är genom brute-force.

Gruvarbetare är noder som försöker beräkna hash (via bruteforce). Gruvarbetarna tävlar alla med varandra för vem som kan komma med en slumpmässig sträng (kallad nonce ) som, när den kombineras med innehållet, producerar den ovannämnda hashen. När någon har hittat rätt nonce - sänder han det till hela nätverket. Nämnda sträng verifieras sedan av varje nod på egen hand och accepteras i deras kedja.

Detta översätts till ett system där det är absurt kostsamt att modifiera blockchain och absurt lätt att verifiera att det inte manipuleras med det.

Det är kostsamt att ändra innehållet i ett block eftersom det skulle ge en annan hash. Kom ihåg att varje efterföljande block hash är beroende av det. Om du skulle ändra en transaktion i det första blocket på bilden ovan - skulle du ändra Merkle Root. Detta skulle i sin tur förändra blockets hash (troligen utan de nödvändiga ledande nollorna) - det skulle ändra block # 2: s hash och så vidare och så vidare. Det betyder att du måste använda en ny nonce för varje block efter det du just har modifierat.

Nätverket litar alltid på och replikerar den längsta giltiga kedjan. För att fuska systemet och så småningom producera en längre kedja behöver du mer än 50% av den totala CPU-effekten som används av alla noder.

Blockchain kan ses som en distribuerad mekanism för framväxande konsensus . Konsensus uppnås inte uttryckligen - det finns inget val eller fast ögonblick när konsensus uppstår. Istället är konsensus en framväxande produkt av den asynkrona interaktionen mellan tusentals oberoende noder, allt efter protokollregler.

Denna oöverträffade innovation har nyligen blivit en högkonjunktur i teknikutrymmet med folk som förutsäger att det kommer att markera skapandet av Web 3.0. Det är definitivt det mest spännande rummet i programvaruteknikvärlden just nu, fyllt med extremt utmanande och intressanta problem som väntar på att lösas.

Bitcoin

Vad tidigare distribuerade betalningsprotokoll saknade var ett sätt att praktiskt taget förhindra problem med dubbla utgifter i realtid, på ett distribuerat sätt. Forskning har gett intressanta förslag [1] men Bitcoin var den första som implementerade en praktisk lösning med tydliga fördelar framför andra.

Det dubbla utgiftsproblemet säger att en skådespelare (t.ex. Bob) inte kan spendera sin enda resurs på två platser. Om Bob har $ 1 borde han inte kunna ge det till både Alice och Zack - det är bara en tillgång, det kan inte dupliceras. Det visar sig att det är riktigt svårt att verkligen uppnå denna garanti i ett distribuerat system. Det finns några intressanta begränsningsmetoder som föregick blockchain, men de löser inte helt problemet på ett praktiskt sätt.

Dubbelutgifter löses enkelt av Bitcoin, eftersom bara ett block läggs till kedjan åt gången. Dubbelutgifter är omöjliga inom ett enda block, därför att även om två block skapas samtidigt - kommer bara en att vara i den eventuella längsta kedjan.

Bitcoin förlitar sig på svårigheten att samla CPU-kraft.

I ett röstningssystem behöver en angripare bara lägga till noder i nätverket (vilket är enkelt, eftersom fri åtkomst till nätverket är ett designmål), men i ett CPU-kraftbaserat system står en angripare inför en fysisk begränsning: att få tillgång till mer och mer kraftfull hårdvara.

Detta är också anledningen till att skadliga grupper av noder behöver kontrollera över 50% av nätverkets beräkningskraft för att faktiskt kunna utföra ett framgångsrikt angrepp. Mindre än så, och resten av nätverket kommer att skapa en längre blockchain snabbare.

Ethereum

Ethereum kan ses som en programmerbar blockchain-baserad programvaruplattform. Den har sin egen kryptovaluta (Ether) som drivs utbyggnaden av smarta kontrakt på sin blockchain.

Smarta kontrakt är en kod som lagras som en enda transaktion i Ethereum blockchain. För att köra koden är allt du behöver göra att utfärda en transaktion med ett smart kontrakt som destination. Detta i sin tur gör att gruvnoderna kör koden och de förändringar som den medför. Koden körs inuti Ethereum Virtual Machine.

Soliditet , Ethereums ursprungliga programmeringsspråk, är det som används för att skriva smarta kontrakt. Det är ett turing-komplett programmeringsspråk som direkt gränssnitt med Ethereum blockchain, så att du kan fråga tillstånd som saldon eller andra smarta kontraktsresultat. För att förhindra oändliga slingor krävs att du kör koden en del Ether.

Eftersom blockkedjan kan tolkas som en serie tillståndsförändringar har många Distribuerade applikationer (DApps) byggts ovanpå Ethereum och liknande plattformar.

Ytterligare användning av distribuerade reskontrar

Bevis på existens - En tjänst som anonymt och säkert lagrar bevis på att ett visst digitalt dokument fanns vid någon tidpunkt. Användbar för att säkerställa dokumentintegritet, ägande och tidsstämpling.

Decentraliserade autonoma organisationer (DAO) - organisationer som använder blockchain som ett sätt att nå enighet om organisationens förbättringsförslag. Exempel är Dashs styrsystem, SmartCash-projektet

Decentraliserad autentisering - Spara din identitet i blockchain, så att du kan använda enkel inloggning (SSO) överallt. Sovrin, Civic

Och många, många fler. Den distribuerade huvudteknologin öppnade verkligen för oändliga möjligheter. Vissa uppfinns troligen när vi talar!

Sammanfattning

I den korta perioden av den här artikeln lyckades vi definiera vad ett distribuerat system är, varför du skulle använda ett och gå igenom varje kategori lite. Några viktiga saker att komma ihåg är:

  • Distribuerade system är komplexa
  • De väljs efter behov av skala och pris
  • De är svårare att arbeta med
  • CAP-sats - Avvägning mellan konsistens och tillgänglighet
  • De har sex kategorier - datalagrar, databehandling, filsystem, meddelandesystem, huvudböcker, applikationer

För att vara uppriktig har vi knappt rört ytan på distribuerade system. Jag hade inte chansen att grundligt ta itu med och förklara kärnproblem som konsensus, replikeringsstrategier, händelsebeställning och tid, feltolerans, sända ett meddelande över nätverket och andra.

Varning

Låt mig lämna dig med en avskedsförvarning:

Du måste avvika från distribuerade system så mycket du kan. Komplexiteten som de ådrar sig med sig själva är inte värt ansträngningen om du kan undvika problemet genom att antingen lösa det på ett annat sätt eller någon annan out-of-the-box-lösning.

[1]

Bekämpa dubbelutgifter med hjälp av samarbetsvilliga P2P-system, 25–27 juni 2007 - en föreslagen lösning där varje ”mynt” kan upphöra att gälla och tilldelas ett vittne (validerare) för det som spenderas.

Bitgold , december 2005 - En översikt på hög nivå av ett protokoll som är mycket likt Bitcoin. Det sägs att detta är föregångaren till Bitcoin.

Ytterligare distribuerade systemläsning:

Designing Data-Intensive Applications, Martin Kleppmann - En fantastisk bok som går igenom allt inom distribuerade system och mer.

Cloud Computing Specialization, University of Illinois, Coursera - En lång serie kurser (6) som går över distribuerade systemkoncept, applikationer

Jepsen - Blogg som förklarar många distribuerade tekniker (ElasticSearch, Redis, MongoDB, etc)

Tack för att du tog dig tid att läsa igenom den här långa artikeln (~ 5600 ord)!

Om du av någon slump hittade det här informativt eller trodde att det gav dig värde, var noga med att ge det så många klappar som du tror det förtjänar och överväga att dela med en vän som kan använda en introduktion till detta underbara studieområde.

~ Stanislav Kozlovski

Uppdatering

Jag arbetar för närvarande på Confluent. Confluent är ett Big Data-företag grundat av skaparna av Apache Kafka själva! Jag är oerhört tacksam för möjligheten de har gett mig - jag arbetar för närvarande på Kafka själv, vilket är fantastiskt! Vi på Confluent hjälper till att forma hela Kafka-ekosystemet med öppen källkod, inklusive ett nytt hanterat Kafka-as-a-service-molnutbud.

Vi anställer många positioner (särskilt SRE / Software Engineers) i Europa och USA! Om du är intresserad av att arbeta på Kafka själv, letar efter nya möjligheter eller helt enkelt nyfiken - var noga med att skicka ett meddelande till mig på Twitter så kommer jag att dela med dig av alla de bra förmånerna som kommer från att arbeta i ett företag inom området.