Bemærk: Dette indlæg er forældet. Du kan finde den mest opdaterede version her.
dette indlæg er forældet. Find den opdaterede version her. Jeg forlader med vilje denne artikel her, så jeg forstyrrer ikke andre sider, der linker tilbage til mig.
for flere år siden var det nemt at opbygge ydeevne i et system – du øgede enten dine maskinressourcer (opskalering) eller ændrede din applikation til at køre mere effektivt (performance tuning). I dag er der en tredje mulighed: vandret skalering (skala ud).
horisontal skalering af programmelsystemer er blevet nødvendig i de senere år på grund af den globale karakter af computing og de stadigt stigende ydelseskrav til applikationer. I mange tilfælde er det ikke længere acceptabelt at køre en enkelt server med en enkelt database i et enkelt datacenter ved siden af din virksomheds hovedkvarter. Vi har brug for virkelig distribuerede miljøer for at tackle nutidens forretningsudfordringer.
desværre kommer de ydelsesfordele, som vandret skalering giver, til en omkostningskompleksitet. Distribuerede systemer introducerer mange flere faktorer i præstationsligningen, end der eksisterede før. Dataposter varierer på tværs af klienter / noder på forskellige steder. Enkelte fejlpunkter ødelægger systemets oppetid, og intermitterende netværksproblemer kryber op på det værst mulige tidspunkt.
disse bekymringer om konsistens (C), tilgængelighed (a) og partitionstolerance (P) på tværs af distribuerede systemer udgør det ~~Eric brygger~~ opfundet som CAP-sætningen. Kort sagt viser CAP-sætningen, at ethvert distribueret system ikke kan garantere C, A og P samtidigt, snarere skal afvejninger foretages på et tidspunkt for at opnå det niveau af ydeevne og tilgængelighed, der kræves til en bestemt opgave.
konsistens – alle noder ser de samme data på samme tid.
kort sagt vil udførelse af en læseoperation returnere værdien af den seneste skriveoperation, der får alle noder til at returnere de samme data. Et system har konsistens, hvis en transaktion starter med systemet i en konsistent tilstand og slutter med systemet i en konsistent tilstand. I denne model kan et system (og gør) skifte til en inkonsekvent tilstand under en transaktion, men hele transaktionen rulles tilbage, hvis der er en fejl i et hvilket som helst trin i processen.
typiske relationsdatabaser er konsistente.
tilgængelighed – hver anmodning får et svar på succes/fiasko.
at opnå tilgængelighed i et distribueret system kræver, at systemet forbliver operationelt 100% af tiden. Hver klient får et svar, uanset tilstanden af en individuel node i systemet. Denne måling er triviel at måle: enten kan du indsende læse/skrive kommandoer, eller du kan ikke.
typiske relationsdatabaser er også tilgængelige. Dette betyder, at der findes relationsdatabaser i CA – rummet-konsistens og tilgængelighed. CA er dog ikke kun forbeholdt relationsdatabaser – nogle dokumentorienterede værktøjer som ElasticSearch falder også under ca-paraplyen.
Partitionstolerance – systemet fortsætter med at arbejde på trods af meddelelsestab eller delvis fejl.
de fleste mennesker tænker på deres datalager som en enkelt node i netværket. “Dette er vores produktions-SERVERINSTANS”. Enhver, der har kørt en produktionsinstans i mere end fire minutter, indser hurtigt, at dette skaber et enkelt fejlpunkt. Et system, der er partitionstolerant, kan opretholde enhver mængde netværksfejl, der ikke resulterer i en fejl i hele netværket. Dataposter replikeres tilstrækkeligt på tværs af kombinationer af noder og netværk til at holde systemet op gennem intermitterende afbrydelser.
lagringssystemer, der falder ind under Partitionstolerance med konsistens (CP): MongoDB, Redis, Appfabric Caching og MemcacheDB. CP-systemer giver fremragende distribuerede cacher, da hver klient får de samme data, og systemet er opdelt på tværs af netværksgrænser.
lagringssystemer, der falder ind under Partitionstolerance med tilgængelighed (AP), inkluderer DynamoDB, CouchDB og Cassandra.
konklusion
distribuerede systemer giver os mulighed for at opnå et niveau af computerkraft og tilgængelighed, der simpelthen ikke var tilgængelige i yesteryears. Vores systemer har højere ydeevne, lavere latenstid og næsten 100% oppetid i datacentre, der spænder over hele kloden. Bedst af alt, er systemer i dag kører på råvare udstyr, der er let opnåelige og konfigurerbare med omkostninger nærmer $0.
al denne computerkraft og fordel har dog en pris. Distribuerede systemer er mere komplekse end deres enkeltnet modparter. Der er mange flere værktøjer og færdigheder, der skal erhverves for at skabe et virkelig skalerbart, højtydende system. At forstå kompleksiteten i distribuerede systemer, foretage de passende afvejninger til den aktuelle opgave (CAP) og vælge det rigtige værktøj til jobbet er alle kritiske færdigheder i en verden, hvor computersystemer bevæger sig ud, ikke op.
