#performance

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

Pipeline trong Redis: cắt round-trip để throughput tăng 13 lần, và vì sao nút thắt là mạng chứ không phải Redis

Redis xử lý lệnh trong phần trăm mili-giây, nhưng nếu client gửi từng lệnh một và chờ reply, phần lớn thời gian là chờ mạng (round-trip) chứ không phải Redis làm việc. Pipeline gộp nhiều lệnh vào một lần gửi để cắt số round-trip. Bài này đo thật trong redis-lab: cùng một kết nối, SET đạt 333.889 lệnh/giây ở P=1 nhưng 4.444.444 lệnh/giây ở P=50 — nhanh ~13 lần. Và pipeline khác transaction thế nào.

#redis#performance#pipeline#latency#backend
38
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.

#redis#stampede#cache#performance#backend
42
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#lua#performance#rate-limiting#backend
28
Lập trình 22/09/2026 5 phút

Bộ nhớ và big key trong Redis: một key 34 MB có thể làm nghẽn cả server, và vì sao đừng bao giờ KEYS *

Redis chạy một luồng — nên một lệnh O(n) trên key khổng lồ chặn mọi client khác. Bài này đo thật trong redis-lab: một hash 500.000 field chiếm 34,5 MB; HGETALL trên nó mất 224ms (so với 1ms cho hash nhỏ) và suốt thời gian đó cả server khựng; và KEYS * quét toàn bộ keyspace O(n) chặn server, trong khi SCAN duyệt từng lô không block. Hiểu để một key hay một lệnh không kéo sập Redis.

#redis#performance#memory#backend#bigkey
36
Lập trình 22/09/2026 6 phút

Server streaming thực chiến: đo thật time-to-first-item nhanh hơn 9 lần so với unary

Server streaming có làm API nhanh hơn không? Có và không. Bài này đo thật: server tạo 10 item mỗi cái 50ms. Unary bắt client chờ 529ms mới nhận được gì; server streaming đẩy item đầu sau chỉ 58ms — nhanh hơn 9 lần về time-to-first-item. Nhưng tổng thời gian gần như bằng nhau (529 vs 533ms). Streaming không rút ngắn tổng — nó thắng ở độ trễ item đầu, bộ nhớ, và xử lý song song.

#golang#streaming#performance#grpc#backend
22
Lập trình 22/09/2026 7 phút

Vì sao cache: đo thật Redis nhanh hơn query database 30 đến 300 lần

Cache nghe như giải pháp vạn năng cho hiệu năng, nhưng nhanh hơn bao nhiêu và khi nào mới đáng? Bài này đo thật: một query gộp 100.000 dòng trên PostgreSQL tốn 8.2ms mỗi lần tính; cache kết quả vào Redis thì GET chỉ 0.028ms (pipelined) hoặc 0.26ms (round-trip đơn) — nhanh hơn 30 đến 300 lần. Nhưng nói thẳng: với query đơn giản lấy một dòng theo khoá chính, chênh lệch nhỏ hơn nhiều. Cache thắng rõ khi tính toán gốc đắt.

#redis#performance#caching#backend#postgresql
46