Message Queue 30/08/2026 8 phút

50.000 UPDATE và 10.000 DELETE trong PostgreSQL sinh ra đúng 0 bản ghi trong Kafka — connector vẫn báo RUNNING, và dữ liệu sai nằm đó vĩnh viễn

Kafka Connect đưa dữ liệu vào ra Kafka bằng JSON cấu hình thay vì mã. Tôi dựng đường ống PostgreSQL → Kafka và đo: thông lượng hơn trăm nghìn dòng/giây, nhưng mode=incrementing mù hoàn toàn với UPDATE và DELETE — không lỗi, không log, connector vẫn xanh, trong khi hạ nguồn tính toán trên dữ liệu cũ. Cách bạn phát hiện thay đổi quyết định loại thay đổi bạn thấy được.

Message Queue 30/08/2026 8 phút

Tôi tạm dừng một connector Debezium đúng 8 giây, PostgreSQL giữ lại 50 MB WAL — và không nhả ra kể cả khi đã bắt kịp; một sự cố hạ nguồn leo ngược lên hệ thống gốc

Debezium đọc WAL thay vì hỏi bảng, nên nó bắt được cả UPDATE lẫn DELETE mà JDBC source bỏ sót — kèm cả giá trị 'before' và 'after'. Nhưng cái giá nằm ở phía cơ sở dữ liệu: khe sao chép ghim WAL lại cho tới khi connector xác nhận, nên một consumer chết qua đêm có thể làm đầy đĩa và chặn luôn việc ghi của hệ giao dịch.

Message Queue 30/08/2026 9 phút

Lag tăng 57 lần trong 60 giây, mà cả ba chỉ số sức khoẻ broker Kafka vẫn xanh mướt — chúng không nói dối, chúng chỉ đang đo sai thứ

Kafka phát ra hàng trăm chỉ số qua JMX. Tôi dựng một sự cố thật — consumer treo, dữ liệu ngừng chảy tới hạ nguồn — rồi xem chỉ số nào báo: broker báo hoàn toàn khoẻ suốt cả phút. Bài này chỉ ra bốn chỉ số broker thật sự đáng cảnh báo, và ba chỉ số phía client mới là thứ nói cho bạn biết đường ống có đang chạy hay không.

Message Queue 30/08/2026 9 phút

Cùng một trạng thái Kafka: 'tụt 2 triệu tin' hay 'tụt 102,6 giây' — một con số nói cho bạn mọi thứ, con số kia chẳng nói gì

Lag là chỉ số quan trọng nhất của một hệ thống Kafka, và cũng là chỉ số bị đặt cảnh báo sai nhiều nhất. Tôi đo cùng một trạng thái theo hai cách: hai triệu tin không hành động được, còn 102,6 giây thì trả lời ngay mọi câu hỏi. Cùng 100.000 tin lag có thể là 5 giây hoặc 2,8 giờ — chênh hai nghìn lần, tuỳ tốc độ.

Message Queue 30/08/2026 8 phút

Đặt hạn ngạch 5 MB/giây cho Kafka, client vẫn đẩy lọt 47 MB ở tốc độ 150 MB/giây — và khi bị bóp, nó chỉ thấy độ trễ 10,9 giây chứ không một lỗi nào

Một client viết sai có thể chiếm hết băng thông cả cụm. Kafka có hạn ngạch để chặn, và tôi đo xem nó thật sự làm gì: bóp đúng xuống 4,38 MB/giây, nhưng bóp bằng cách làm chậm phản hồi chứ không từ chối, nên không có lỗi nào để bắt — và vì nó đo trên cửa sổ trung bình 11 giây, một client vẫn bùng phát được tới gấp 11 lần hạn ngạch trước khi bị chặn.

Message Queue 30/08/2026 9 phút

Bật TLS cho Kafka làm việc ghi chậm 20%, nhưng việc đọc chậm tới 2,2 lần — cùng một tính năng, hai cái giá lệch hẳn, và lý do nằm ở một đường tắt chỉ phía đọc mới có

Tôi dựng một broker Kafka hai cổng — PLAINTEXT và SSL — rồi đo cùng phần cứng, cùng dữ liệu: ghi với TLS chậm 20%, nhưng đọc chậm 2,2 lần, và cột SSL gần như phẳng trong khi PLAINTEXT tăng dần. Khác biệt không phải ngẫu nhiên — mã hoá giết chết sendfile, cái đường tắt zero-copy mà chỉ phía đọc mới được hưởng.