Bagaimana transaksi Redis bekerja?

Question

Accepted Answer

Redis **transactions** (via `MULTI`/`EXEC`) mengelompokkan beberapa perintah untuk dijalankan **secara atomik** — semuanya bersama-sama tanpa perintah lain yang saling menyela. Dikombinasikan dengan `WATCH` untuk optimistic locking, mereka menangani skenario yang memerlukan beberapa operasi agar konsisten. Transaksi Redis berbeda dari transaksi SQL dengan cara yang penting.

## MULTI / EXEC — antrian dan eksekusi atomik

```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` mulai antrian perintah; `EXEC` menjalankan semuanya secara atomik (tanpa saling menyela dari klien lain). `DISCARD` membatalkan transaksi yang antri.

## 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` menyediakan **optimistic locking**: jika kunci yang diawasi diubah oleh klien lain sebelum `EXEC`, transaksi dibatalkan — memungkinkan Anda melakukan operasi check-then-set dengan aman (ulangi saat ada konflik).

## Bagaimana transaksi Redis BERBEDA dari 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).
```

## Mengapa ini penting

Memahami transaksi Redis sangat berharga untuk **melakukan beberapa operasi secara konsisten**, jadi pengetahuan ini berguna — dan memahami bagaimana mereka berbeda dari transaksi SQL sangat penting untuk menghindari asumsi yang salah.

Kemampuan inti — pengelompokan perintah `MULTI`/`EXEC` untuk **dijalankan secara atomik** (semuanya bersama, tanpa perintah klien lain yang saling menyela) — mengatasi skenario di mana beberapa operasi harus terjadi sebagai satu unit yang konsisten.

Mekanisme **`WATCH`** menyediakan **optimistic locking** (check-and-set): membatalkan transaksi jika kunci yang diawasi berubah sebelum `EXEC`, memungkinkan operasi check-then-modify yang aman (seperti mengurangi saldo berdasarkan nilai saat ini) dengan ulangi saat ada konflik — penting untuk operasi bersamaan yang benar.

Poin **paling kritis** adalah memahami bagaimana transaksi Redis **berbeda dari transaksi SQL**: Redis **tidak memiliki rollback** — jika perintah gagal pada waktu `EXEC`, perintah lain tetap dijalankan (Redis tidak membatalkan), jadi "atomisitas" di sini berarti perintah berjalan bersama tanpa saling menyela (isolasi), BUKAN semua-atau-tidak-sama-sekali dengan rollback kesalahan.

Salah memahami ini (mengasumsikan rollback seperti SQL) menyebabkan penanganan kesalahan yang tidak benar.

Mengetahui bahwa **Lua scripts** sering digunakan sebagai gantinya untuk logika atomik yang kompleks (skrip dijalankan secara atomik sebagai satu unit) sangat berharga.

Karena eksekusi multi-operasi yang konsisten dan concurrency yang benar adalah kebutuhan nyata, dan karena transaksi Redis (MULTI/EXEC dengan WATCH untuk optimistic locking) mengatasi hal tersebut tetapi dengan perbedaan penting dari SQL (tidak ada rollback) yang harus dipahami, memahami transaksi Redis — MULTI/EXEC, optimistic locking berbasis WATCH, dan terutama perbedaan no-rollback dari SQL — adalah pengetahuan praktis dan relevan untuk menggunakan Redis dengan benar dalam skenario bersamaan, di mana memahami perbedaan dari transaksi SQL yang sudah dikenal sama pentingnya dengan mekanisme itu sendiri.