Det förlorade uppdateringsproblemet inträffar när två eller flera transaktioner läser samma uppgifter och uppdaterar den sedan baserat på deras respektive läsningar. Om transaktionerna inte är korrekt synkroniserade kan uppdateringarna av en transaktion skriva över uppdateringarna av en annan, vilket kan leda till förlorade data. Här är flera åtgärder som kan vidtas för att förhindra detta:
1. Låsmekanismer:
* Exklusiva lås (skrivlås): När en transaktion vill uppdatera en rad förvärvar den ett exklusivt lås på den raden. Ingen annan transaktion kan förvärva någon form av lås (läs eller skriva) på den raden tills det exklusiva låset släpps. Detta säkerställer att endast en transaktion kan ändra raden vid en viss tidpunkt.
* delade lås (läs lås): När en transaktion vill läsa en rad förvärvar den ett delat lås på den raden. Flera transaktioner kan hålla delade lås på samma rad samtidigt. Ingen transaktion kan dock skaffa ett exklusivt lås medan det finns delade lås som hålls på den raden. Detta förhindrar författare från att störa läsarna.
* Lås granularitet: Nivån på vilken lås appliceras (t.ex. radnivå, sidnivå, tabellnivå, databasnivå) påverkar samtidighet och prestanda. Finare låsning (t.ex. radnivå) möjliggör mer samtidighet men har högre omkostnader, medan grovkornig låsning (t.ex. tabellnivå) minskar över huvudet men begränsar samtidighet.
2. Samtidighetskontrollprotokoll:
* Tvåfaslåsning (2PL): Ett samtidighetskontrollprotokoll som garanterar serialiserbarhet (och därmed förhindrar förlorade uppdateringar). Den har två faser:
* växande fas: En transaktion kan förvärva lås men kan inte släppa dem.
* krympningsfas: En transaktion kan släppa lås men kan inte förvärva nya.
Strikt tvåfaslåsning (Strict 2PL) har alla exklusiva lås fram till slutet av transaktionen (begå eller återuppspelning). Detta förhindrar kaskadering av rollbacks (där ett misslyckande med en transaktion kan tvinga fram återgång av andras).
* tidsstämpelbeställning (till): Varje transaktion tilldelas en unik tidsstämpel. Systemet använder dessa tidsstämplar för att säkerställa att motstridiga operationer utförs i storleksordningen för deras tidsstämplar. Om en transaktion försöker skriva ett värde som redan har skrivits över av en transaktion med en senare tidsstämpel, avvisas skrivningen och transaktionen rullas tillbaka. Detta tillvägagångssätt undviker dödlås, men kan leda till svält.
* Optimistisk samtidskontroll (OCC): Transaktioner fortsätter utan att förvärva lås. Innan en transaktion åtar sig kontrollerar den om någon annan transaktion har ändrat de uppgifter som den har läst. Om det finns konflikter rullas transaktionen tillbaka. OCC är lämplig för situationer med låg stridighet, eftersom rollbacks kan vara kostsamma. Det har vanligtvis tre faser:
* Läs fas: Transaktionen läser data och lagrar den i en lokal arbetsyta.
* Valideringsfas: Systemet kontrollerar om någon av de uppgifter som transaktionsläst har modifierats av en annan transaktion sedan den lästes.
* skrivfas: Om valideringen är framgångsrik tillämpas ändringarna på databasen. Annars rullas transaktionen tillbaka.
3. Använda transaktioner:
* syraegenskaper: Använd alltid transaktioner och se till att ditt databassystem upprätthåller syraegenskaperna (atomicitet, konsistens, isolering, hållbarhet). Egenskapen "isolering" är avgörande för att förhindra förlorade uppdateringar.
* Transaktionsisoleringsnivåer: SQL -databaser erbjuder olika isoleringsnivåer (t.ex. läst otillåtet, läs engagerad, repeterbar läsning, serialiserbar). Högre isoleringsnivåer (t.ex. serialiserbara) ger starkare garantier mot samtidighetsproblem som förlorade uppdateringar, men kan minska samtidighet och prestanda. Välj försiktigt lämplig isoleringsnivå för din applikations behov. "Serialiserbar" är den mest restriktiva och säkraste, men potentiellt långsammaste. "Läs engagerad" är ett vanligt standard och ger rimligt skydd.
4. Logik på applikationsnivå:
* atomoperationer (jämför och swap): Vissa databassystem och programmeringsspråk tillhandahåller atomoperationer som kan användas för att utföra läsmodifieringsoperationer i ett enda, odelbart steg. Till exempel kan operationen "Jämför och swap" (CAS) atomiskt uppdatera ett värde om och bara om dess nuvarande värde matchar ett specifikt förväntat värde. Detta tillvägagångssätt kan i vissa fall undvika behovet av uttryckliga lås.
* Spela in versionering/optimistisk låsning i applikationen: Applikationen kan inkludera ett versionnummer (eller tidsstämpel) i de data som den läser. Vid uppdatering av data innehåller applikationen det ursprungliga versionnumret. Databasen uppdaterar sedan bara raden om versionnumret matchar det aktuella versionnumret i databasen. Om versionnumren inte matchar avvisas uppdateringen och applikationen måste försöka igen uppdateringen. Detta är en annan implementering av den optimistiska strategin för samtidighetskontroll.
* Affärslogiköverväganden: Granska affärslogiken för att se om det finns sätt att undvika läs-modifiering-skrivoperationer helt. Kan du göra om datamodellen eller processen för att undvika potentialen för förlorade uppdateringar?
5. Databasdesign:
* Normalisering: En korrekt normaliserad databas hjälper till att minska dataredundansen och förbättra datakonsistensen, vilket indirekt kan hjälpa till att förhindra samtidighetsproblem.
* Lämpliga datatyper: Att använda lämpliga datatyper för dina data kan hjälpa till att förhindra fel och förbättra prestanda, vilket indirekt kan hjälpa till att förhindra samtidiga problem.
Exempelsscenario och lösningar:
Föreställ dig två användare som försöker uppdatera mängden en produkt i en inventeringstabell.
* Användare A: Läser kvantitet (t.ex. 10). Användare A vill sälja 2, så beräknar ny mängd som 8.
* Användare B: Läser kvantitet (t.ex. 10). Användare B vill sälja 3, så beräknar ny mängd som 7.
* Användare A: Skriver den nya mängden (8) till databasen.
* Användare B: Skriver den nya mängden (7) till databasen.
Den sista mängden i databasen är 7, men den bör vara 5 (10 - 2 - 3). Användar A:s uppdatering förlorades.
Här är några lösningar för detta scenario:
* Exklusivt lås: När endera användaren läser mängden för uppdatering, skaffa ett exklusivt lås på produktraden. Den andra användaren måste vänta tills låset släpps innan han läser och uppdateras.
* Serialiserbar isoleringsnivå: Ställ in transaktionsisoleringsnivån på serialiserbar. Detta säkerställer att de två transaktionerna effektivt serialiseras och förhindrar dem från att störa varandra.
* Optimistisk låsning (med versionnummer):
1. När användaren A läser mängden (10) läser de också ett versionnummer (t.ex. 1).
2. Användare A beräknar den nya mängden (8) och inkluderar det ursprungliga versionnummer (1) i uppdateringsuttalandet.
3. Databasen uppdaterar mängden endast om det aktuella versionnumret fortfarande är 1. Uppdateringsuttalandet ökar också versionnumret (t.ex. till 2).
4. Om användaren B försöker uppdatera efter att användaren A redan har åtagit sig kommer användar B:s uppdatering att misslyckas (eftersom versionnumret nu är 2), och de kommer att behöva läsa om data och försöka uppdatera uppdateringen.
* Atomisk ökning/minskning: Använd en databasspecifik atomökning/dekrement-operation, om tillgänglig. Till exempel:`Uppdatera lageruppsättning kvantitet =kvantitet-2 där produkt_id =x` Denna metod undviker läsmodifieringssekvensen.
Att välja rätt tillvägagångssätt:
Det bästa tillvägagångssättet för att förhindra förlorade uppdateringar beror på flera faktorer, inklusive:
* Samtidsnivå: Hur ofta görs uppdateringar till samma data?
* Prestandakrav: Vad är den acceptabla omkostnaderna för samtidskontroll?
* Databasesystemfunktioner: Vilka samtidighetskontrollmekanismer stöds av databasen?
* Applikationskomplexitet: Hur komplex är applikationslogiken och hur lätt kan den modifieras?
Noggrann övervägande av dessa faktorer hjälper dig att välja den mest effektiva lösningen för din specifika situation. Att använda en kombination av tekniker är ofta den mest effektiva strategin. Till exempel använder du transaktioner med en lämplig isoleringsnivå i samband med optimistisk låsning på applikationsnivå.
