#redis

63 bài viết
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.

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

Sentinel công bố máy chính Redis mới sau 4,50 giây — nhưng khách hàng của bạn thấy hệ thống chết 6,27 giây, và khoảng chênh đó là con số duy nhất đáng đưa vào SLA

Sao chép giữ dữ liệu tốt cho tới khi máy chính chết và không ai thay nó — Sentinel làm việc thay đó. Đo thật một lần chuyển đổi: Sentinel công bố máy chính mới sau 4,50 giây (≈ down-after + 1,5 giây), nhưng khách hàng ghi liên tục thấy gián đoạn 6,27 giây vì còn phải nhận ra kết nối chết, hỏi lại địa chỉ, nối lại. Vì sao cần ba Sentinel ở ba vùng hỏng, và cái Sentinel không cứu được.

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

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

Công thức khoá phân tán 'SET NX PX' được chép nhiều nhất Internet — và 50 trên 50 lần nó âm thầm mất khoá giữa chừng, để ba tiến trình cùng ghi vào một chỗ mà không ai biết

SET key value NX PX 30000 là công thức khoá phân tán ai cũng chép. Đo thật xem nó bảo đảm gì và ngừng bảo đảm ở đâu: khi công việc ngắn hơn TTL, nó chặn sạch 599 lần đua về 0; nhưng khi công việc dài hơn TTL, 50/50 lần lấy khoá đều mất khoá trước khi xong, ba tiến trình cùng vào vùng cấm mà không lỗi nào hiện ra. Redlock không cứu được — vấn đề nằm ở đồng hồ, không ở số lượng Redis.

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

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

Thêm một dòng CREATE INDEX làm truy vấn nhanh hơn 181 lần — tốt hơn cả tỉ lệ trúng cache 99%, và không thêm một hệ thống nào để hỏng

Cache-aside là mẫu dùng Redis phổ biến nhất, nhưng đo thật cho thấy nó thắng ít hơn ta tưởng. Tra khoá chính: Redis GET 0,062 ms ngang PostgreSQL 0,065 ms — đặt cache ở đây chỉ thêm một chỗ để hỏng. Truy vấn đắt 19,9 ms: cache nhanh hơn 321 lần, nhưng một CREATE INDEX kéo nó xuống 0,110 ms — nhanh hơn 181 lần, tốt hơn cả cache trúng 99%. Bộ đệm che một truy vấn chậm; chỉ mục xoá nó.

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