#hieu-nang

370 bài viết
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
14
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
13
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
15
Backend 01/09/2026 8 phút

Giết máy chính Redis giữa 2,7 triệu lệnh ghi: mất 0 — nhưng để bản sao chậm lại một chút rồi mới giết: mất 79%; 'bất đồng bộ' không có nghĩa 'mất một ít'

Sao chép của Redis là bất đồng bộ, và mọi tài liệu đều cảnh báo điều đó nghĩa là mất dữ liệu. Đo thật: liên kết khoẻ thì giết máy chính giữa 2,78 triệu lệnh vẫn mất đúng 0; nhưng cho bản sao chậm lại trước khi giết thì mất 79.592 trên 100.719 lệnh — gần bốn phần năm. Lượng mất không phải 'vài lệnh cuối', nó bằng ĐÚNG khoảng cách bản sao đang chậm ngay lúc đó. WAIT thu hẹp khoảng đó nhưng chậm 25 lần.

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

Một khách Redis Cluster không giữ bản đồ slot chạy chậm 1,63 lần vì 67% lệnh bị đá sang nút khác — và cái giá thật của Cluster không phải tốc độ, mà là MGET ngừng hoạt động

Sentinel cho chịu lỗi nhưng dữ liệu vẫn nằm một máy; Cluster chia ra nhiều máy và lấy đi vài thứ. Dựng cụm sáu nút rồi đo: khách tự tính CRC16 gọi thẳng đúng nút đạt 16.907 ops/s với 0 lần MOVED, còn khách 'ngây thơ' chỉ 10.390 ops/s vì 67% lệnh bị chuyển hướng. Nhưng mất mát lớn nhất không đo bằng ops/s: MGET, MSET, Lua, MULTI đều chết với CROSSSLOT khi khoá nằm khác slot. Cái Cluster lấy đi là khả năng diễn đạt.

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

Cửa sổ cố định cho 200 yêu cầu lọt qua trong 0,3 giây dù giới hạn là 100/giây — và cách đếm chính xác tuyệt đối ngốn gấp 1.646 lần bộ nhớ để sửa đúng 2% sai số

Giới hạn tần suất là ứng dụng phổ biến thứ hai của Redis sau cache. Cài bốn thuật toán bằng Lua rồi đo cả tốc độ, bộ nhớ lẫn độ chính xác: cửa sổ cố định đơn giản nhất nhưng để lọt gấp đôi ở ranh giới; nhật ký trượt chính xác tuyệt đối nhưng tốn 88 GB nơi cửa sổ trượt chỉ tốn 53 MB với sai số 2%. Bài học là chọn xấp xỉ đủ tốt, không đuổi theo chính xác tuyệt đối.

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