Cân bằng lại nhóm consumer được vẽ nhiều mà đo ít. Tôi bắt từng sự kiện kèm dấu thời gian: kiểu 'nhả hết' xong trong 4 ms không ai để ý, còn kiểu hợp tác giữ được partition đang chạy nhưng mỗi partition nhường mất 3 giây — tổng đắt gấp 375 lần. Lời khuyên 'luôn dùng cooperative' chỉ đúng khi ngắt một partition là đắt.
Chốt offset là chỗ dữ liệu thật sự mất hoặc trùng. Tôi dựng một lần sập giống hệt nhau rồi chạy ba cách: chốt trước khi xử lý mất tin, chốt sau khi xử lý trùng tin, không cách nào từ Kafka cho ra đúng một lần. Thứ tự giữa 'làm việc' và 'ghi nhận đã làm' quyết định crash làm mất hay làm trùng.
Chiến lược chia mặc định (RangeAssignor) chia riêng từng topic và làm tròn cùng một phía, nên phần dư dồn hết lên một consumer: hai topic lệch 4:2, năm topic lệch 10:5. Cộng với chuyện khởi động lại một consumer gây tới hai lần cân bằng toàn nhóm — và một dòng group.instance.id xoá sạch cả hai.
'Kafka có độ trễ cao' là câu hay nói. Tôi đo thật, tách từng chặng: mặc định dưới một phần ba mili giây. Thứ gây độ trễ nghìn lần là hai bộ hẹn giờ chờ-gom-lô (linger.ms, fetch.min.bytes) — gần như miễn phí khi tải cao, nhưng bằng đúng cả khoảng chờ khi tải thấp, nên kiểu hỏng tệ nhất rơi vào lúc ba giờ sáng không ai nhìn bảng số.
'Đặ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 giữ thứ tự tin nhắn' đúng một nửa, và nửa sai là nửa gây sự cố. Tôi đo: thứ tự chỉ được bảo đảm trong một partition, không phải trong một topic. Và vì khoá định tuyến bằng băm chia lấy dư cho số partition, tăng partition làm gần một nửa khoá chuyển chỗ — tin cũ và tin mới của cùng một khoá rơi vào hai partition khác nhau, thứ tự vỡ vĩnh viễn.