Backend

Theo dõi riêng chuyên mục này 40 bài viết
Backend 01/09/2026 7 phút

Một lệnh SET vô tình xoá sạch TTL và biến phiên đăng nhập 30 phút thành khoá sống mãi mãi — còn APPEND lại giữ nguyên hạn, dù cả hai đều sửa giá trị

Đặt TTL là thao tác phổ biến nhất trong Redis sau GET và SET. Đo ba thứ ít ai kiểm: Redis dọn 100.000 khoá hết hạn trong dưới một giây (nhanh hơn lời đồn), SET xoá TTL nhưng APPEND/INCRBY thì không — vì lệnh thay thế cả khoá thì mất hạn còn lệnh sửa tại chỗ thì giữ — và mỗi TTL tốn thêm 34,4 byte (+19%). Quên KEEPTTL là nguồn của một lớp lỗi khoá bất tử không lỗi, không cảnh báo.

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

Cùng 199 trường, cùng dữ liệu, nhưng một Hash tốn 16.256 byte còn cái kia 1.840 byte — chênh 8,8 lần chỉ vì một khoá từng phình to rồi co lại

Redis đổi cách mã hoá tập hợp khi nó vượt ngưỡng, nhưng KHÔNG BAO GIỜ đổi ngược. Đo thật: một Hash từng có 513 trường rồi xoá còn 199 vẫn tốn 16.256 byte, gấp 8,8 lần một Hash tạo mới đúng 199 trường (1.840 byte). Đây là rò rỉ bộ nhớ âm thầm nhất trong Redis — phình trong đợt cao điểm rồi giữ chi phí lúc lớn nhất vĩnh viễn. Và một giá trị vượt 64 byte đẩy cả Hash sang mã hoá đắt.

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

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

Redis nhanh hơn PostgreSQL 4,1 lần khi ghi — không phải 100 lần như lời đồn; và phần lớn khoảng cách đó là độ bền bị bỏ, không phải kiến trúc

Mở đầu sê-ri bốn mươi phần về Redis, không bằng lời quảng cáo mà bằng cách đo nó cạnh PostgreSQL trên đúng cùng một bài toán. Redis nhanh hơn 4,1 lần khi ghi và 2,0 lần khi đọc — nhưng bật cờ UNLOGGED trên Postgres là khoảng cách co còn 1,4 lần, cho thấy Redis nhanh chủ yếu vì mặc định không hứa gì về độ bền. Bộ nhớ mỗi bản ghi gần bằng nhau (185 vs 178 byte), và có một câu hỏi Redis không trả lời được.

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

Xoá 270.000 khoá khỏi Redis mà RSS không giảm một byte — bộ nhớ trả về theo cả trang, không theo từng khoá, nên xoá rải rác để lại lỗ không thu hồi được

mem_fragmentation_ratio là chỉ số hay bị hiểu sai nhất trong INFO memory. Đo ở ba trạng thái: một instance gần rỗng có tỷ lệ 16,59 mà hoàn toàn khoẻ; xoá 90% khoá thì used_memory tụt còn RSS đứng im ở 107,6 MB vì jemalloc chỉ trả một trang về khi MỌI đối tượng trong đó đã chết. Và activedefrag y, tự nó, thường là lệnh không có tác dụng vì ngưỡng mặc định 100 MB. Cảnh báo trên allocator_frag_bytes, đừng trên tỷ lệ.

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

Gom nhóm bốn trạng thái đơn hàng mất 203,8 ms trong Redis và 8,9 ms trong PostgreSQL — và 203,8 ms đó đóng băng toàn bộ máy chủ Redis

Dựng thử một ứng dụng thật trên Redis rồi đo. Tra một khoá đã biết: Redis thắng, 0,145 ms so với 0,334. Nhưng gom nhóm, lọc, sắp xếp thì nó thua 5–23 lần hoặc không làm được — và mỗi báo cáo chạy trong Lua khiến mọi khách khác chờ một phần năm giây. Redis giỏi tra theo nhãn, dở tra theo thuộc tính; ép nó làm việc thứ hai là tự dựng chỉ mục mà không ai giữ đồng bộ.

#redis#zero-to-hero#postgresql
28