Backend 01/09/2026 8 phút

50 bản tin Redis Pub/Sub gửi trong lúc thuê bao mất kết nối: nhận lại được đúng 0 — nó là đài phát thanh, không phải hộp thư, và người ta cứ nhầm hai thứ đó

Pub/Sub là tính năng hay bị dùng sai nhất của Redis vì nó trông giống một hàng đợi. Đo ba tình huống chứng minh nó không phải: bản tin gửi khi chưa ai nghe mất sạch, gửi trong lúc thuê bao ngắt kết nối cũng mất sạch (0/50), và thuê bao đọc chậm bị Redis đóng kết nối sau khi bộ đệm chạm 32 MB. PUBLISH cũng chậm 6 lần khi lên 10 thuê bao vì phải ghi vào bộ đệm từng người trên luồng duy nhất.

Backend 01/09/2026 8 phút

Một tiêu thụ Redis Stream quên gọi XACK thổi 1,4 MB thành 28 MB — gấp 19,7 lần — và XTRIM cắt stream không cứu được một byte

List làm hàng đợi được và nhiều hệ thống dùng nó. Đo xem Stream cho thêm gì: nó gọn hơn List 24% dù mang thêm id, và khác biệt thật là khi tiến trình chết — bản tin ở lại danh sách chờ tới khi có ai XACK, còn List thì mất dấu. Nhưng danh sách chờ là cái bẫy: quên XACK làm bộ nhớ phình 19,7 lần, và XTRIM không cứu được vì chỗ tốn nằm ở pending, không ở stream. Giám sát XPENDING, không chỉ XLEN.

Backend 01/09/2026 8 phút

Một lệnh GET khiến khách chờ 3.335,8 ms không hề xuất hiện trong slowlog của Redis — nó chỉ ghi thời gian chạy, không ghi thời gian nằm chờ trong hàng

SLOWLOG là công cụ chẩn đoán tốt nhất của Redis, nhưng nó đo thời gian một lệnh CHẠY, không đo thời gian nó xếp hàng. Đo thật: một EVAL chạy 3 giây làm một GET mất 3,3 giây từ phía khách — và slowlog chỉ ghi EVAL, GET biến mất. SLOWLOG cho biết ai gây nghẽn, không cho biết ai bị nghẽn; muốn thấy phía nạn nhân phải đo ở khách hàng.

Backend 01/09/2026 7 phút

Một tập 512 số nguyên trong Redis tốn 2,6 byte mỗi số — thêm đúng một phần tử nữa là nhảy lên 48,2 byte, gấp 18,6 lần

Đo bốn kiểu tập hợp của Redis và tìm ra ba vách đá bộ nhớ rơi ở đúng một phần tử. Gom nhiều giá trị vào một Hash/Set rẻ hơn nhiều khoá riêng 2,3–2,8 lần vì phụ trội 64 byte mỗi khoá biến mất. Nhưng vượt ngưỡng listpack/intset là bộ nhớ mỗi phần tử nhảy 2,3–18,6 lần chỉ vì một phần tử. Và LINDEX có hình chữ V: chậm nhất ở giữa list, không phải ở cuối.

Backend 01/09/2026 8 phút

Một kết nối Redis duy nhất nhảy từ 25.850 lên 1.136.364 lệnh/giây mà không đổi một dòng cấu hình — vì nút thắt chưa bao giờ là CPU, mà là lượt đi về

Redis xử lý lệnh bằng một luồng duy nhất, nghe như lãng phí trên máy 16 nhân. Đo thật cho thấy nút thắt nằm ở chỗ khác: một luồng vẫn tăng gần tuyến tính tới 8 kết nối, và một kết nối đơn dùng đường ống 64 đạt 1,1 triệu lệnh/giây — gấp 44 lần cùng kết nối đó không đường ống. Không đường ống, Redis không dùng hết nổi một nhân vì phần lớn thời gian nằm trong lời gọi đọc/ghi socket, mỗi lời gọi mang đúng một lệnh.

Backend 01/09/2026 8 phút

Bật TLS cho Redis chậm hơn 11,5% khi gọi từng lệnh — nhưng gộp thành đường ống thì nhanh bằng bản không mã hoá; cái giá thật nằm ở chỗ khác: 40% CPU

Redis mặc định không mật khẩu, không mã hoá, ai cũng làm được mọi thứ. Đo hai lớp bảo vệ và cái giá thật của từng lớp: ACL gần như miễn phí và chặn được lớp lỗi lớn nhất; còn TLS thì bất ngờ — chi phí mã hoá tính trên bản ghi chứ không trên lệnh, nên đường ống 100 lệnh làm nó gần như biến mất (477.027 so với 461.274/giây), nhưng CPU máy chủ vẫn nhảy từ 38,71% lên 54,26% cho cùng một lượng việc.