Redis transaktiot (käyttäen MULTI/EXEC) ryhmittelevät useita komentoja suorittaa atomisesti — kaikki kerralla ilman muiden komentojen lomittautumista. Yhdessä WATCH-komennon kanssa optimistisen lukituksen toteuttamiseen, ne käsittelevät skenaarioita, joissa useat operaatiot täytyy olla konsistentteja. Redis-transaktiot eroavat SQL-transaktioista tärkeillä tavoilla.
MULTI # start a transaction (begin queuing commands)
SET account:1 100 # QUEUED (not executed yet)
SET account:2 200 # QUEUED
INCR counter # QUEUED
EXEC # execute ALL queued commands atomically (as one unit)
# → all commands run together, with NO other client's commands in between
MULTI aloittaa komentojen jonoituksen; EXEC suorittaa ne kaikki atomisesti (ei muiden asiakkaiden komentojen lomittautumista). DISCARD peruuttaa jonossa olevan transaktion.
# WATCH a key; if it CHANGES before EXEC, the transaction ABORTS (returns nil)
WATCH balance
val = GET balance # read the current value
MULTI
SET balance (val - 100) # modify based on what we read
EXEC # → if "balance" changed since WATCH, EXEC fails (returns nil)
# → retry the whole thing if it failed (optimistic concurrency control)
WATCH tarjoaa optimistisen lukituksen: jos toinen asiakas muuttaa vahtiin jäänyttä avainta ennen EXEC-komentoa, transaktio keskeytyy — jolloin voit turvallisesti tehdä tarkistus-sitten-asetus-operaatioita (uudelleenyritys konfliktissa).
⚠️ Redis transactions are NOT like SQL transactions:
✗ NO ROLLBACK — if a command fails at EXEC time, OTHER commands still execute
(errors don't roll back the transaction; Redis doesn't undo). Only syntax errors
before EXEC abort the whole thing.
✓ Atomicity = commands run together without interleaving (isolation), NOT all-or-nothing
with rollback on error.
→ Often Lua SCRIPTS are used instead for complex atomic logic (a script runs atomically).
Redis-transaktioiden ymmärtäminen on arvokasta useiden operaatioiden suorittamiseen johdonmukaisesti, joten se on hyödyllistä tietoa — ja erityisesti se, kuinka ne eroavat SQL-transaktioista, on tärkeää välttää virheellisiä oletuksia.
Peruskyky — MULTI/EXEC komentojen ryhmittely atomiseen suoritukseen (kaikki kerralla, ilman muiden asiakkaiden komentojen lomittautumista) — vastaa tilanteisiin, joissa useat operaatiot täytyy tapahtua johdonmukaisena yksikkönä.
WATCH-mekanismi tarjoaa optimistisen lukituksen (tarkistus-ja-asetus): transaktion keskeytyy, jos vahtiin jäänyt avain muuttui ennen EXEC-komentoa, mikä mahdollistaa turvallisten tarkistus-sitten-muokkaa-operaatioiden toteuttamisen (kuten saldon vähentämisen sen nykyisen arvon perusteella) uudelleyrityksen kanssa konfliktissa — tärkeä oikeille samanaikaisille operaatioille.
Kriittisin piste on ymmärtää, kuinka Redis-transaktiot eroavat SQL-transaktioista: Redisillä ei ole takaisinvetoa — jos komento epäonnistuu EXEC-aikaan, muut komennot silti suoritetaan (Redis ei kumoa), joten "atomisuus" tässä tarkoittaa komentoja, jotka suoritetaan ilman lomittautumista (eristäminen), EI kaikki-tai-ei-mitään virheellä vetäytymistä.
Tämän väärinymmärtäminen (SQL-maisen takaisinvedon olettaminen) johtaa virheelliseen virheenkäsittelyyn.
Tietäminen, että Lua-skriptejä käytetään usein sen sijaan monimutkaiseen atomiseen logiikkaan (skripti suoritetaan atomisesti yksikkönä) on arvokasta.
Koska johdonmukainen moni-operaatio-suoritus ja oikea samanaikaisuus ovat todellisia tarpeita, ja koska Redis-transaktiot (MULTI/EXEC ja WATCH optimistiselle lukitukselle) vastaavat niihin, mutta tärkeillä eroilla SQL:stä (ei takaisinvetoa), jotka täytyy ymmärtää, Redis-transaktioiden ymmärtäminen — MULTI/EXEC, WATCH-perustainen optimistinen lukitus, ja erityisesti ei-takaisinveto-ero SQL:stä — on arvokasta, käytännöllisesti relevanttia tietoa Redisin oikeaksi käyttämiseen samanaikaisissa tilanteissa, joissa erojen ymmärtäminen tutusta SQL-transaktioista on yhtä tärkeää kuin mekanismi itse.