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.
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.
min.insync.replicas quyết định lúc nào Kafka thà từ chối ghi còn hơn nhận rồi mất. Tôi đo cả ba giá trị ở ba mức hỏng: đặt bằng đúng replication-factor thì không còn dư địa nào, mỗi lần bảo trì một broker đều dừng ghi. Và có một kiểu hỏng — mất quorum controller — mà không cấu hình topic nào chạm tới được, trong khi describe vẫn báo khoẻ.