#redis

63 bài viết
Backend 01/09/2026 8 phút

Khởi động lại Redis: script Lua biến mất sạch, còn Function vẫn nguyên vẹn và chạy được ngay — nhưng tốc độ hai bên giống hệt nhau, vì cùng một máy Lua

Redis 7 thêm Functions, và câu hỏi đầu tiên ai cũng hỏi là 'khác gì Lua script'. Đo cả hai trên cùng logic: sau khi khởi động lại, EVALSHA trả NOSCRIPT còn FCALL chạy bình thường — vì function nằm trong chính dữ liệu, đi theo RDB/AOF/bản sao, còn script chỉ nằm trong bộ nhớ tạm. Nhưng FCALL 20.520 ops/s so EVALSHA 20.256, chênh trong nhiễu: đừng chuyển vì hiệu năng, chuyển vì vận hành — cờ no-writes được thi hành thật, tên có nghĩa thay mã băm, và mã đi theo quy trình triển khai.

#zero-to-hero#redis
14
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.

#zero-to-hero#redis
15
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.

#zero-to-hero#redis#hieu-nang
10
Backend 01/09/2026 8 phút

Ghi đè 7 triệu khoá trong lúc Redis đang chụp ảnh bộ nhớ làm chi phí copy-on-write nhảy từ 1,4 MB lên 87 MB — và INFO memory không hề thấy một byte nào trong đó

RDB chụp toàn bộ bộ nhớ Redis ra một tệp. Đo thật: BGSAVE 2 triệu khoá xong trong 1,21 giây, tệp nén 7,2 lần nhỏ hơn bộ nhớ, khách gần như không thấy độ trễ nhờ fork. Nhưng chi phí thật nằm ở copy-on-write: không ghi gì thì tốn 1,4 MB, ghi đè 7 triệu khoá lúc đang chụp thì tốn 87 MB — gấp 64 lần — và used_memory_rss của Redis đứng im vì các trang bị sao chép thuộc về tiến trình con. Đây là nguồn gốc lời khuyên 'chỉ dùng 50% RAM cho Redis'.

#zero-to-hero#redis#hieu-nang
15
Backend 01/09/2026 8 phút

Giết Redis bằng SIGKILL với appendfsync=no — mất đúng 0 bản ghi, lặp ba lần vẫn vậy; vì tiến trình chết không phải mất điện, và người ta hay nhầm hai thứ đó

AOF ghi từng lệnh vào tệp thay vì chụp ảnh định kỳ, với ba chế độ appendfsync ai cũng gọi là nhanh/cân bằng/an toàn. Đo cả tốc độ lẫn lượng mất thật: no và everysec nhanh ngang nhau, always chậm 12,5 lần khi gọi từng lệnh nhưng chỉ 4,8 lần khi có đường ống. Bất ngờ lớn nhất: SIGKILL Redis với appendfsync=no vẫn mất 0 — vì write() đã vào bộ đệm kernel, và giết tiến trình không xoá được nó. appendfsync chỉ quyết định chuyện gì xảy ra khi mất điện.

#zero-to-hero#redis#hieu-nang
15
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.

#zero-to-hero#redis#hieu-nang
17