Transacties binnen een Redis Cluster zijn een ander verhaal dan transacties met Redis Standalone.
TL;DR;
Dat is meer een conceptueel probleem met betrekking tot garanties en afwegingen dan een kwestie van een klant.
Uitleg
In Redis Cluster is een bepaald knooppunt een master voor een of meer hash-slots, dat is het partitioneringsschema om gegevens tussen meerdere knooppunten te sharden. Eén hash-slot, berekend op basis van de sleutels die in de opdracht worden gebruikt, leeft op één knooppunt. Opdrachten met meerdere sleutels zijn beperkt tot hetzelfde hash-slot. Anders worden ze afgewezen. Dergelijke sterrenbeelden worden cross-slot genoemd.
Transacties lijken de oplossing te zijn om commando's uit te voeren naar sleutels met meerdere slots, maar op een bepaald moment zou men het bereik van één knooppunt verlaten en een ander knooppunt nodig hebben om de transactie voort te zetten. Dit kan zijn als de ene sleutel op het ene knooppunt leeft en de andere sleutel op een ander knooppunt. Er is nog steeds geen transactiecoördinatie en dat kan soms een probleem zijn voor Redis Cluster-problemen.
Een API op hoog niveau die transactionele ondersteuning voor Redis Cluster biedt, heeft te maken met meerdere problemen en er zijn tot nu toe twee strategieën voor het omgaan met transacties in Redis Cluster:
Ondersteunt transacties als alle sleutels zich op één node bevinden
Met deze optie kunnen transacties met alle functies worden uitgevoerd. De clientbibliotheek is vereist om bij te houden op welk knooppunt de transactie wordt uitgevoerd en om sleutels buiten het slotbereik te verbieden gedurende de tijd dat de transactie aan de gang is. Omdat het slot alleen kan worden bepaald door een commando met een sleutel te gebruiken, moet de klant een transactievlag instellen en bij het allereerste commando dat een sleutel bevat, moet het MULTI-commando worden gegeven, vlak voor het eerste commando binnen de transactie. De beperking hier is duidelijk de vereiste om alle sleutels op één knooppunt te hebben.
Gedistribueerde transacties
In dit geval worden meerdere transacties gestart op alle knooppunten die deelnemen aan de gedistribueerde transactie. Deze gedistribueerde transactie kan sleutels van alle hoofdknooppunten bevatten. Zodra de transactie is uitgevoerd, activeert de clientbibliotheek de uitvoering van de transactie, verzamelt de bibliotheek alle resultaten (om de volgorde van de opdrachtresultaten te behouden) en stuurt deze terug naar de beller.
Deze stijl van transacties is transparant voor de klant. Zodra een sleutel op een bepaalde node wordt aangevraagd en de node nog geen deel uitmaakt van de transactie, wordt eenMULTI opdracht wordt gegeven om het knooppunt aan de transactie toe te voegen. Het nadeel hiervan is dat transacties niet meer voorwaardelijk kunnen zijn (WATCH ). De afzonderlijke transacties weten niet of een sleutel op een ander knooppunt is gewijzigd, en dus kan de ene transactie worden teruggedraaid terwijl de andere transacties slagen. Klinkt een beetje als twee-fasen-commit.
Conclusie
Redis Transactions voelt aan als batching met atomaire commando's die voorwaardelijk kunnen worden gemaakt. Het is belangrijk om te onthouden dat de uitvoering van de opdracht wordt uitgesteld omdat de leesresultaten terugkeren op het moment dat de transactie wordt uitgevoerd en niet op het moment dat de opdracht wordt gegeven.
Voor Redis Cluster hebben klanten geen globale strategie gekozen. Het is veilig om transacties uit te voeren op een bepaald Redis Cluster-knooppunt, maar u bent beperkt tot de sleutels die door dat knooppunt worden bediend. Beide mogelijke strategieën hebben eigenschappen die nuttig kunnen zijn voor bepaalde gebruikssituaties, maar ook met beperkingen.