#lua

3 bài viết
Lập trình 22/09/2026 6 phút

Transaction và Lua trong Redis: ba cách làm nhiều lệnh nguyên tử, và vì sao Lua mạnh hơn MULTI

Khi nhiều client cùng trừ tồn kho hay cùng trừ tiền, race condition làm hỏng dữ liệu. Redis có ba công cụ đảm bảo nguyên tử. Bài này đo thật trong redis-lab: MULTI/EXEC chạy cả khối lệnh liền nhau; WATCH huỷ transaction khi key bị client khác đổi (bal=999 chứ không phải 949, chứng minh DECRBY bị huỷ); và script Lua trừ tồn kho CHỈ KHI đủ — đọc-kiểm-ghi chạy nguyên tử trong một EVAL, thứ MULTI không làm được vì không rẽ nhánh.

#redis#backend#lua#concurrency#transaction
1
Lập trình 22/09/2026 6 phút

Distributed lock với Redis: SET NX PX, và vì sao nhả lock bằng DEL là một lỗi nguy hiểm

Khoá phân tán để chỉ một tiến trình làm một việc tại một thời điểm trên nhiều máy — nghe đơn giản nhưng viết sai một chút là hỏng dữ liệu. Bài này đo thật trong redis-lab: SET NX PX cho client A giành lock, B thất bại (nil) khi A đang giữ; và quan trọng nhất, nhả lock phải dùng token duy nhất + Lua — demo B nhả với token sai trả 0 (không phá lock của A), A nhả với token đúng trả 1. Hiểu vì sao DEL mù quáng xoá nhầm lock người khác.

#redis#backend#lua#concurrency#distributed-lock
1
Lập trình 22/09/2026 6 phút

Rate limiting với Redis: fixed window, sliding window và token bucket — ba thuật toán, ba mức mượt

Giới hạn số request để chống lạm dụng là bài toán backend kinh điển, và Redis là công cụ lý tưởng nhờ các thao tác nguyên tử. Bài này đo thật trong redis-lab ba thuật toán: fixed window (INCR+EXPIRE, đơn giản nhưng burst ở ranh giới), sliding window (sorted set theo timestamp, mượt hơn, không burst), và token bucket (cho phép burst có kiểm soát). Với limit 5, cả hai đều cho 5 request qua và chặn request 6-7 — nhưng khác nhau ở độ chính xác quanh ranh giới cửa sổ.

#redis#backend#lua#rate-limiting#performance
1