معاملات Redis (عبر MULTI/EXEC) تجمع أوامر متعددة لتنفيذها بشكل ذري — الكل معاً دون تداخل الأوامر الأخرى. بالدمج مع WATCH للقفل المتفائل، تتعامل مع سيناريوهات تحتاج عمليات متعددة ليكون متسقاً. معاملات Redis تختلف عن معاملات SQL بطرق مهمة.
معاملات Redis (عبر MULTI/EXEC) تجمع أوامر متعددة لتنفيذها بشكل ذري — الكل معاً دون تداخل الأوامر الأخرى. بالدمج مع WATCH للقفل المتفائل، تتعامل مع سيناريوهات تحتاج عمليات متعددة ليكون متسقاً. معاملات Redis تختلف عن معاملات SQL بطرق مهمة.
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 يبدأ طابور الأوامر؛ EXEC ينفذها جميعاً بشكل ذري (لا تداخل من عملاء آخرين). DISCARD يلغي معاملة في الطابور.
# 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 يوفر القفل المتفائل: إذا تم تعديل مفتاح مراقب من قبل عميل آخر قبل EXEC، تُجهض المعاملة — مما يتيح لك بأمان إجراء عمليات التحقق-ثم-التعيين (إعادة المحاولة عند التضارب).
⚠️ 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 مفيد لإجراء عمليات متعددة بشكل متسق، لذا فهو معرفة قيمة — وفهم كيفية اختلافها عن معاملات SQL مهم بشكل خاص لتجنب الافتراضات الخاطئة.
القدرة الأساسية — تجميع أوامر MULTI/EXEC لـالتنفيذ الذري (الكل معاً، دون تداخل أوامر أي عميل آخر) — تعالج السيناريوهات حيث يجب أن تحدث عمليات متعددة كوحدة متسقة.
آلية WATCH توفر القفل المتفائل (التحقق والتعيين): إجهاض المعاملة إذا تغير مفتاح مراقب قبل EXEC، مما يتيح عمليات التحقق-ثم-التعديل الآمنة (مثل إنقاص رصيد بناءً على قيمته الحالية) مع إعادة المحاولة عند التضارب — مهم للعمليات المتزامنة الصحيحة.
النقطة الأكثر حرجة هي فهم كيفية اختلاف معاملات Redis عن معاملات SQL: Redis بدون تراجع — إذا فشلت أمرة في وقت EXEC، تنفذ الأوامر الأخرى بكل الأحوال (Redis لا تتراجع)، لذا "الذرية" هنا تعني الأوامر تعمل معاً دون تداخل (العزلة)، وليس كل أو لا شيء مع التراجع عند الخطأ.
sوء الفهم هذا (افتراض التراجع الشبيه بـ SQL) يؤدي إلى معالجة خطأ غير صحيحة.
معرفة أن سكريبتات Lua غالباً ما تُستخدم بدلاً منها للمنطق الذري المعقد (سكريبت ينفذ بشكل ذري كوحدة) مفيدة.
بما أن تنفيذ العمليات المتعددة المتسق والتزامن الصحيح احتياجات حقيقية، وبما أن معاملات Redis (MULTI/EXEC مع WATCH للقفل المتفائل) تعالجها لكن مع فروقات مهمة عن SQL (بدون تراجع) يجب فهمها، فهم معاملات Redis — MULTI/EXEC، القفل المتفائل القائم على WATCH، وخصوصاً التمييز بدون-تراجع عن SQL — معرفة قيمة وعملية لاستخدام Redis بصحة في السيناريوهات المتزامنة، حيث فهم الفروقات عن معاملات SQL المألوفة مهم مثل الآلية نفسها.