Transactions za Redis (kupitia MULTI/EXEC) huunganisha amri nyingi kutekeleza kiatomiki — zote pamoja bila amri nyingine kuingilia. Zikiunganishwa na WATCH kwa optimistic locking, hushughulikia hali zinazohitaji operesheni nyingi kuwa thabiti. Transactions za Redis zinatofautiana na SQL transactions kwa njia muhimu.
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 huanza kuweka amri foleni; EXEC huziendesha zote kiatomiki (bila kuingilia kutoka clients wengine). DISCARD hughairi transaction iliyowekwa foleni.
# 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 hutoa optimistic locking: ikiwa key iliyofuatiliwa imebadilishwa na client mwingine kabla ya EXEC, transaction huahirishwa — ikikuruhusu kufanya kwa usalama operesheni za check-then-set (jaribu tena kwenye mgongano).
⚠️ 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).
Kuelewa Redis transactions ni yenye thamani kwa kufanya operesheni nyingi kwa uthabiti, hivyo ni maarifa muhimu — na kuelewa jinsi zinavyotofautiana na SQL transactions ni muhimu hasa ili kuepuka mawazo yasiyo sahihi.
Uwezo wa msingi — MULTI/EXEC kuunganisha amri kutekeleza kiatomiki (zote pamoja, bila amri za client mwingine kuingilia) — hushughulikia hali ambapo operesheni nyingi lazima zifanyike kama kitengo kimoja thabiti.
Utaratibu wa WATCH hutoa optimistic locking (check-and-set): kuahirisha transaction ikiwa key iliyofuatiliwa imebadilika kabla ya EXEC, ukiwezesha operesheni salama za check-then-modify (kama kupunguza balance kulingana na thamani yake ya sasa) na jaribu tena kwenye mgongano — muhimu kwa operesheni sahihi za wakati mmoja.
Jambo muhimu zaidi ni kuelewa jinsi Redis transactions zinavyotofautiana na SQL transactions: Redis haina rollback — ikiwa amri inashindwa wakati wa EXEC, amri nyingine bado zinatekelezwa (Redis haifuti), hivyo "atomicity" hapa inamaanisha amri huendeshwa pamoja bila kuingilia (isolation), SI yote-au-hakuna na rollback kwenye kosa.
Kutoelewa hili (kudhani rollback kama ya SQL) husababisha ushughulikiaji usio sahihi wa makosa.
Kujua kwamba Lua scripts mara nyingi hutumika badala yake kwa atomic logic ngumu (script hutekeleza kiatomiki kama kitengo) ni yenye thamani.
Kwa kuwa utekelezaji thabiti wa operesheni nyingi na concurrency sahihi ni mahitaji halisi, na kwa kuwa Redis transactions (MULTI/EXEC na WATCH kwa optimistic locking) zinazishughulikia lakini zenye tofauti muhimu na SQL (hakuna rollback) ambazo lazima zieleweke, kuelewa Redis transactions — MULTI/EXEC, optimistic locking inayotegemea WATCH, na hasa tofauti ya hakuna-rollback na SQL — ni maarifa yenye thamani, yanayohusiana na vitendo kwa kutumia Redis kwa usahihi katika hali za wakati mmoja, ambapo kuelewa tofauti na SQL transactions zinazofahamika ni muhimu kama utaratibu wenyewe.