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.
Kafka hay được khen nhanh nhờ 'zero-copy' và 'page cache', hai cụm từ ít khi được đo. Tôi đo cả hai: một broker 1,2 GB phục vụ 1.130 MB/giây, và khi xoá sạch bộ đệm trang, đọc lạnh chỉ chậm 1,6 lần chứ không phải hai bậc độ lớn — vì Kafka đọc tuần tự, và với truy cập tuần tự thì bộ đệm gần như là tuỳ chọn.
Mọi hệ lưu trữ phải trả lời: ghi vào bộ đệm hệ điều hành đã coi là an toàn chưa? Kafka trả lời khác PostgreSQL, và tôi đo cái giá: fsync mỗi lô kéo thông lượng từ 540k xuống 170k tin/giây. Kèm một câu chuyện về phép đo hình chữ U mà tôi suýt công bố — hoá ra do một lệnh tạo topic hỏng bị nuốt lỗi.