Tôi dựng một broker Kafka hai cổng — PLAINTEXT và SSL — rồi đo cùng phần cứng, cùng dữ liệu: ghi với TLS chậm 20%, nhưng đọc chậm 2,2 lần, và cột SSL gần như phẳng trong khi PLAINTEXT tăng dần. Khác biệt không phải ngẫu nhiên — mã hoá giết chết sendfile, cái đường tắt zero-copy mà chỉ phía đọc mới được hưởng.
Bốn mươi phần, mỗi phần một phép đo thật trong container. Bài cuối gom lại những con số đáng mang theo, một bộ cấu hình mặc định mà mọi dòng đều có gốc từ một phép đo, sáu kiểu hỏng im lặng, và bài học đắt nhất: kết quả quá gọn gàng không phải phát hiện — nó là dấu hiệu phép đo đã hỏng.
'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ố.
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.
Ai cũng bảo 'acks=0 nhanh nhất'. Tôi đo thì thấy nó còn chậm hơn acks=1 5%. Chỉ acks=all mới thật sự tốn — mất nửa thông lượng. Và đây là thứ nửa đó mua được: sự thật, đúng lúc cụm đang hỏng.
'Ghi đúng một lần' là cụm dễ hiểu sai nhất trong Kafka. Mở tệp log ra xem, tôi thấy giao dịch bị huỷ vẫn nằm nguyên trên đĩa và vẫn chiếm offset — đủ để một consumer đã bắt kịp hoàn toàn vẫn hiện lag khác 0 suốt đời.