Redis transactions (MULTI/EXEC के माध्यम से) कई commands को atomically execute करने के लिए समूहित करते हैं — सभी एक साथ, बिना अन्य commands के बीच में आए। optimistic locking के लिए WATCH के साथ संयुक्त, ये उन परिदृश्यों को संभालते हैं जिनमें कई operations को consistent होने की ज़रूरत होती है। Redis transactions महत्वपूर्ण तरीकों से SQL transactions से भिन्न होते हैं।
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 commands को queue करना शुरू करता है; EXEC उन्हें सभी atomically चलाता है (अन्य clients से कोई interleaving नहीं)। DISCARD एक queued transaction को cancel करता है।
# 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 optimistic locking प्रदान करता है: यदि कोई watched key EXEC से पहले किसी अन्य client द्वारा modify किया जाता है, तो transaction abort हो जाता है — आपको सुरक्षित रूप से check-then-set operations करने देते हुए (conflict पर retry)।
⚠️ 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 transactions को समझना कई operations को consistently करने के लिए मूल्यवान है, इसलिए यह उपयोगी ज्ञान है — और यह समझना कि वे SQL transactions से कैसे भिन्न हैं, गलत धारणाओं से बचने के लिए विशेष रूप से महत्वपूर्ण है।
मुख्य क्षमता — MULTI/EXEC commands को atomically execute करने के लिए समूहित करना (सभी एक साथ, अन्य client के commands के बीच में आए बिना) — उन परिदृश्यों को संबोधित करती है जहाँ कई operations को एक consistent इकाई के रूप में होना चाहिए।
WATCH तंत्र optimistic locking प्रदान करता है (check-and-set): यदि कोई watched key EXEC से पहले बदल जाता है तो transaction को abort करना, सुरक्षित check-then-modify operations (जैसे किसी balance को उसके वर्तमान मूल्य के आधार पर decrement करना) को conflict पर retry के साथ संभव बनाते हुए — सही concurrent operations के लिए महत्वपूर्ण।
सबसे महत्वपूर्ण बिंदु यह समझना है कि Redis transactions SQL transactions से कैसे भिन्न हैं: Redis में कोई rollback नहीं है — यदि कोई command EXEC समय पर fail होता है, तो अन्य commands फिर भी execute होते हैं (Redis undo नहीं करता), इसलिए यहाँ "atomicity" का अर्थ है commands बिना interleaving के एक साथ चलते हैं (isolation), error rollback के साथ all-or-nothing नहीं।
इसे गलत समझना (SQL-जैसा rollback मान लेना) गलत error handling की ओर ले जाता है।
यह जानना कि Lua scripts अक्सर complex atomic logic के लिए इसके बजाय उपयोग होते हैं (एक script एक इकाई के रूप में atomically execute होता है) मूल्यवान है।
चूँकि consistent multi-operation execution और सही concurrency वास्तविक ज़रूरतें हैं, और चूँकि Redis transactions (optimistic locking के लिए WATCH के साथ MULTI/EXEC) इन्हें संबोधित करते हैं लेकिन SQL से महत्वपूर्ण अंतरों (कोई rollback नहीं) के साथ जिन्हें समझना ज़रूरी है, इसलिए Redis transactions को समझना — MULTI/EXEC, WATCH-आधारित optimistic locking, और विशेष रूप से SQL से no-rollback भेद — concurrent परिदृश्यों में Redis को सही ढंग से उपयोग करने के लिए मूल्यवान, व्यावहारिक रूप से प्रासंगिक ज्ञान है, जहाँ परिचित SQL transactions से अंतरों को समझना तंत्र जितना ही महत्वपूर्ण है।