Q

Quản trị viên

Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.

2300 bài viết · Website
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.

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.

Backend 01/09/2026 8 phút

Một lệnh lỗi giữa giao dịch Redis không huỷ gì cả — các lệnh khác vẫn chạy và vẫn giữ kết quả; 'transaction' của Redis không có chữ Rollback

Redis có MULTI/EXEC và gọi nó là giao dịch, nhưng nó bảo đảm ít hơn bạn tưởng. Đo thật: lỗi cú pháp lúc xếp hàng huỷ cả khối (EXECABORT), nhưng lỗi lúc chạy — INCR trên một chuỗi — chỉ báo lỗi đúng lệnh đó còn SET x và SET y vẫn chạy và vẫn giữ kết quả. Không có quay lui. Cái mạnh thật sự là WATCH — khoá lạc quan kiểu kiểm-rồi-đặt — và MULTI bọc quanh một đường ống gần như miễn phí (chênh 0,2%).

Linux 01/09/2026 8 phút

Đọc ngẫu nhiên qua bộ đệm trang nhanh gấp 15 lần đi thẳng xuống NVMe — và một máy chủ khoẻ mạnh luôn có RAM trống gần bằng 0, đó là điều đúng đắn chứ không phải triệu chứng

Bộ đệm trang là thứ làm 'available' khác 'free'. Đo thật: cùng lần đọc 4 KB ngẫu nhiên, qua bộ đệm 425.874 IOPS còn O_DIRECT chỉ 28.655 — 15 lần. Và bộ đệm ăn thêm nửa gigabyte trong khi RAM khả dụng gần như không đổi, vì trang bộ đệm sạch vứt đi lúc nào cũng được. RAM trống là RAM lãng phí. Cộng thêm một sai lầm đo lường: drop_caches không chạm tới máy chủ bên dưới.

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.

Backend 01/09/2026 8 phút

Một lệnh KEYS đẩy độ trễ PING của Redis từ 1 ms vọt lên 263 ms — trong khoảnh khắc đó khoảng 13.000 yêu cầu xếp hàng chờ, và DEL còn tệ hơn KEYS

Redis xử lý lệnh bằng một luồng duy nhất, nên một lệnh chậm không chỉ chậm — nó chặn đầu hàng của mọi khách khác. Đo thật trên 2 triệu khoá: KEYS '*' đẩy PING max lên 263,8 ms, SCAN chậm hơn 58% nhưng độ trễ tệ nhất ít hơn 63 lần vì nó nhường luồng; DEL một Hash 194 MB chặn 467,7 ms còn UNLINK chỉ 3,6 ms. Và độ trễ trung bình gần như không đổi — nên nếu chỉ đo trung bình, cả vấn đề này vô hình.