Suốt mười năm Kafka cần ZooKeeper; từ 4.0 thì không. Tôi dựng cả hai kiểu cạnh nhau: KRaft nhanh gấp chín lần, nhẹ hơn, bớt một tiến trình. Nhưng bài học đáng nhớ hơn là khi ZooKeeper chết, Kafka vẫn ghi đọc bình thường — chỉ mặt phẳng điều khiển dừng — và bỏ ZooKeeper không có nghĩa bỏ được yêu cầu đa số 2f+1.
Kafka coi mọi tin là mảng byte, nên đổi lược đồ là trách nhiệm của bạn. Tôi đo cái giá khi làm sai: một tin sai kiểu khiến consumer quay ở 692 nghìn ngoại lệ mỗi giây, đốt trọn một nhân CPU, và partition đứng vĩnh viễn ở offset đó. Bảy dòng chữa nó — và cái bẫy thật là một vòng bắt-lỗi lặp lại ngay thao tác vừa hỏng.
Lời khuyên phổ biến là 'đừng dùng JSON trên Kafka, dùng Avro'. Tôi đo cả ba định dạng trên cùng dữ liệu: thô thì Avro nhỏ hơn JSON 2,5 lần nhưng mã hoá lại chậm hơn. Rồi bật nén — mà cụm nào cũng bật — và lợi thế co xuống 1,4 lần, vì nén xoá đúng phần dư thừa (tên trường lặp lại) mà Avro xoá bằng tay. Lý do thật để chọn Avro nằm ở chỗ khác.
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.
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.
Chi phí của giao dịch Kafka phụ thuộc hoàn toàn vào một con số bạn tự chọn: cỡ giao dịch. Một tin một giao dịch cho 96 tin/giây, cỡ 10.000 cho 639.285 — nhanh hơn cả không giao dịch. Đó là một chi phí cố định 10,4 mili giây được khấu hao trên số tin; nhưng gói càng lớn thì tin đầu tiên chờ càng lâu, vì read_committed không thấy gì tới khi cả lô cam kết.