Redis transactions કેવી રીતે કામ કરે છે?

Question

Accepted Answer

Redis **transactions** (`MULTI`/`EXEC` દ્વારા) બહુવિધ આદેશોને **atomically** એક્સીક્યુટ કરવા માટે જૂથબદ્ધ કરે છે — બધા એક સાથે અન્ય આદેશોની દખલ વિના. `WATCH` સાથે optimistic locking માટે સંયુક્ત, તેઓ બહુવિધ ઑપરેશનને સુસંગત હોવું જરૂરી હોય તેવા scenarios હેન્ડલ કરે છે. Redis transactions SQL transactions થી મહત્વપૂર્ણ રીતે અલગ છે.

## MULTI / EXEC — queuing અને atomic execution

```bash
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` આદેશોને queue કરવાનું શરૂ કરે છે; `EXEC` તે બધાને atomically ચલાવે છે (અન્ય ક્લાયન્ટ્સ તરફથી કોઈ ઇન્ટરલીવિંગ નથી). `DISCARD` queued transaction રદ કરે છે.

## WATCH — optimistic locking (check-and-set)

```bash
# 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** આપે છે: જો કોઈ અન્ય ક્લાયન્ટ દ્વારા `EXEC` પહેલાં watched key સંશોધિત થાય તો, transaction abort થાય છે — તમને safely check-then-set ઑપરેશન કરવા દે છે (conflict પર retry કરો).

## Redis transactions SQL થી કેવી રીતે અલગ છે

```text
⚠️ 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 સમજવું **બહુવિધ ઑપરેશન સુસંગતપણે પરફોર્મ કરવા** માટે મૂલ્યવાન છે, તેથી તે ઉપયોગી જ્ઞાન છે — અને તેઓ SQL transactions થી કેવી રીતે અલગ છે તે સમજવું ખાસ કરીને અયોગ્ય ધારણાઓ ટાળવા માટે મહત્વપૂર્ણ છે.

મૂલ ક્ષમતા — `MULTI`/`EXEC` આદેશોને **atomically** એક્સીક્યુટ કરવા માટે જૂથબદ્ધ કરવું (બધા એક સાથે, અન્ય ક્લાયન્ટના આદેશોની કોઈ ઇન્ટરલીવિંગ વિના) — તે scenarios સંબોધે છે જ્યાં બહુવિધ ઑપરેશન consistent unit તરીકે થવું જોઈએ.

**`WATCH`** મિકેનિজમ **optimistic locking** આપે છે (check-and-set): જો `EXEC` પહેલાં watched key બદલાયુ તો transaction abort કરીને, safe check-then-modify ઑપરેશન (જેમ કે તેની વર્તમાન કિંમતના આધારે balance ઘટાડવું) સક્ષમ કરે છે conflict પર retry સાથે — સાચી concurrent ઑપરેશનો માટે મહત્વપૂર્ણ.

**સૌથી મહત્વની બાબત** એ સમજવું છે કે Redis transactions SQL transactions **થી અલગ** કેવી રીતે છે: Redis **કોઈ rollback નથી** — જો `EXEC` સમયે આદેશ નિષ્ફળ જાય, અન્ય આદેશો તો અલીકતે એક્સીક્યુટ થાય છે (Redis ઉલટો નથી કરે), તેથી અહીં "atomicity" નો અર્થ એ છે કે આદેશો ઇન્ટરલીવિંગ વિના એક સાથે ચલાય છે (isolation), તમામ-અથવા-કંઈ નથી rollback સાથે.

આનું ગેસ લગાવવું (SQL જેવું rollback ધારવું) ખોટી ભૂલ હેન્ડલીંગ તરફ દોરી જાય છે.

જાણવું કે **Lua scripts** ક્ષણે સંકેત આમણે જટિલ atomic logic માટે વપરાય છે (એક script atomically એક unit તરીકે એક્સીક્યુટ થાય છે) તે મૂલ્યવાન છે.

મહત્ત્વપૂર્ણ multi-operation execution અને સાચી concurrency વાસ્તવિક જરૂરિયાતો હોવાથી, અને Redis transactions (optimistic locking માટે MULTI/EXEC WATCH સાથે) તેમને સંબોધે છે પણ SQL (rollback નથી) તથી મહત્વપૂર્ણ તફાવત સાથે જે સમજવું જોઈએ, Redis transactions સમજવું — MULTI/EXEC, WATCH-based optimistic locking, અને ખાસ કરીને SQL તથી no-rollback તફાવત — એ મૂલ્યવાન, વ્યવહારિક રીતે સંબંધિત જ્ઞાન છે Redis ને concurrent scenarios માં સાચીથી વાપરવા માટે, જ્યાં પરિચિત SQL transactions તથી તફાવતો સમજવું મિકેનિજમ જ જેટલું મહત્વપૂર્ણ છે.