Bài viết mới nhất

Tổng 2300 bài
Lập trình 22/09/2026 8 phút

Logical replication đo thật: chép một triệu dòng sang cụm khác sẵn sàng sau 1,2 giây, lag 0 byte dưới tải nhẹ nhưng một giao dịch 300.000 dòng mất 1,2 giây để áp, và ba thứ nó không chép làm subscription đứng: DDL, sequence, xung đột khoá chính

Publication trên PostgreSQL 16, subscription trên cụm riêng: 1.000.000 dòng 158 MB sẵn sàng sau 1.185 ms. Dưới 200 giao dịch UPDATE 500 dòng, lag logic và vật lý đều 0 byte. Một UPDATE 300.000 dòng một giao dịch: publisher 639 ms, subscriber áp xong sau 1.836 ms. ADD COLUMN ở publisher làm worker chết với lỗi missing replicated column, thêm cột ở subscriber thì nối lại sau 1,3 giây. Sequence không sang: subscriber ở 1 khi publisher ở 1.000, insert đầu tiên duplicate key. Xung đột khoá chính kẹt mọi giao dịch phía sau, worker thử lại mỗi 5 giây, SKIP lsn gỡ trong 1,9 giây. TRUNCATE có sang.

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

Polling, long polling, SSE và WebSocket đo thật trên cùng một luồng sự kiện: polling mỗi giây trễ 486 ms và tốn 8,4 KB mỗi phút cho 23 sự kiện, WebSocket và SSE trễ 0,3 ms với 1,3 KB, với 200 client polling tốn CPU gấp ba mà trễ gấp 300 lần

Một server Go phát sự kiện ngẫu nhiên trung bình mỗi 2 giây, một client đo độ trễ từ lúc sự kiện sinh ra tới lúc nhận và đếm byte TCP thật. Polling 1 giây: p50 486 ms, p99 900 ms, 60 request và 8.373 byte mỗi phút. Polling 5 giây: p50 2,3 giây. Long polling: 0,5 ms nhưng 39 request mỗi phút. SSE và WebSocket: 0,3 ms, 1 kết nối, 1.221 và 1.276 byte mỗi phút. Sau netem 50 ms, mọi cách đẩy cộng đúng 50 ms. Với 200 client, polling tốn 0,33 giây CPU server mỗi 30 giây và 12.000 request mỗi phút trong khi SSE tốn 0,11 giây với 200 kết nối mở và 5,4 MB heap.

Kiến trúc hệ thống 22/09/2026 5 phút

Kafka và log phân tán: chạy THẬT và đo 1,25 triệu message/giây trên một broker

Kafka ghi xuống đĩa mà vẫn ingest hàng triệu message/giây. Bí quyết là một lựa chọn cấu trúc: log chỉ-thêm-vào-cuối biến mọi ghi thành tuần tự, cộng page cache và zero-copy. Bài này chạy THẬT Kafka 3.8 và đo bằng chính công cụ perf của Kafka: producer 1.253.132 records/giây (119,51 MB/s), consumer 1.139.211 msg/giây.

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

Backpressure WebSocket đo thật: một client không đọc làm hub ghi thẳng đứng hẳn ở giây thứ 3 và bỏ đói 20 client khoẻ, hàng đợi không giới hạn ăn thêm 1 MB RAM mỗi giây, còn hàng đợi 256 với drop hoặc ngắt giữ RAM phẳng ở 13 MB

Server Go fan-out 1 KB, khoảng 900 thông điệp mỗi giây, tới 20 client đọc bình thường và 1 client không bao giờ đọc. Ghi thẳng không deadline: kernel nuốt 2,5 MB vào send buffer rồi Write chặn, vòng hub đứng ở thông điệp 3.133 và cả 20 client khoẻ nhận 0 thông điệp mỗi giây từ giây 4 tới hết. Ghi thẳng với deadline 1 giây: hub kẹt đúng 1.002 ms rồi đóng client chậm ở giây 4,25. Hàng đợi không giới hạn: heap 7,5 lên 26,9 MB, RSS 19 lên 41 MB sau 30 giây, 24.091 thông điệp chờ. Hàng đợi 256 với drop: RSS 13 MB, bỏ 25.076 trong 28.503. Hàng đợi 256 với ngắt: đóng client chậm ở giây 3,82.

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

VACUUM và autovacuum: cơ chế dọn bản chết tự động giữ PostgreSQL sống sót

Bloat (bài trước) sẽ bóp nghẹt database nếu không được dọn — và VACUUM là công cụ dọn đó. Bài này đo thật trên pg-lab: autovacuum TỰ chạy khi dead tuple vượt ngưỡng, đưa n_dead_tup từ 10.000 về 0 mà không cần một lệnh nào. Xem VACUUM VERBOSE báo cáo dọn 5000 tuple, không gian được tái dùng giữ kích thước ổn định, và vì sao đừng bao giờ tắt autovacuum.

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

Đọc trên replica đo thật: truy vấn dài bị huỷ sau 2,2 giây hoặc 30,9 giây tuỳ max_standby_streaming_delay, chờ mãi thì lag phình 454 MB trong 12 giây, feedback hết huỷ nhưng để lại 400.000 dead tuple trên primary, đọc ngay sau ghi trượt 299/300

Trên replica PostgreSQL 16 ở chế độ hot standby, một truy vấn 40 giây giữ snapshot gặp VACUUM từ primary: với max_standby_streaming_delay 2 giây bị huỷ sau 2,2 giây, với 30 giây mặc định bị huỷ sau 30,9 giây, với -1 chạy xong nhưng lag replica lên 454 MB và 12 giây dưới tải. Bật hot_standby_feedback thì truy vấn chạy xong, xmin của replica xuất hiện trong slot và VACUUM VERBOSE trên primary báo 400.000 dead tuple chưa dọn được. Đọc ngay sau ghi bằng Go pgx: 299 trong 300 lượt chưa thấy dòng vừa commit, thấy sau 1,4 ms trung vị và tối đa 120 ms dưới tải, dù lag báo 0 byte.