Transaction của Redis (qua MULTI/EXEC) gom nhiều lệnh để thực thi nguyên tử — tất cả cùng nhau mà không có lệnh khác xen vào. Kết hợp với WATCH cho optimistic locking, chúng xử lý các tình huống cần nhiều thao tác phải nhất quán. Transaction của Redis khác với transaction SQL ở những điểm quan trọng.
MULTI # bắt đầu một transaction (bắt đầu xếp hàng lệnh)
SET account:1 100 # ĐÃ XẾP HÀNG (chưa thực thi)
SET account:2 200 # ĐÃ XẾP HÀNG
INCR counter # ĐÃ XẾP HÀNG
EXEC # thực thi TẤT CẢ lệnh đã xếp hàng một cách nguyên tử (như một khối)
# → tất cả lệnh chạy cùng nhau, KHÔNG có lệnh của client khác chen vào
MULTI bắt đầu xếp hàng lệnh; EXEC chạy tất cả chúng nguyên tử (không có lệnh từ client khác xen vào). DISCARD hủy một transaction đã xếp hàng.
# WATCH một key; nếu nó THAY ĐỔI trước EXEC, transaction HỦY BỎ (trả về nil)
WATCH balance
val = GET balance # đọc giá trị hiện tại
MULTI
SET balance (val - 100) # sửa dựa trên những gì ta đọc
EXEC # → nếu "balance" thay đổi kể từ WATCH, EXEC thất bại (trả về nil)
# → thử lại toàn bộ nếu thất bại (optimistic concurrency control)
WATCH cung cấp optimistic locking: nếu một key được watch bị sửa bởi client khác trước EXEC, transaction hủy bỏ — cho phép bạn an toàn thực hiện các thao tác check-then-set (thử lại khi xung đột).
⚠️ 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).
Hiểu transaction của Redis là giá trị để thực hiện nhiều thao tác một cách nhất quán, nên đó là kiến thức hữu ích — và hiểu chúng khác với transaction SQL như thế nào đặc biệt quan trọng để tránh các giả định sai.
Khả năng cốt lõi — MULTI/EXEC gom các lệnh để thực thi nguyên tử (tất cả cùng nhau, không có lệnh của client khác xen vào) — giải quyết các tình huống nơi nhiều thao tác phải xảy ra như một khối nhất quán.
Cơ chế WATCH cung cấp optimistic locking (check-and-set): hủy transaction nếu một key được watch thay đổi trước EXEC, cho phép các thao tác check-then-modify an toàn (như giảm số dư dựa trên giá trị hiện tại của nó) với thử lại khi xung đột — quan trọng cho các thao tác đồng thời đúng. Điểm quan trọng nhất là hiểu transaction Redis khác transaction SQL như thế nào: Redis không có rollback — nếu một lệnh thất bại tại thời điểm EXEC, các lệnh khác vẫn thực thi (Redis không hoàn tác), nên "tính nguyên tử" ở đây nghĩa là các lệnh chạy cùng nhau mà không xen vào (isolation), KHÔNG phải all-or-nothing với rollback khi lỗi.
Hiểu sai điều này (giả định có rollback giống SQL) dẫn đến xử lý lỗi sai.
Biết rằng Lua script thường được dùng thay thế cho logic nguyên tử phức tạp (một script thực thi nguyên tử như một khối) là giá trị.
Vì thực thi nhiều thao tác nhất quán và concurrency đúng là nhu cầu thực tế, và vì transaction Redis (MULTI/EXEC với WATCH cho optimistic locking) giải quyết chúng nhưng với các khác biệt quan trọng so với SQL (không rollback) phải hiểu, hiểu transaction Redis — MULTI/EXEC, optimistic locking dựa trên WATCH, và đặc biệt là phân biệt không-rollback so với SQL — là kiến thức giá trị, có liên quan về mặt thực hành để dùng Redis đúng trong các tình huống đồng thời, nơi hiểu các khác biệt so với transaction SQL quen thuộc cũng quan trọng như chính cơ chế.