Dela via

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

  • Artikel

Transaktion

En transaktion är en sekvens med åtgärder som utförs som en enda logisk arbetsenhet. Den uppvisar de vanliga ACID-egenskaperna (atomicitet, konsekvens, isolering, hållbarhet) för databastransaktioner:

  • Atomicitet: En transaktion måste vara en atomisk arbetsenhet. Med andra ord utförs antingen alla dess dataändringar eller så utförs ingen av dem.
  • Konsekvens: När transaktionen är klar måste den lämna alla data i ett konsekvent tillstånd. Alla interna datastrukturer måste vara korrekta i slutet av transaktionen.
  • Isolering: Ändringar som görs av samtidiga transaktioner måste isoleras från de ändringar som görs av andra samtidiga transaktioner. Isoleringsnivån som används för en åtgärd inom en ITransaction bestäms av IReliableState som utför åtgärden.
  • 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ån definierar i vilken utsträckning transaktionen måste isoleras från ändringar som görs av andra transaktioner. Det finns två isoleringsnivåer som stöds i Reliable Collections:

  • Upprepningsbar läsning: Anger att instruktioner inte kan läsa data som har ändrats men ännu inte utförts 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.
  • Ögonblicksbild: Anger att data som lästs av en instruktion i en transaktion är den transaktionsmässigt konsekventa versionen av de data som fanns i början av transaktionen. Transaktionen kan bara identifiera dataändringar som har genomförts före transaktionens början. Dataändringar som görs av andra transaktioner efter starten av den aktuella transaktionen är inte synliga för instruktioner som körs i den aktuella transaktionen. Effekten är som om uttrycken i en transaktion får en ögonblicksbild av de incheckade data som de fanns i början av transaktionen. Ögonblicksbilder är konsekventa i Reliable Collections.

Reliable Collections väljer automatiskt den isoleringsnivå som ska användas för en viss läsåtgärd beroende på åtgärden och replikens roll när transaktionen skapas. Följande är tabellen som visar standardvärden för isoleringsnivå för Reliable Dictionary- och Queue-åtgärder.

Åtgärd \ roll Primär Sekundär
Enskild entitetsläsning Repeterbar läsning Ögonblicksbild
Uppräkning, antal Ögonblicksbild Ögonblicksbild

Anteckning

Vanliga exempel för åtgärder med en entitet är IReliableDictionary.TryGetValueAsync, IReliableQueue.TryPeekAsync.

Både Reliable Dictionary och Reliable Queue stöder Read Your Writes. Med andra ord kommer alla skrivningar i en transaktion att vara synliga för en följande läsning som tillhör samma transaktion.

Lås

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

Reliable Dictionary använder låsning på radnivå för alla entitetsåtgärder. Reliable Queue avväger samtidighet med strikt transaktionell FIFO-egenskap. Reliable Queue använder lås på åtgärdsnivå som tillåter en transaktion med TryPeekAsync och/eller TryDequeueAsync och en transaktion i EnqueueAsync taget. Observera att om en TryPeekAsync eller TryDequeueAsync någon gång observerar att Reliable Queue är tom för att bevara FIFO kommer de också att låsa EnqueueAsync.

Skrivåtgärder har alltid exklusiva lås. För läsåtgärder beror låsning på ett par faktorer:

  • Alla läsåtgärder som utförs med ögonblicksbildisolering är låsfria.
  • Alla repeterbara läsåtgärder tar som standard delade lås.
  • För alla läsåtgärder som stöder upprepningsbar läsning kan användaren dock be om ett uppdateringslås i stället för det delade låset. Ett uppdateringslås är ett asymmetriskt lås som används för att förhindra en vanlig form av deadlock som inträffar när flera transaktioner låser resurser för potentiella uppdateringar vid ett senare tillfälle.

Matrisen för låskompatibilitet finns i följande tabell:

Begäran \ beviljas Ingen Delad Uppdatera Exklusiva
Delad Ingen konflikt Ingen konflikt Konflikt Konflikt
Uppdatera Ingen konflikt Ingen konflikt Konflikt Konflikt
Exklusiva Ingen konflikt Konflikt Konflikt Konflikt

Tidsgränsargumentet i Reliable Collections-API:er används för deadlock-identifiering. Två transaktioner (T1 och T2) försöker till exempel läsa och uppdatera K1. Det är möjligt för dem att låsa sig, eftersom båda har delat lås. I det här fallet överskrider en eller båda åtgärderna tidsgränsen. I det här scenariot kan ett uppdateringslås förhindra ett sådant dödläge.

Nästa steg