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 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
23
DevOps 01/09/2026 8 phút

Sự cố làm 0,2% request chậm gấp 56 lần mà p99 đứng yên ở 0,46 µs — chỉ p99.9 mới lộ ra 21,88 µs

Mở sê-ri quan sát: tôi dựng một sự cố thật (0,2% request đi qua nhánh chậm) rồi soi bằng cả metric, log, trace và đo giá từng lăng kính. p99 mù hoàn toàn vì sự cố nằm gọn trong phần đuôi nó cắt bỏ; trung bình chỉ nhích 12%; ba trụ cột không thay thế nhau — metric nói CÓ, log nói request NÀO, trace nói chậm Ở ĐÂU. Phân vị bạn theo dõi quyết định tỷ lệ sự cố nhỏ nhất bạn thấy được.

#zero-to-hero#giam-sat#quan-sat#devops
31
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.

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

Ghi giá trị mới thẳng vào cache lệch với cơ sở dữ liệu 103 trên 120 lần — còn 'xoá cache trước khi cập nhật', cái nghe an toàn nhất, để lại dữ liệu cũ nằm đó vĩnh viễn

Bộ đệm chỉ có ích khi nó đúng. Đo bốn cách giữ nó khớp với cơ sở dữ liệu khi có 8 luồng vừa đọc vừa ghi: ghi đè giá trị mới lệch 103/120 lần (tệ nhất, lại trực giác nhất); xoá-trước-cập-nhật nhìn hoàn hảo cho tới khi thêm người đọc song song thì để lại dữ liệu cũ VĨNH VIỄN; chỉ 'xoá sau khi cập nhật' cho lệch tạm thời tự khỏi. Bài toán thật không phải 'làm sao luôn khớp' mà 'lệch bao lâu thì chấp nhận được'.

#redis#zero-to-hero#postgresql
34
Linux 01/09/2026 9 phút

Cách chữa 'Too many open files' được nhắc nhiều nhất — ulimit -n 65536 — thường không làm điều bạn nghĩ: giới hạn mềm ai cũng tự nâng, và nâng nó lên có khi làm chương trình hỏng nặng hơn

Giới hạn mềm không phải một hàng rào, nó là giá trị khởi đầu — tiến trình tự nâng lên tới giới hạn cứng mà không cần quyền gì (đo được: gấp 1.027 lần). Một triệu mô tả tệp chỉ tốn 38 MB nên đặt thấp để 'tiết kiệm bộ nhớ' là vô nghĩa. Và cú bất ngờ nhất: nâng ulimit khiến một dịch vụ dùng select() hỏng ở tận đâu đâu, hàng giờ sau, chỉ khi tải cao.

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

Một tiêu thụ Redis Stream quên gọi XACK thổi 1,4 MB thành 28 MB — gấp 19,7 lần — và XTRIM cắt stream không cứu được một byte

List làm hàng đợi được và nhiều hệ thống dùng nó. Đo xem Stream cho thêm gì: nó gọn hơn List 24% dù mang thêm id, và khác biệt thật là khi tiến trình chết — bản tin ở lại danh sách chờ tới khi có ai XACK, còn List thì mất dấu. Nhưng danh sách chờ là cái bẫy: quên XACK làm bộ nhớ phình 19,7 lần, và XTRIM không cứu được vì chỗ tốn nằm ở pending, không ở stream. Giám sát XPENDING, không chỉ XLEN.

#redis#hieu-nang#zero-to-hero
30