Transaktioner inom ett Redis-kluster är en annan historia än transaktioner med Redis Standalone.
TL;DR;
Det är mer ett konceptuellt problem när det gäller garantier och avvägningar än en kundfråga.
Förklaring
I Redis Cluster är en viss nod en master för en eller flera hash-slots, det är partitioneringsschemat för att splittra data mellan flera noder. En hash-slot, beräknad från nycklarna som används i kommandot, bor på en nod. Kommandon med flera nycklar är begränsade till att ge efter till samma hash-slot. Annars avvisas de. Sådana konstellationer kallas cross-slot.
Transaktioner verkar vara lösningen för att exekvera kommandon till cross-slot-nycklar men vid en viss tidpunkt skulle man lämna omfattningen av en nod och behöva en annan nod för att fortsätta transaktionen. Detta kan vara om den ena nyckeln bor på en nod och den andra nyckeln bor på en annan nod. Det finns fortfarande ingen transaktionskoordinering och det kan ibland vara ett problem för Redis Cluster-problem.
Ett API på hög nivå som tillhandahåller transaktionsstöd för Redis Cluster står inför flera problem och det finns två strategier hittills, hur man hanterar transaktioner i Redis Cluster:
Stöd transaktioner om alla nycklar finns på en nod
Detta alternativ tillåter fullfjädrade transaktioner. Klientbiblioteket måste hålla reda på den nod som transaktionen exekveras och förbjuda nycklar utanför luckintervallet under den tid som transaktionen pågår. Eftersom luckan endast kan bestämmas genom att använda ett kommando som innehåller en nyckel, måste klienten ställa in en transaktionsflagga och på det allra första kommandot som innehåller en nyckel måste MULTI-kommandot utfärdas, precis före det första kommandot i transaktionen. Begränsningen här är helt klart kravet att ha alla nycklar placerade på en nod.
Distribuerade transaktioner
I det här fallet startas flera transaktioner på alla noder som går med i den distribuerade transaktionen. Denna distribuerade transaktion kan inkludera nycklar från alla huvudnoder. När transaktionen är utförd utlöser klientbiblioteket exekveringen av transaktionen, biblioteket samlar in alla resultat (för att bibehålla ordningen på kommandoresultaten) och returnerar det till den som ringer.
Denna typ av transaktioner är transparent för kunden. Så snart en nyckel på en viss nod begärs och noden ännu inte är en del av transaktionen visas enMULTI kommandot utfärdas för att ansluta noden till transaktionen. Nackdelen här är att transaktioner inte längre kan vara villkorade (WATCH ). De enskilda transaktionerna har ingen kunskap om huruvida en nyckel ändrades på en annan nod, så en transaktion kunde återställas medan de andra transaktionerna skulle lyckas. Låter lite som två-fas-commit.
Slutsats
Redis Transactions känns som atomkommandobatchning som kan göras villkorad. Det är viktigt att komma ihåg att kommandoexekveringen skjuts upp eftersom läsresultaten återkommer i det ögonblick då transaktionen utförs och inte vid den tidpunkt då kommandot utfärdas.
För Redis Cluster har kunderna inte bestämt sig för en global strategi. Det är säkert att köra transaktioner på en viss Redis Cluster-nod men du är begränsad till nycklarna som betjänas av den noden. Båda möjliga strategierna har egenskaper som kan vara användbara för vissa användningsfall men som också har begränsningar.