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.
Vì sao spawn hàng nghìn goroutine chạy mượt còn hàng nghìn OS thread thì nghẹt? Đo thật: ping-pong qua channel tốn 164 ns/vòng và 0 cấp phát, còn ping-pong qua pipe giữa hai OS thread tốn 21465 ns/vòng — đắt hơn 130 lần. Vì một cái ở user-space, cái kia qua kernel. Go 1.23.
Nhân bản sync bắt primary chờ standby xác nhận trước khi commit — không mất dữ liệu khi primary chết, nhưng chậm hơn. Đo thật: dải synchronous_commit từ 5021 xuống 2475 tps, và demo commit treo với wait_event SyncRep khi standby chết. PostgreSQL 16.
Cần kiểm tra một phần tử có trong tập triệu phần tử không, mà không muốn tốn hàng chục MB? Bloom filter làm được bằng một mảng bit và vài hàm băm. Bài này tự cài Bloom và đo thật: thay 57MB set bằng 1.25MB (nhỏ hơn 46 lần), tỉ lệ báo nhầm thực tế 0.83% khớp gần như hoàn hảo công thức lý thuyết 0.82%, và không bao giờ báo sót. Cơ chế, công thức, và khi nào dùng.
Làm sao lấy ngẫu nhiên 1000 dòng từ một log đang chảy, khi bạn không biết nó sẽ dài bao nhiêu và không thể giữ hết trong RAM? Algorithm R làm được với một lượt duyệt và bộ nhớ O(k). Bài này tự cài và đo thật: chạy 200.000 lần, mọi phần tử — đầu hay cuối luồng — đều được chọn với xác suất k/N (lệch tối đa 0.18 điểm phần trăm). Cơ chế, vì sao đều, và ứng dụng.
Khép lại loạt Serialization: điểm lại JSON, Protobuf, gob, MessagePack, CBOR, zero-copy — mỗi cái mạnh ở đâu — rồi chạy thật cả năm trên cùng một đơn hàng để so kích thước, tốc độ mã hóa/giải mã và cấp phát. Kết quả đo được: Protobuf nhỏ nhất (205 byte) và giải mã nhanh nhất, JSON dễ đọc nhất nhưng giải mã chậm nhất (2793 ns). Kèm cây quyết định và lời khuyên khi nào cứ JSON là đủ.
JIT biên dịch biểu thức truy vấn thành mã máy để chạy nhanh hơn, nhưng biên dịch tốn thời gian trả trước. Đo thật: JIT kích hoạt nhầm biến một query 0,045 ms thành 37,7 ms, và không thắng cả trên aggregate 5 triệu dòng. PostgreSQL 16.