Tôi dựng cả Kafka lẫn RabbitMQ trên cùng một máy, ném 200.000 tin vào mỗi bên và đo. Kafka thắng rõ về tốc độ. Nhưng khác biệt quyết định lựa chọn lại nằm ở chỗ khác hẳn: với RabbitMQ đọc xong là tin biến mất, với Kafka đọc xong tin vẫn còn — và đó là khác biệt kiến trúc, không phải hiệu năng.
Khi một tin không xử lý được, phản xạ tự nhiên là thử lại. Tôi đo cái giá đó ở bốn mức tỉ lệ hỏng: ở mức 50%, thử lại tại chỗ cho 30 tin/giây còn đẩy sang DLQ cho 766 — chênh 25,5 lần. Chi phí của một tin hỏng không phải là chờ nó, mà là toàn bộ hàng phía sau cũng phải chờ theo.
Mọi hệ lưu trữ phải trả lời: ghi vào bộ đệm hệ điều hành đã coi là an toàn chưa? Kafka trả lời khác PostgreSQL, và tôi đo cái giá: fsync mỗi lô kéo thông lượng từ 540k xuống 170k tin/giây. Kèm một câu chuyện về phép đo hình chữ U mà tôi suýt công bố — hoá ra do một lệnh tạo topic hỏng bị nuốt lỗi.
Chạy Kafka trong Docker để thử nghiệm chỉ cần một lệnh. Chạy nó thật thì cần vài dòng nữa — và bài này đo chuyện gì xảy ra khi thiếu từng dòng: thiếu volume thì mất sạch dữ liệu không một dòng log, giới hạn bộ nhớ 400 MB thì broker bị OOMKilled giữa chừng, và advertised.listeners sai là chỗ hỏng nhiều nhất.
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.
Khả năng đọc lại dữ liệu cũ là thứ phân biệt Kafka với hàng đợi truyền thống. Tôi đo bốn cách tua offset, và tìm ra cái bẫy trong cách dùng nhiều nhất: --to-datetime với mốc quá dữ liệu không từ chối mà âm thầm lùi về 'latest' — nhảy tới cuối, ngược hẳn ý định — kèm một thông báo 'empty' hoàn toàn gây hiểu nhầm.