Transaksi Redis (melalui MULTI/EXEC) mengumpulkan pelbagai arahan untuk dilaksanakan secara atomik — semua bersama tanpa arahan lain menyelang. Digabungkan dengan WATCH untuk optimistic locking, ia menangani senario yang memerlukan pelbagai operasi menjadi konsisten. Transaksi Redis berbeza daripada transaksi SQL dalam cara yang penting.
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 memulakan penggiliran arahan; EXEC menjalankan kesemuanya secara atomik (tiada selangan daripada klien lain). DISCARD membatalkan transaksi yang digilirkan.
# 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 menyediakan optimistic locking: jika key yang diawasi diubah suai oleh klien lain sebelum EXEC, transaksi digugurkan — membenarkan anda melakukan operasi check-then-set dengan selamat (cuba semula apabila konflik).
⚠️ 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).
Memahami transaksi Redis adalah bernilai untuk melakukan pelbagai operasi secara konsisten, jadi ia adalah pengetahuan yang berguna — dan memahami bagaimana ia berbeza daripada transaksi SQL amat penting untuk mengelakkan andaian yang salah.
Keupayaan teras — MULTI/EXEC mengumpulkan arahan untuk dilaksanakan secara atomik (semua bersama, tanpa arahan klien lain menyelang) — menangani senario di mana pelbagai operasi mesti berlaku sebagai satu unit yang konsisten.
Mekanisme WATCH menyediakan optimistic locking (check-and-set): menggugurkan transaksi jika key yang diawasi berubah sebelum EXEC, membolehkan operasi check-then-modify yang selamat (seperti menolak baki berdasarkan nilai semasanya) dengan cuba semula apabila konflik — penting untuk operasi serentak yang betul.
Perkara paling kritikal ialah memahami bagaimana transaksi Redis berbeza daripada transaksi SQL: Redis tiada rollback — jika arahan gagal pada masa EXEC, arahan lain masih dilaksanakan (Redis tidak membuat asal), jadi "atomik" di sini bermaksud arahan berjalan bersama tanpa menyelang (isolasi), BUKAN semua-atau-tiada dengan rollback ralat.
Salah faham ini (menganggap rollback seperti SQL) membawa kepada pengendalian ralat yang salah.
Mengetahui bahawa Lua scripts sering digunakan sebaliknya untuk logik atomik kompleks (skrip dilaksanakan secara atomik sebagai satu unit) adalah bernilai.
Memandangkan pelaksanaan pelbagai operasi yang konsisten dan keserentakan yang betul adalah keperluan sebenar, dan kerana transaksi Redis (MULTI/EXEC dengan WATCH untuk optimistic locking) menanganinya tetapi dengan perbezaan penting daripada SQL (tiada rollback) yang mesti difahami, memahami transaksi Redis — MULTI/EXEC, optimistic locking berasaskan WATCH, dan terutamanya perbezaan tiada-rollback daripada SQL — adalah pengetahuan bernilai yang relevan dari segi praktikal untuk menggunakan Redis dengan betul dalam senario serentak, di mana memahami perbezaan daripada transaksi SQL yang biasa adalah sama pentingnya dengan mekanisme itu sendiri.
Pustaka soalan temu duga IT dengan jawapan terperinci — daripada Junior hingga Senior.
Derma