Lập trình

Theo dõi riêng chuyên mục này 150 bài viết
Lập trình 22/09/2026 5 phút

Xử lý lỗi trong gRPC: status code chuẩn và rich error details — để client xử lý đúng thay vì đoán chuỗi

Trả lỗi bằng một chuỗi text buộc client phải đoán và regex — mong manh và dễ vỡ. gRPC có bộ status code chuẩn hoá (NotFound, InvalidArgument, Unavailable...) để client rẽ nhánh đúng, và rich error details để gửi lỗi CÓ CẤU TRÚC. Bài này đo thật trong go-lab: Get id không tồn tại trả NotFound, id âm trả InvalidArgument; và Create với input xấu trả về danh sách field vi phạm (email, age) để client đọc type-safe thay vì parse câu lỗi.

#grpc#status-code#backend#go#error-handling
2
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#streams#backend#messaging#redis
2
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.

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

#lua#distributed-lock#backend#redis#concurrency
2
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#rate-limiting#performance#backend#redis
1
Lập trình 22/09/2026 5 phút

Persistence trong Redis: RDB và AOF — Redis có mất dữ liệu khi chết không, và đánh đổi độ bền vs hiệu năng

Redis sống trong RAM, nên câu hỏi sống còn: tắt đi có mất dữ liệu không? Redis có hai cơ chế ghi xuống đĩa với hai triết lý khác nhau. Bài này đo thật trong redis-lab: RDB snapshot (BGSAVE tạo dump.rdb nhỏ gọn, nhưng mất dữ liệu giữa hai lần chụp); AOF ghi mọi lệnh với appendfsync everysec (bền hơn, mất tối đa 1 giây, file lớn hơn). Cùng 1000 key, RDB 16.881 byte vs AOF 21.161 byte. Chọn đúng theo vai trò cache hay store.

#aof#persistence#rdb#backend#redis
1