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.
Bản sao là cơ chế Kafka dùng để không mất dữ liệu khi máy chết. Tôi giết máy thật và bấm giờ: 9,142 giây để bầu leader mới, đúng bằng broker.session.timeout.ms — vì không thể phân biệt tức thời 'đã chết' với 'chỉ chậm'. Không mất tin nào, nhưng có tin mất 11,7 giây mới tới, và broker sống lại thì ngồi không cho tới khi được trao lại việc.
'Đặt nhiều partition cho chắc' là lời khuyên phổ biến và tốn kém. Tôi đo cả hai vế: phía ghi một partition đã gần chạm trần, thêm consumer bão hoà ở 1,7 lần chứ không phải 4 lần, còn 2.000 partition rỗng đẩy bộ nhớ broker từ 290 MB lên 973 MB. Partition là đơn vị song song, không phải nút vặn thông lượng — và tăng thì được, giảm thì không.
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.
cleanup.policy=compact biến topic Kafka thành gần một bảng khoá–giá trị. Nhưng tôi đo thấy nó không để lại mỗi khoá đúng một tin: phần đầu log vừa ghi vẫn giữ nguyên bản trùng, chỉ phần đuôi đã nén mới sạch. Bảo đảm ở đây là 'rốt cuộc hội tụ về giá trị mới nhất', không phải một bất biến tức thời — và có một cái bẫy bia mộ khiến dữ liệu xoá vẫn còn.
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 độ.