Obs: Detta inlägg är föråldrad. Du hittar den senaste versionen här.
detta inlägg är föråldrad. Den uppdaterade versionen hittar du här. Jag lämnar avsiktligt den här artikeln här så jag stör inte andra webbplatser som länkar tillbaka till mig.
för flera år sedan var det enkelt att bygga prestanda i ett mjukvarusystem – du ökade antingen dina hårdvaruresurser (skala upp) eller ändrade din applikation för att köra mer effektivt (prestandajustering). Idag finns det ett tredje alternativ: horisontell skalning (skala ut).
horisontell skalning av mjukvarusystem har blivit nödvändig de senaste åren på grund av den globala karaktären av databehandling och de ständigt ökande prestandakraven på applikationer. I många fall är det inte längre acceptabelt att köra en enda server med en enda databas i ett enda datacenter intill företagets huvudkontor. Vi behöver verkligen distribuerade miljöer för att ta itu med dagens affärsutmaningar.
tyvärr kommer prestandafördelarna som horisontell skalning ger till en kostnadskomplexitet. Distribuerade system introducerar många fler faktorer i prestandaekvationen än vad som fanns tidigare. Dataposter varierar mellan klienter / noder på olika platser. Enstaka felpunkter förstör systemets upptid, och intermittenta nätverksproblem kryper upp vid värsta möjliga tidpunkt.
dessa problem med konsistens (C), tillgänglighet (a) och partitionstolerans (P) över distribuerade system utgör vad ~~Eric Brewer~~ myntade som CAP Theorem. Enkelt uttryckt visar Cap-satsen att alla distribuerade system inte kan garantera C, A och P samtidigt, snarare måste avvägningar göras vid en tidpunkt för att uppnå den nivå av prestanda och tillgänglighet som krävs för en specifik uppgift.
konsistens – alla noder ser samma data samtidigt.
enkelt uttryckt returnerar en läsoperation värdet för den senaste skrivoperationen vilket gör att alla noder returnerar samma data. Ett system har konsistens om en transaktion börjar med systemet i ett konsekvent tillstånd och slutar med systemet i ett konsekvent tillstånd. I den här modellen kan ett system (och gör) växla till ett inkonsekvent tillstånd under en transaktion, men hela transaktionen rullas tillbaka om det finns ett fel under något steg i processen.
typiska relationsdatabaser är konsekventa: SQL Server, MySQL och PostgreSQL.
tillgänglighet – varje förfrågan får svar på framgång/misslyckande.
att uppnå tillgänglighet i ett distribuerat system kräver att systemet förblir operativt 100% av tiden. Varje klient får ett svar, oavsett tillståndet för varje enskild nod i systemet. Det här måttet är trivialt att mäta: antingen kan du skicka läs – /skrivkommandon, eller så kan du inte.
typiska relationsdatabaser finns också: SQL Server, MySQL och PostgreSQL. Detta innebär att relationsdatabaser finns i CA-utrymmet-konsistens och tillgänglighet. CA är dock inte bara reserverat för relationsdatabaser – vissa dokumentorienterade verktyg som ElasticSearch faller också under ca-paraplyet.
Partitionstolerans – systemet fortsätter att fungera trots meddelandeförlust eller partiellt fel.
de flesta tänker på deras datalager som en enda nod i nätverket. ”Detta är vår produktion SQL Server instans”. Den som har kört en produktionsinstans i mer än fyra minuter inser snabbt att detta skapar en enda felpunkt. Ett system som är partitionstolerant kan upprätthålla någon mängd nätverksfel som inte resulterar i ett fel i hela nätverket. Dataposter replikeras tillräckligt över kombinationer av noder och nätverk för att hålla systemet uppe genom intermittenta avbrott.
lagringssystem som faller under Partitionstolerans med konsistens (CP): MongoDB, Redis, AppFabric Caching och MemcacheDB. CP-system ger utmärkta distribuerade cachar eftersom varje klient får samma data och systemet är uppdelat över nätverksgränser.
lagringssystem som faller under Partitionstolerans med tillgänglighet (AP) inkluderar DynamoDB, CouchDB och Cassandra.
slutsats
distribuerade system tillåter oss att uppnå en nivå av datorkraft och tillgänglighet som helt enkelt inte var tillgängliga i går. Våra system har högre prestanda, lägre latens och nära 100% upptid i datacenter som spänner över hela världen. Bäst av allt, dagens system körs på råvaruhårdvara som är lätt att få och konfigurerbar med kostnader som närmar sig $0.
All denna datorkraft och nytta kommer dock till ett pris. Distribuerade system är mer komplexa än deras motsvarigheter i ett nätverk. Det finns många fler verktyg och färdigheter som måste förvärvas för att skapa ett verkligt skalbart högpresterande system. Att förstå komplexiteten i distribuerade system, göra lämpliga avvägningar för uppgiften till hands (CAP) och välja rätt verktyg för jobbet är alla kritiska färdigheter i en värld där datorsystem flyttar ut, inte upp.
