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.

2312 bài viết · Website
Lập trình 22/09/2026 9 phút

Tổng kết Caching: gom 11 phép đo thành một hàm, DB giảm 19 lần và Redis giảm 60 lần

Phần cuối loạt Caching gom mọi thứ đã đo thành một hàm đọc duy nhất — L1 trong tiến trình, singleflight, khoá SET NX, dấu vắng mặt, TTL có nhiễu — rồi đo nó cạnh cache-aside ngây thơ dưới cùng một lưu lượng: 32 người đọc song song, Zipf trên 5000 key, 5% là bot quét id không tồn tại. Kết quả: truy vấn database từ 101.739 xuống 5.300 (đúng sàn lý thuyết), lưu lượng Redis từ 100% xuống 0,1%, p99 từ 0,283ms xuống 0,001ms — đổi lại đuôi khởi động nguội xấu hơn, 388,7ms so với 21,5ms. Kèm khung quyết định và checklist rà soát trước khi lên production.

Lập trình 22/09/2026 8 phút

Structured logging với slog: vì sao log chuỗi tự do là món nợ kỹ thuật bạn trả lúc 3 giờ sáng

Lúc sự cố xảy ra, bạn không đọc log — bạn truy vấn nó. Và log chuỗi tự do (fmt.Printf) không truy vấn được: mỗi dòng một định dạng, muốn lọc phải viết regex. Bài này đo thật với log/slog của Go 1.23: cùng một sự kiện in ra chuỗi tự do và JSON có cấu trúc, rồi dùng jq lọc 1000 dòng log theo nhiều field (đếm ERROR theo service, tính latency trung bình). Kèm số đo chi phí thật — và một sự thật ngược đời: log chuỗi nhanh hơn slog gần 1.7 lần.

Lập trình 22/09/2026 6 phút

Consumer lag: con số nói cho bạn biết hệ thống Kafka sắp sập trước khi nó sập

Nếu chỉ được theo dõi một chỉ số của Kafka, hãy chọn consumer lag — khoảng cách giữa chỗ producer đã ghi và chỗ consumer đã xử lý. Bài này đo thật trong lab: lag phình từ 700 lên 1200 khi producer ghi nhanh hơn consumer, rồi co về 0 khi consumer đuổi kịp. Hiểu công thức LAG = LOG-END − CURRENT, phân biệt offset lag với time lag, và biết dấu hiệu nguy hiểm thật: lag tăng đều không ngừng.