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ẻ.
Có một tham số Kafka mà bật lên là bạn đồng ý mất dữ liệu trong vài tình huống. Tôi dựng đúng tình huống đó: unclean.leader.election.enable=true cho một bản sao cũ lên làm leader, 500 tin đã ack biến mất, và offset đi lùi — phá vỡ giả định nền của mọi thứ xây trên Kafka. Đây là lựa chọn giữa 'dừng lại chờ' và 'tiến lên với dữ liệu sai'.
Kafka nhanh vì gần như không làm gì phức tạp trên đĩa. Tôi mở tệp .index ra đọc từng dòng: một segment 4.992 tin chỉ có 63 mục — một dòng cho ~79 tin. Đủ để nhảy gần đúng rồi quét nốt, nên tìm một offset bất kỳ gần như miễn phí. Đây là đánh đổi chỉ mục thưa, và vì sao đọc lại từ giữa log không tốn gì.
retention.ms là mức *sàn*, không phải hạn chót: việc dọn chạy theo chu kỳ 5 phút và chỉ xoá nguyên cả segment. retention.bytes tính theo từng partition và làm tròn lên một segment, nên đĩa thật gấp 3,4 lần con số bạn viết. Đây là công thức dự trù đĩa đúng, và vì sao 'xoá sau 30 ngày' không phải một bảo đảm tuân thủ.
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.