Varför kan halvsynkron replikation behövas?

Hej allihop. Det här är Vladislav Rodin. För närvarande undervisar jag på plattformen OTUS kurser som handlar om programvaruarkitektur och programvaruarkitektur som utsätts för hög belastning. Inför starten av den nya kursomgången »Arkitekt för hög belastning« har jag beslutat att skriva ett litet originalmaterial som jag vill dela med er.

Introduktion

Eftersom HDD endast kan utföra cirka 400-700 operationer per sekund (vilket är ohållbart jämfört med de typiska rps:arna som förekommer i ett högbelastningssystem), utgör en klassisk databashantering en flaskhals i arkitekturen. Därför är det nödvändigt att särskilt fokusera på mönstren för skalning av detta lagringssystem.

För närvarande finns det två mönster för att skala databasen: replikation och sharding. Sharding gör det möjligt att skala skrivoperationen och, som följd, minska den rps som skrivs till en server i din kluster. Replikation gör samma sak men med läsoperationer. Denna artikel ägnas just detta mönster.

Replikation

Om man ser replikation på en helt övergripande nivå, är det en enkel sak: du hade en server, där data lagrades, och sedan klarade inte denna server av belastningen vid läsning av dessa data. Du lägger till några fler servrar, synkroniserar data på alla servrar, och användare kan läsa från vilken server som helst i ditt kluster.

Trots den till synes enkla strukturen finns det flera sätt att klassificera olika implementeringar av detta schema:

• Efter roller i klustret (master-master eller master-slave)
• Efter överförda objekt (row-based, statement-based eller mixed)
• Efter mekanismen för nodsynkronisering

Idag ska vi fokusera på just den tredje punkten.

Hur en transaktion kommittas

Detta ämne är direkt relaterat till replikation, en separat artikel kan skrivas om det, men eftersom förståelsen för hur transaktioner kommittas är avgörande för att läsa vidare, låt mig påminna om de mest grundläggande delarna. Kommittén av transaktionen sker i tre steg:

1. Skriva transaktionen till databasens logg.
2. Tillämpa transaktionen i databasens motor.
3. Skicka bekräftelse till klienten om att transaktionen har tillämpats framgångsrikt.

I olika databaser kan det uppstå nyanser i denna algoritm: till exempel har MySQL:s InnoDB-motor 2 loggar: en för replikering (binary log) och en annan för att upprätthålla ACID (undo/redolog), medan PostgreSQL har en logg som utför båda funktionerna (write ahead log = WAL). Men ovan har den allmänna konceptet presenterats, vilket gör det möjligt att ignorera sådana nyanser.

Synchronous (sync) replikering

Låt oss lägga till logik för replikering av de erhållna ändringarna i algoritmen för transaktionscommit:

1. Skriva transaktionen till databasens logg.
2. Tillämpa transaktionen i databasens motor.
3. Skicka data till alla repliker.
4. Ta emot bekräftelse från alla repliker om att transaktionen har genomförts.
5. Skicka bekräftelse till klienten om att transaktionen har tillämpats framgångsrikt.

Med denna metod får vi ett antal nackdelar:

• klienten väntar på att ändringarna ska tillämpas på alla repliker.
• med en ökning av antalet noder i klustret minskar vi sannolikheten för att skrivoperationen lyckas.

Om första punkten är mer eller mindre klar, så är anledningarna till den andra punkten värda att förklara. Om vi inte får svar från minst en nod vid synkroniserad replikering, rullar vi tillbaka transaktionen. Därmed, genom att öka antalet noder i klustret, ökar du sannolikheten för att skrivoperationen misslyckas.

Kan vi vänta på bekräftelse endast från en viss andel av noderna, till exempel från 51% (kvorum)? Ja, det kan vi, men i det klassiska fallet krävs bekräftelse från alla noder, eftersom det är så vi kan säkerställa full konsistens av data i klustret, vilket utan tvekan är en fördel med denna typ av replikering.

Asynkron (async) replikering

Låt oss förändra den tidigare algoritmen. Vi kommer att skicka data till repliker "någon gång senare", och "någon gång senare" kommer ändringarna att tillämpas på replikerna:

1. Skriva transaktionen till databasens logg.
2. Tillämpa transaktionen i databasens motor.
3. Skicka bekräftelse till klienten om att transaktionen har tillämpats framgångsrikt.
4. Skicka data till replikerna och tillämpa ändringarna.

Denna metod resulterar i att klustret arbetar snabbt, eftersom vi inte håller klienten i väntan medan data når repliker och ännu måste bli kommittade.

Men villkoret för att skicka data till repliker "någon gång senare" kan leda till att transaktionen går förlorad, inklusive en bekräftad transaktion för användaren, eftersom om data inte hinner replikeras och bekräftelse har skickats till klienten om att operationen har genomförts men noden, som fick ändringarna, har en hårddisk som kraschar, förlorar vi transaktionen, vilket kan leda till mycket otrevliga konsekvenser.

Halvsynkron (semisync) replikering

Äntligen har vi kommit till den semisynkrona replikeringen. Denna typ av replikering är inte särskilt känd och spridd, men den är intressant eftersom den kan förena fördelarna med både synkron och asynkron replikering.

Låt oss försöka kombinera de två tidigare tillvägagångssätten. Vi ska inte hålla kunden för länge, men kräva att data replikeras:

1. Skriva transaktionen till databasens logg.
2. Tillämpa transaktionen i databasens motor.
3. Skickar data till repliker.
4. Mottar bekräftelse från repliken om att ändringar har tagits emot (de kommer att tillämpas "någon gång senare").
5. Skicka bekräftelse till klienten om att transaktionen har tillämpats framgångsrikt.

Observera att med denna algoritm kan transaktionsförlust endast inträffa om både noden som tar emot ändringar och repliknodens fallerar. Sannolikheten för en sådan störning bedöms som låg, och dessa risker accepteras.

Men med detta tillvägagångssätt finns det en risk för spökläsningar. Tänk er följande scenario: vid steg 4 fick vi ingen bekräftelse från någon replik. Vi måste återkalla denna transaktion och inte returnera en bekräftelse till kunden. Eftersom data tillämpades i steg 2, finns det ett tidsintervall mellan slutet av steg 2 och återkallandet av transaktionen, under vilket parallella transaktioner kan se de förändringar som inte borde finnas i databasen.

Förlustfri semisynkron replikering

Om man tänker lite kan man bara byta steg i algoritmen för att åtgärda problemet med spökläsningar i detta scenario:

1. Skriva transaktionen till databasens logg.
2. Skickar data till repliken.
3. Mottar bekräftelse från repliken om att ändringar har tagits emot (de kommer att tillämpas "någon gång senare").
4. Tillämpa transaktionen i databasens motor.
5. Skicka bekräftelse till klienten om att transaktionen har tillämpats framgångsrikt.

Nu kommittar vi ändringar endast om de har replikeras.

Utdata

Som alltid finns det inga perfekta lösningar, det finns en uppsättning lösningar, var och en med sina egna fördelar och nackdelar och som passar för olika klassers uppgifter. Detta gäller även valet av mekanism för datasykronisering av den replikerade databasen. Uppsättningen fördelar som semisynkron replikering har är tillräckligt solid och intressant för att den ska erkännas som värd uppmärksamhet, trots att den är lite spridd.

Det är allt för nu. Vi ses på kurs!

Källa: habr.com