Dela via

Transaktioner och låslägen i Azure Service Fabric Reliable Collections

Transaktion

En transaktion är en sekvens med åtgärder som utförs som en enda logisk arbetsenhet. Den uppvisar de vanliga ACID (atomärhet, konsekvens, isolering, beständighet) egenskaperna hos databastransaktioner.

  • Atomicity: En transaktion måste vara en atomär arbetsenhet. Med andra ord, antingen utförs alla dess datamodifieringar, eller så utförs inga alls.
  • Konsekvens: När det är slutfört måste en transaktion lämna all data i ett konsekvent tillstånd. Alla interna datastrukturer måste vara korrekta vid slutet av transaktionen.
  • Isolation: Modifikationer gjorda av samtidiga transaktioner måste vara isolerade från modifikationer gjorda av andra samtidiga transaktioner. Isoleringsnivån som används för en operation inom en ITransaction bestäms av IReliableState som utför operationen.
  • Hållbarhet: När en transaktion har slutförts är dess effekter permanent på plats i systemet. Ändringarna kvarstår även i händelse av ett systemfel.

Isoleringsnivåer

Isoleringsnivå definierar graden till vilken transaktionen måste isoleras från ändringar som gjorts av andra transaktioner. Det finns två isoleringsnivåer som stöds i Reliable Collections:

  • Repeterbar läsning: Anger att uttryck inte kan läsa data som har ändrats men ännu inte bekräftats av andra transaktioner och att inga andra transaktioner kan ändra data som har lästs av den aktuella transaktionen förrän den aktuella transaktionen har slutförts.

    • Fördelar med läsrepeterbara transaktioner:
      • Lägre minnesfotavtryck än transaktioner med ögonblicksbilder
      • Säkerställer konsekvent återföring av värden vid flera läsningar vid en given tidpunkt
    • Överväganden för läsrepeterbara transaktioner:

      • Skrivningar blockeras när det finns en aktiv läsning av data

      • Läsningar blockeras också när det finns en aktiv skrivning av data.

  • Snapshot: Anger att data som läses av valfri sats i en transaktion är den transaktionsmässigt konsistenta versionen av data som fanns vid transaktionens början. Transaktionen kan bara identifiera dataändringar som har genomförts före den första läsningen av transaktionen. Dataändringar som görs av andra transaktioner efter att den aktuella transaktionen startat är inte synliga för uttryck som körs i den aktuella transaktionen.

    Effekten är som om uttalandena i en transaktion får en ögonblicksbild av de uppdaterade uppgifterna som de var vid transaktionens början. Ögonblicksbilder är konsekventa inom Pålitliga Samlingar.

    • Fördelar med transaktioner med ögonblicksbilder:
      • Tillåter skrivningar även när ett värde har lästs i en okommiterad transaktion
    • Överväganden för transaktioner med ögonblicksbilder:
      • Långvariga transaktioner med ögonblicksbilder kan resultera i ett stort minnesavtryck för tjänsten när fler värden flyttas till minnet för att upprätthålla ögonblicksbildisoleringen
      • Olika transaktioner kan returnera olika värden för läsdata beroende på när ögonblicksbilden togs

Tillförlitliga samlingar väljer automatiskt vilken isolationsnivå som ska användas för en given läsoperation beroende på operationen och replikenhetens roll vid tidpunkten för transaktionens skapande. Nedan följer en tabell som visar standardvärdena för isoleringsnivå för pålitliga ordboks- och köoperationer.

Operation \ Role Primär Sekundär
Läsning av Enstaka Enhet Upprepad Läsning Ögonblicksbild
Uppräkning, Antal Ögonblicksbild Ögonblicksbild

Anmärkning

Vanliga exempel på operationer med en enda enhet är IReliableDictionary.TryGetValueAsync, IReliableQueue.TryPeekAsync.

Både Reliable Dictionary och Reliable Queue stöder Read Your Writes. Med andra ord, kommer varje skrivning inom en transaktion att vara synlig för en efterföljande läsning som tillhör samma transaktion.

Exempel på repeterbart läsbeteende

Exempel på pålitliga samlingar med läsrepeterbar isolering

I det här exemplet kan du se att T2 hindras från att hämta ett lås på nyckeln K1 tills T1 committerar, eftersom T1 för närvarande håller ett läslås på den.

Exempel på ögonblicksbildsbeteende

Reliable Collections Snapshot Isolation Exempel

I det här exemplet kan du se att även om T2 har uppdaterat värdet för K1 till V6 räknar T2 fortfarande upp K1 som V1 samtidigt som den är medveten om sin egen ändring till K2. T3 påverkas inte eftersom det läser nycklar som inte har några aktuella skrivlås.

Lås

I Reliable Collections implementerar alla transaktioner rigorös tvåfaslåsning: en transaktion släpper inte de lås den har förvärvat förrän transaktionen avslutas med antingen avbrytning eller kommittering.

Reliable Dictionary använder radlåsning för alla operationer med enskilda entiteter. Pålitlig kö avväger samtidighet för en strikt transaktionell FIFO-egenskap. Reliable Queue använder lås på operationsnivå som tillåter en transaktion med TryPeekAsync och/eller TryDequeueAsync och en transaktion med EnqueueAsync åt gången. Observera att för att bevara FIFO, om en TryPeekAsync eller TryDequeueAsync någonsin observerar att Reliable Queue är tom, kommer de också att låsa EnqueueAsync.

Write operations always take Exclusive locks. För läsåtgärder beror låsningen på ett par faktorer:

  • Alla läsoperationer som utförs med snapshot-isolering är låsfria.
  • Any Repeatable Read operation by default takes Shared locks.
  • För alla läsoperationer som stöder Repeatable Read kan användaren begära en Uppdateringslås i stället för ett Delat lås. En uppdateringslås är ett asymmetriskt lås som används för att förhindra en vanlig form av dödläge som uppstår när flera transaktioner låser resurser för potentiella uppdateringar vid ett senare tillfälle.

Kompatibilitetsmatrisen för lås finns i följande tabell:

Begäran \ Beviljad Ingen Delad Uppdatera Exklusiv
Delad Ingen konflikt Ingen konflikt Konflikt Konflikt
Uppdatera Ingen konflikt Ingen konflikt Konflikt Konflikt
Exklusiv Ingen konflikt Konflikt Konflikt Konflikt

Timeout-argumentet i API:erna för pålitliga samlingar används för att upptäcka dödlägen. Exempelvis försöker två transaktioner (T1 och T2) läsa och uppdatera K1. Det är möjligt att de hamnar i dödläge, eftersom båda har ett delat lås.

I det här fallet kommer en eller båda av operationerna att tidsgränsen överskrids. I detta scenario kan en uppdateringslås förhindra en sådan återvändslåsning.

Nästa steg