'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ố.
Kafka coi mọi tin là mảng byte, nên đổi lược đồ là trách nhiệm của bạn. Tôi đo cái giá khi làm sai: một tin sai kiểu khiến consumer quay ở 692 nghìn ngoại lệ mỗi giây, đốt trọn một nhân CPU, và partition đứng vĩnh viễn ở offset đó. Bảy dòng chữa nó — và cái bẫy thật là một vòng bắt-lỗi lặp lại ngay thao tác vừa hỏ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.
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.
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.
Tôi dựng đúng một ứng dụng nginx ba bản bằng Docker thuần rồi bằng Kubernetes, và đo cả hai — kể cả cái giá. Docker thắng mọi chỉ số tốc độ và bộ nhớ. Rồi tôi giết một thứ đang chạy, và mọi thứ đảo chiều: Docker chạy thứ bạn bảo nó chạy, Kubernetes giữ thứ bạn khai là phải có.