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ó.

Backend 01/09/2026 7 phút

200 khách cùng gặp một khoá Redis vừa hết hạn tạo ra đúng 200 truy vấn xuống cơ sở dữ liệu — và một dòng khoá kéo nó về 1, còn làm chính người dùng nhanh hơn 6,4 lần

Cache-aside chạy tốt khi mọi thứ bình thường. Bài này đo đúng khoảnh khắc nó không bình thường: một khoá nóng hết hạn và 200 khách cùng lao vào. Không bảo vệ: 200 truy vấn, p50 vọt lên 360 ms. Một khoá độc quyền: 1 truy vấn, p50 xuống 56 ms — nhanh hơn 6,4 lần, vì CSDL không bị 200 mũi cùng đâm. Trả giá trị cũ: không ai phải chờ, p50 chỉ 29 ms.

Backend 01/09/2026 8 phút

Một cặp ngoặc nhọn trong tên khoá đẩy trọn 20.000 khoá về đúng một nút Redis Cluster — nhưng thông lượng không hề đổi; cái nó lấy đi là hai phần ba dung lượng

Phần 23 thấy CRC16 rải khoá rất đều. Bài này đo khi nó KHÔNG đều: một thẻ băm {khach} gom cả 20.000 khoá vào một slot, hai nút còn lại giữ đúng số không. Bất ngờ là tốc độ chẳng suy suyển — một nút chịu trên 1,2 triệu lệnh/giây — nhưng cụm ba máy giờ chỉ còn dung lượng của một máy. Bạn trả tiền cho ba, dùng được một. Vấn đề của khoá nóng không phải chậm, mà là mất chỗ.

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.

Backend 01/09/2026 8 phút

Mở kết nối Redis mới cho mỗi lệnh chậm gấp 5,5 lần — và khi chạm trần 10.000 kết nối, chính redis-cli của bạn cũng không vào nổi để xem chuyện gì đang xảy ra

Bể kết nối là thứ mọi thư viện đều có và ít ai chỉnh. Đo thật: tái dùng kết nối nhanh gấp 5,5 lần mở mới mỗi lệnh (6,4 lần khi có mật khẩu), mật khẩu không làm Redis chậm mà chỉ làm việc MỞ kết nối chậm; mỗi kết nối chỉ tốn 1.928 byte và gần như 0 CPU khi ngồi không — nhưng có một trần cứng 10.000, và lúc chạm nó bạn mất luôn đường nhìn vào bên trong.

Backend 01/09/2026 7 phút

Memcached đọc nhanh hơn Redis 55% và tốn ít bộ nhớ hơn 61% cho cùng một bộ đệm — nhưng khởi động lại là mất sạch, và đó mới là chỗ quyết định

Đo cả hai trên đúng cùng bài toán khoá–giá trị 100 byte. Không đường ống thì bằng nhau (nút thắt là lượt đi về). Đẩy mạnh thì Memcached thắng vì đa luồng thật, và tốn ít RAM hơn 2,6 lần vì không có lớp đối tượng đa kiểu. Nhưng nó không có lưu trữ, trần 1 MB mỗi giá trị, và không có kiểu dữ liệu nào. Câu hỏi không phải cái nào nhanh, mà là bạn sẽ cần gì trong sáu tháng tới.