Transaktioner inden for en Redis Cluster er en anden historie end transaktioner med Redis Standalone.
TL;DR;
Det er mere et konceptuelt problem med hensyn til garantier og afvejninger end et kundeproblem.
Forklaring
I Redis Cluster er en bestemt node en master for en eller flere hash-slots, det er partitioneringsskemaet til at sønderdele data mellem flere noder. Én hash-slot, beregnet ud fra de nøgler, der bruges i kommandoen, bor på én node. Kommandoer med flere nøgler er begrænset til at give efter til den samme hash-slot. Ellers bliver de afvist. Sådanne konstellationer kaldes cross-slot.
Transaktioner ser ud til at være løsningen til at udføre kommandoer til kryds-slot nøgler, men på et bestemt tidspunkt ville man forlade omfanget af en node og ville have brug for en anden node for at fortsætte transaktionen. Dette kan være, hvis den ene nøgle bor på en node, og den anden nøgle bor på en anden node. Der er stadig ingen transaktionskoordinering, og det kan nogle gange være et problem for Redis Cluster-problemer.
En API på højt niveau, der yder transaktionssupport til Redis Cluster, står over for flere problemer, og der er indtil videre to strategier, hvordan man håndterer transaktioner i Redis Cluster:
Understøtte transaktioner, hvis alle nøgler er placeret på én node
Denne mulighed giver mulighed for fuldt udstyrede transaktioner. Klientbiblioteket er forpligtet til at holde styr på den node, transaktionen udføres og forbyde nøgler uden for slotområdet i den tid, transaktionen er i gang. Fordi slot kun kan bestemmes ved at bruge en kommando, der indeholder en nøgle, skal klienten indstille et transaktionsflag, og på den allerførste kommando, der indeholder en nøgle, skal MULTI-kommandoen udsendes, lige før den første kommando i transaktionen. Begrænsningen her er klart kravet om at have alle nøgler placeret på én node.
Distribuerede transaktioner
I dette tilfælde startes flere transaktioner på alle noder, der slutter sig til den distribuerede transaktion. Denne distribuerede transaktion kan inkludere nøgler fra alle masterknudepunkter. Når transaktionen er udført, udløser klientbiblioteket udførelsen af transaktionen, biblioteket indsamler alle resultater (for at opretholde rækkefølgen af kommandoresultater) og returnerer det til den, der ringer.
Denne type transaktioner er gennemsigtig for kunden. Så snart der anmodes om en nøgle på en bestemt node, og noden endnu ikke er en del af transaktionen, vises enMULTI kommandoen udstedes for at forbinde noden med transaktionen. Ulempen her er, at transaktioner ikke længere kan være betingede (WATCH ). De enkelte transaktioner har ingen viden om, hvorvidt en nøgle blev ændret på en anden node, og så en transaktion kunne rulles tilbage, mens de andre transaktioner ville lykkes. Lyder lidt som to-fase-commit.
Konklusion
Redis Transactions føles som atomkommando-batching, der kan gøres betinget. Det er vigtigt at huske, at udførelse af kommando udskydes, fordi læste resultater returnerer i det øjeblik, transaktionen udføres og ikke på det tidspunkt, hvor kommandoen udstedes.
For Redis Cluster har kunderne ikke besluttet sig for en global strategi. Det er sikkert at køre transaktioner på en bestemt Redis Cluster-node, men du er begrænset til nøglerne, der betjenes af den node. Begge mulige strategier har egenskaber, der kan være nyttige til visse use-cases, men som også har begrænsninger.