Lưu trữ — Tháng 9/2026

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

#zero-to-hero#redis
21
Backend 01/09/2026 8 phút

Một Lua script chạy 3 giây trên Redis bắt mọi khách hàng khác chờ đúng 2.951,6 ms — vì tính nguyên tử bạn nhận được CHÍNH LÀ thời gian chặn mọi người phải chịu

Lua cho bạn tính nguyên tử mà MULTI không cho: đọc một giá trị rồi quyết định dựa trên nó. Đo cái giá: script chạy 3,02 giây thì PING của khách khác chạm 2.951,6 ms — độ chặn gần đúng bằng thời gian chạy, không nhường luồng. Vòng lặp vô hạn không làm máy chủ chết (BUSY sau 5 giây, cứu bằng SCRIPT KILL) nhưng script đã ghi thì không giết được. EVALSHA nhanh hơn EVAL 27%, và cache script sinh động rò 340 MB không ai dọn.

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

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

Đọc giá trị 10 MB từ Redis chỉ chậm hơn 1 KB đúng 3,5 mili giây — nhưng 20 khách đọc chậm cùng lúc thổi 10 MB dữ liệu thành 200 MB bộ nhớ mà maxmemory không hề hay biết

'Đừng lưu giá trị lớn trong Redis' là lời khuyên phổ biến, nhưng vấn đề thật không phải chỗ người ta nghĩ. Đo thật: đọc 10 MB gần như không chặn khách khác (Redis gửi theo đoạn), độ trễ dưới 10 KB phẳng hoàn toàn. Cái nguy hiểm là bộ đệm đầu ra — 20 khách đọc chậm biến 10 MB dữ liệu thành 215 MB used_memory, gấp 5.183 lần, và đó là cách một Redis 'chỉ chứa 5 GB' bị giết khi có 20 GB RAM.

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

Cảnh báo trên phần trăm bộ nhớ Redis cho bạn đúng 2 giây báo trước — rồi nó ghim ở 100% và câm lặng trong khi 15.870 khoá bị vứt đi mỗi giây

INFO trả về hơn hai trăm dòng; đo thật trên một Redis 64 MB cho thấy dòng bạn hay cảnh báo nhất — phần trăm bộ nhớ — là dòng vô dụng nhất khi sự cố xảy ra. Nó là chỉ số bão hoà, chạm trần rồi đứng im; cái thật sự nói mức nghiêm trọng là tốc độ đuổi khoá, một con số không có trần. Cùng bốn nguồn để truy một lệnh chậm, và mười chỉ số nên đưa lên bảng.

#giam-sat#zero-to-hero#redis
18
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.

#zero-to-hero#redis
19