Redis transactions ทำงานอย่างไร?

Question

Accepted Answer

Redis **transactions** (ผ่าน `MULTI`/`EXEC`) จัดกลุ่มหลายคำสั่งให้ทำงาน **แบบ atomic** — ทั้งหมดพร้อมกันโดยไม่มีคำสั่งอื่นแทรก เมื่อรวมกับ `WATCH` สำหรับ optimistic locking มันจัดการสถานการณ์ที่ต้องการให้หลายการดำเนินการสอดคล้องกัน Redis transactions แตกต่างจาก SQL transactions ในแง่ที่สำคัญ

## MULTI / EXEC — การ queue และการทำงานแบบ atomic

```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` รันทั้งหมดแบบ atomic (ไม่มีการแทรกจาก client อื่น) ส่วน `DISCARD` ยกเลิก transaction ที่ queue ไว้

## 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**: หาก key ที่ watch อยู่ถูกแก้ไขโดย client อื่นก่อน `EXEC` transaction จะ abort — ทำให้คุณทำการดำเนินการ check-then-set ได้อย่างปลอดภัย (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` จัดกลุ่มคำสั่งให้ **ทำงานแบบ atomic** (ทั้งหมดพร้อมกัน โดยไม่มีคำสั่งของ client อื่นแทรก) — ตอบโจทย์สถานการณ์ที่หลายการดำเนินการต้องเกิดขึ้นเป็นหน่วยเดียวที่สอดคล้องกัน

กลไก **`WATCH`** มอบ **optimistic locking** (check-and-set): abort transaction หาก key ที่ watch ถูกเปลี่ยนก่อน `EXEC` ทำให้ทำการดำเนินการ check-then-modify ได้อย่างปลอดภัย (เช่น การลดยอด balance ตามค่าปัจจุบัน) พร้อม retry เมื่อเกิดความขัดแย้ง — สำคัญต่อการดำเนินการพร้อมกันอย่างถูกต้อง

**ประเด็นที่สำคัญที่สุด** คือการเข้าใจว่า Redis transactions **แตกต่างจาก SQL transactions** อย่างไร: Redis **ไม่มี rollback** — หากคำสั่งหนึ่งล้มเหลวตอน `EXEC` คำสั่งอื่นยังคงทำงาน (Redis ไม่ undo) ดังนั้น "atomicity" ในที่นี้หมายถึงคำสั่งทำงานพร้อมกันโดยไม่มีการแทรก (isolation) ไม่ใช่ all-or-nothing พร้อม rollback เมื่อเกิด error

การเข้าใจผิดในเรื่องนี้ (สมมติว่ามี rollback แบบ SQL) นำไปสู่การจัดการ error ที่ไม่ถูกต้อง

การรู้ว่า **Lua scripts** มักถูกใช้แทนสำหรับ logic atomic ที่ซับซ้อน (สคริปต์ทำงานแบบ atomic เป็นหน่วยเดียว) มีคุณค่า

เนื่องจากการทำหลายการดำเนินการอย่างสอดคล้องและความถูกต้องของ concurrency เป็นความต้องการจริง และเนื่องจาก Redis transactions (MULTI/EXEC พร้อม WATCH สำหรับ optimistic locking) ตอบโจทย์เหล่านั้นแต่มีความแตกต่างที่สำคัญจาก SQL (ไม่มี rollback) ที่ต้องเข้าใจ การเข้าใจ Redis transactions — MULTI/EXEC, optimistic locking ที่อิง WATCH และโดยเฉพาะความแตกต่างเรื่องไม่มี rollback จาก SQL — จึงเป็นความรู้ที่มีคุณค่าและเกี่ยวข้องเชิงปฏิบัติสำหรับการใช้ Redis อย่างถูกต้องในสถานการณ์ concurrency ที่การเข้าใจความแตกต่างจาก SQL transactions ที่คุ้นเคยสำคัญพอ ๆ กับตัวกลไกเอง