Backend 01/09/2026 8 phút

Nâng Redis 6.2 lên 7.4 không cần cửa sổ bảo trì: đúng một lệnh ghi thất bại trên 3.843 lần — nhưng vừa đổi vai trò xong là không còn đường lùi

Một quy trình nâng cấp không downtime, đo thật: dựng bản mới làm bản sao (đồng bộ 0,6 giây), đổi vai trò (0,12 giây), khách mất đúng một lệnh ghi và 0,03 giây gián đoạn. Nhưng khi thử đảo ngược — cho bản cũ làm bản sao của bản mới — bản 6.2 không đọc nổi định dạng RDB của 7.4, dbsize về 0. Đây là quyết định một chiều, và mọi kiểm tra phải xong trước bước không quay lại được.

Backend 01/09/2026 8 phút

Đặt volatile-lru khi không khoá nào có TTL chính là tắt hẳn việc dọn dẹp — Redis từ chối ghi trong khi 166.000 khoá bỏ được vẫn nằm nguyên trong RAM

Khi Redis chạm trần bộ nhớ, chính sách maxmemory quyết định nó dọn gì. Đo tám chính sách trên cùng một phép thử: volatile-lru với dữ liệu không TTL cho kết quả y hệt noeviction (0 khoá bị đuổi, 27.610 lỗi ghi) — cái bẫy dễ vấp nhất. Và LRU của Redis là gần đúng (lấy mẫu 5 khoá) nên chỉ giữ được 545/1000 khoá nóng, trong khi LFU giữ đủ 1.000/1.000 mà không cần chỉnh gì.

Backend 01/09/2026 8 phút

BLPOP nhận việc sau 0,3 mili giây, còn vòng lặp hỏi mỗi 100 ms mất 50,6 ms và tốn gấp 10 lần số lệnh — nhanh hơn 170 lần cho một dòng lệnh đổi tên

Dùng List làm hàng đợi là cách phổ biến nhất, và cách lấy việc ra quyết định gần như mọi thứ. Đo ba cách chờ: BLPOP nhận việc sau 0,3 ms với 0 lần thăm dò, còn vòng lặp hỏi mỗi 100 ms mất 50,6 ms (trung vị luôn xấp xỉ nửa chu kỳ) và gửi gấp 10 lần số lệnh cho không việc gì. Nhưng BLPOP vẫn mất việc khi tiến trình chết — BLMOVE sang danh sách 'đang xử lý' chỉ tốn thêm 9,5%, và đó là ranh giới nên chuyển sang Stream.

Backend 01/09/2026 8 phút

Tệp AOF của Redis lớn gấp 5,8 lần RDB nhưng nạp lại nhanh y hệt — lặp bốn lần vẫn vậy, và nó lật đổ lời khuyên 'AOF khôi phục chậm hơn nhiều'

Đặt RDB và AOF cạnh nhau trên cùng 2 triệu khoá rồi đo thứ quan trọng nhất — thời gian sống lại sau sự cố. AOF văn bản 270 MB so với RDB 47 MB, lớn gấp 5,8 lần, nhưng nạp lại trong 1,3–1,4 giây y như RDB, vì thời gian nạp bị chi phối bởi việc dựng 2 triệu mục bảng băm chứ không phải đọc byte. Nên lựa chọn không nằm ở tốc độ mà ở lượng dữ liệu mất: RDB mất tới một giờ, AOF everysec mất một giây.

Backend 01/09/2026 8 phút

Cùng một chuỗi 1024 byte tốn 1.328 hay 2.608 byte tuỳ cách bạn ghi nó vào Redis — chênh 96% mà không đổi một ký tự dữ liệu

Đào vào con số 185 byte cho mỗi khoá chứa 100 byte dữ liệu, và tìm ra ba cách ghi cùng một chuỗi cho ba lượng bộ nhớ khác nhau. Phụ trội cố định ~64 byte mỗi khoá; một khoá 8 byte dữ liệu tốn 72 byte, gấp 9 lần. Ranh giới 44 byte đổi embstr sang raw. Và dựng chuỗi bằng APPEND chiếm gần gấp đôi vì Redis cấp phát tăng gấp bội. FLUSHALL cũng không trả RAM về hệ điều hành.

Backend 01/09/2026 8 phút

Đếm một triệu phần tử khác nhau bằng 14.384 byte với sai số 0,12% — và HyperLogLog còn ghi nhanh hơn Set 1,6 lần vì nó không lưu phần tử nào

Hai kiểu dữ liệu ít dùng nhất của Redis cũng là hai kiểu tiết kiệm nhất. Đo cả bộ nhớ lẫn sai số: HyperLogLog đếm một triệu phần tử khác nhau trong 14.384 byte cố định (nhỏ hơn Set 3.364 lần) với sai số dưới 0,5%, và PFADD nhanh hơn SADD vì nó băm rồi vứt, không cấp phát. Bitmap nhỏ hơn Set 35 lần nhưng có bẫy: bộ nhớ phụ thuộc chỉ số bit lớn nhất, không phụ thuộc số bit đã đặt.