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 5 phút

Timeout và context: đặt hạn cho mọi thao tác, và cái bẫy rò rỉ goroutine

Không đặt hạn thì một thao tác treo giữ luồng mãi, tài nguyên cạn dần. Bài này chạy thật trong Go: context timeout 200ms khiến thao tác 2 giây trả về sau 209ms với DeadlineExceeded; và đo cái bẫy quan trọng — 100 goroutine không nghe ctx.Done() vẫn rò rỉ dù đã cancel, còn 100 goroutine có nghe thì thoát sạch. Timeout chỉ có tác dụng nếu hàm thực sự tôn trọng context.

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

Worker pool: vì sao 'một goroutine mỗi task' hỏng ở quy mô, và bao nhiêu worker là đủ

Tạo một goroutine cho mỗi task nghe tiện, nhưng với hàng triệu task nó bùng nổ thành hàng triệu goroutine tốn RAM và đè downstream. Bài này chạy thật trong Go: worker pool giữ đúng 11 goroutine cho 200.000 task (so với 200.001), và đo throughput theo số worker — với CPU-bound, throughput bão hòa quanh số core (10), thêm worker không nhanh hơn. Giải thích cách chọn N cho CPU-bound vs I/O-bound.

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

Đọc GODEBUG=schedtrace trong Go: giải mã trạng thái bộ lập lịch không cần thư viện

schedtrace là công cụ số một để nhìn vào bộ lập lịch Go. Bài này giải mã từng trường của một dòng SCHED thật, và theo dõi vòng đời một run qua bốn snapshot — từ lúc goroutine dồn vào hàng đợi cục bộ tới khi mọi core bận. Kèm cách đọc để chẩn đoán nút thắt. Go 1.23.

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

Retry đúng cách: exponential backoff và jitter để không tự gây bão

Thử lại khi lỗi thoáng qua là đúng — nhưng retry ngay và đều của nhiều client cùng lúc tạo 'bão retry' đánh sập service đang gượng dậy. Bài này chạy thật trong Go: retry với exponential backoff (100/200/400ms), và đo sức mạnh của jitter — 50 client cùng lỗi, không jitter thì cả 50 dội cùng một cửa sổ 20ms, có jitter thì đỉnh chỉ còn 5, cắt tải retry ~10 lần.

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

Idempotency: retry đã cứu bạn ở phần 3, giờ đừng để nó trừ tiền khách hai lần

Retry là lá chắn chống lỗi tạm thời, nhưng nó có một mặt tối: nếu request đầu tiên đã thành công mà phản hồi bị mất, lần retry sẽ chạy lại side-effect — khách bị trừ tiền hai lần. Bài này đo thật trong Go: một handler thanh toán không có idempotency bị retry 5 lần trừ tiền 5 lần (số dư 1000 → 500); thêm idempotency key, con số về đúng 1 lần; và 1000 goroutine gửi cùng key đồng thời vẫn chỉ trừ đúng 1 lần, kiểm bằng go run -race.