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.
Debezium đọc WAL thay vì hỏi bảng, nên nó bắt được cả UPDATE lẫn DELETE mà JDBC source bỏ sót — kèm cả giá trị 'before' và 'after'. Nhưng cái giá nằm ở phía cơ sở dữ liệu: khe sao chép ghim WAL lại cho tới khi connector xác nhận, nên một consumer chết qua đêm có thể làm đầy đĩa và chặn luôn việc ghi của hệ giao dịch.
Chi phí của giao dịch Kafka phụ thuộc hoàn toàn vào một con số bạn tự chọn: cỡ giao dịch. Một tin một giao dịch cho 96 tin/giây, cỡ 10.000 cho 639.285 — nhanh hơn cả không giao dịch. Đó là một chi phí cố định 10,4 mili giây được khấu hao trên số tin; nhưng gói càng lớn thì tin đầu tiên chờ càng lâu, vì read_committed không thấy gì tới khi cả lô cam kết.
Nối hai dòng dữ liệu là việc phổ biến nhất và dễ làm sai nhất trong Kafka Streams. Tôi dựng một phép nối rồi chỉ đổi độ dài cửa sổ: kết quả đi từ đầy đủ xuống bằng không, không một dòng log. Cửa sổ nối so thời gian sự kiện, nên nó phải khớp khoảng cách thật trong nghiệp vụ — và cái giá của cửa sổ dài tỉ lệ với lưu lượng, không với độ dài.
Lag là chỉ số quan trọng nhất của một hệ thống Kafka, và cũng là chỉ số bị đặt cảnh báo sai nhiều nhất. Tôi đo cùng một trạng thái theo hai cách: hai triệu tin không hành động được, còn 102,6 giây thì trả lời ngay mọi câu hỏi. Cùng 100.000 tin lag có thể là 5 giây hoặc 2,8 giờ — chênh hai nghìn lần, tuỳ tốc độ.
Tôi dựng cả Kafka lẫn RabbitMQ trên cùng một máy, ném 200.000 tin vào mỗi bên và đo. Kafka thắng rõ về tốc độ. Nhưng khác biệt quyết định lựa chọn lại nằm ở chỗ khác hẳn: với RabbitMQ đọc xong là tin biến mất, với Kafka đọc xong tin vẫn còn — và đó là khác biệt kiến trúc, không phải hiệu năng.