Một client viết sai có thể chiếm hết băng thông cả cụm. Kafka có hạn ngạch để chặn, và tôi đo xem nó thật sự làm gì: bóp đúng xuống 4,38 MB/giây, nhưng bóp bằng cách làm chậm phản hồi chứ không từ chối, nên không có lỗi nào để bắt — và vì nó đo trên cửa sổ trung bình 11 giây, một client vẫn bùng phát được tới gấp 11 lần hạn ngạch trước khi bị chặn.
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.
Xác thực trả lời 'bạn là ai', ACL trả lời 'bạn được làm gì'. Tôi bật ACL trên cụm thật rồi cấp quyền từng lớp: broker bị chính luật của nó chặn vì lưu lượng nội bộ là ANONYMOUS, đọc cần tới hai ACL, và lỗi của producer idempotent nói về cụm chứ không nói về topic. Mỗi lỗi đều chỉ sai chỗ cần sửa.
Sao chép Kafka giữa hai vùng là nền của mọi kế hoạch phục hồi thảm hoạ. Tôi dựng hai cụm thật, chạy MirrorMaker 2: dữ liệu sang hoàn hảo trong 8,7 giây, nhưng vị trí đọc của consumer thì không — topic checkpoint được tạo ra, rỗng, và im lặng. Đó là khác biệt giữa 'có bản sao dữ liệu' và 'có kế hoạch chuyển vùng'.
Nâng cấp Kafka không cần dừng dịch vụ, quy trình ngắn hơn nhiều người nghĩ. Tôi chạy nó thật trên cụm đang có producer và consumer hoạt động: thay từng broker, ISR đầy lại sau 1–22 giây, không mất tin. Nhưng nhị phân mới không có nghĩa giao thức đã mới — và khoảng cách đó là một cửa sổ lùi được đặt ra có chủ ý.
Chạy Kafka trong Docker để thử nghiệm chỉ cần một lệnh. Chạy nó thật thì cần vài dòng nữa — và bài này đo chuyện gì xảy ra khi thiếu từng dòng: thiếu volume thì mất sạch dữ liệu không một dòng log, giới hạn bộ nhớ 400 MB thì broker bị OOMKilled giữa chừng, và advertised.listeners sai là chỗ hỏng nhiều nhất.