#backend

57 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.

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

TTL và eviction trong Redis: key tự hết hạn, và vì sao chọn sai chính sách khi đầy bộ nhớ làm hỏng cả hệ thống

Redis sống trong RAM có hạn — hai cơ chế quyết định số phận key: TTL (tự hết hạn) và eviction (đẩy key ra khi đầy). Bài này đo thật trong redis-lab: key đặt PX 150ms tự biến mất sau đó (GET trả nil); và với maxmemory 3mb, nạp 100.000 key — chính sách allkeys-lru đẩy 89.992 key để ghi vẫn thành công (bộ nhớ giữ đúng 3.00M), còn noeviction từ chối ghi với lỗi OOM. Chọn chính sách theo vai trò Redis.

#ttl#eviction#memory#redis#backend
1
Lập trình 22/09/2026 6 phút

Pub/Sub và Streams trong Redis: hai cách nhắn tin dễ nhầm, khác nhau căn bản ở chỗ giữ hay vứt message

Redis có hai cơ chế nhắn tin trông giống nhau nhưng khác nhau một trời một vực. Pub/Sub là loa phát thanh — ai đang nghe thì nghe, phát trước khi ai subscribe là mất luôn. Streams là sổ ghi bền — lưu lại, đọc lại, phát lại, có consumer group chia việc như Kafka thu nhỏ. Bài này đo thật trong redis-lab: PUBLISH khi không subscriber trả về 0 (mất), XADD rồi XRANGE đọc lại được, và consumer group chia entry cho c1/c2 với XACK theo dõi.

#pubsub#messaging#streams#redis#backend
1
Lập trình 22/09/2026 6 phút

Cache-aside và cache stampede: khi một key nóng hết hạn, 20 request cùng đập database — và cách chặn bằng một lock

Cache-aside là pattern cache phổ biến nhất, nhưng nó có một lỗ hổng chết người: khi một key nóng hết hạn, mọi request đến cùng lúc đều miss và cùng đập vào database — cache stampede. Bài này đo thật trong redis-lab: cache HIT 1ms vs MISS 204ms; 20 client đồng thời khi key vắng gây 20 lần query DB; thêm một lock SET NX, số query DB giảm còn đúng 1. Hiểu để một đợt key hết hạn không kéo sập database.

#cache#stampede#performance#redis#backend
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.

#concurrency#distributed-lock#lua#redis#backend
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ổ.

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