Redis transaksionet (përmes MULTI/EXEC) grupojnë komanda të shumta për të ekzekutuar atomikisht — të gjithë bashkë pa komanda të tjera që ndërhyjnë. E kombinuar me WATCH për kyçje optimiste, ato përballojnë skenarë që kërkojnë operacione të shumta për të qenë të qëndrueshme. Transaksionet Redis ndryshojnë nga transaksionet SQL në mënyra të rëndësishme.
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 fillon radhëzimin e komandave; EXEC i ekzekuton të gjithë atomikisht (asnjë ndërhyrje nga klientë të tjerë). DISCARD anulon një transaksion të radhëzuar.
# 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 ofron kyçje optimiste: nëse një çelës i vëzhguar modifikohet nga klient tjetër përpara EXEC, transaksioni aborton — duke ju lejuar të bëni me siguri operacione kontroll-pastaj-caktim (rifshini në konflikt).
⚠️ 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).
Kuptimi i transaksioneve Redis është i vlefshëm për kryerjen e operacioneve të shumta në mënyrë të qëndrueshme, kështu që është njohuri e dobishme — dhe të kuptuarit se si ndryshojnë nga transaksionet SQL është veçanërisht e rëndësishme për të shmangur supozime të pasakta.
Kapaciteti themelor — radhëzimi MULTI/EXEC i komandave për të ekzekutuar atomikisht (të gjithë bashkë, pa komanda të klientit tjetër që ndërhyjnë) — zgjidh skenarë ku operacione të shumta duhet të ndodhin si një njësi e qëndrueshme.
Mekanizmi WATCH ofron kyçje optimiste (kontroll-dhe-caktim): aborton transaksionin nëse një çelës i vëzhguar ndryshoi përpara EXEC, duke mundësuar operacione të sigurta kontroll-pastaj-modifiko (si zvogëlimi i një bilanci bazuar në vlerën e tij aktuale) me rifshim në konflikt — i rëndësishëm për operacione të sakta konkurente.
Pika më kritike është të kuptuarit se si transaksionet Redis ndryshojnë nga transaksionet SQL: Redis nuk ka kthim mbrapa — nëse një komandë dështon në kohën e EXEC, komandat e tjera ende ekzekutohen (Redis nuk zhbën), kështu që "atomiciteti" këtu nënkupton që komandat ekzekutohen bashkë pa ndërhyrje (izolim), JO e-gjitha-ose-asgjë me kthim mbrapa gabimi.
Mosfahim ky (duke supozuar kthim mbrapa si SQL) çon në trajtim të pasaktë të gabimit.
Të ditur se Lua scripts përdoren shpesh në vend për logjikë komplekse atomike (një skript ekzekutohet atomikisht si njësi) është i vlefshëm.
Pasi ekzekutimi i qëndrueshëm i operacioneve të shumta dhe konkurrenca e saktë janë nevoja reale, dhe pasi transaksionet Redis (MULTI/EXEC me WATCH për kyçje optimiste) ato përballojnë por me ndryshime të rëndësishme nga SQL (asnjë kthim mbrapa) që duhet të kuptohen, të kuptuarit e transaksioneve Redis — MULTI/EXEC, kyçje optimiste e bazuar në WATCH, dhe veçanërisht dallimi pa-kthim-mbrapa nga SQL — është njohuri e vlefshme, praktikisht-relevante për përdorimin e saktë të Redis në skenarë konkurente, ku të kuptuarit e ndryshimeve nga transaksionet SQL të njohura është po aq i rëndësishëm sa mekanizmi vetë.